Porting gcj to i386-darwin
Hi everyone, I would like to port gcj/libgcj to i386-darwin. Is there someone already working on that? Considering that powerpc-darwin is a supported platform, it should not prove to be too hard. However, I need some hints on how to proceed. At configure phase, GCC woes for: target-libmudflap target-libffi target-boehm-gc target-zlib target-libjava target-libada gnattools target-libgfortran The last 3 items should not really be needed for gcj. Let examine the others: target-zlib: should be sufficient to add i386-darwin to the supported platforms target-boehm-gc: a patch exists for porting to the new platform, so it should be a matter of applying it target-libffi, target-libmudflap, target-libjava: I don't know what exactly needs to be done, maybe someone could help me Another question: if I change a configure.am somewhere, is there a script that rebuilds all the configure things or I have to call autoconf (which version?) on it? Cheers, Sandro smime.p7s Description: S/MIME cryptographic signature
Re: Porting gcj to i386-darwin
target-zlib: should be sufficient to add i386-darwin to the supported platforms zlib is being skipped only because libjava is. target-boehm-gc: a patch exists for porting to the new platform, so it should be a matter of applying it Well, good. target-libffi, target-libmudflap, target-libjava: I don't know what exactly needs to be done, maybe someone could help me mudflap is not needed for java. libjava probably needs very little treatment if any, but I am not sure. libffi is going to be the hardest. You have to support Apple's calling conventions; I am not sure how different they are from say Microsoft (Windows) or SVR4 (Linux) calling conventions. Paolo
Re: Porting gcj to i386-darwin
Paolo Bonzini writes: target-zlib: should be sufficient to add i386-darwin to the supported platforms zlib is being skipped only because libjava is. target-boehm-gc: a patch exists for porting to the new platform, so it should be a matter of applying it Well, good. target-libffi, target-libmudflap, target-libjava: I don't know what exactly needs to be done, maybe someone could help me mudflap is not needed for java. libjava probably needs very little treatment if any, but I am not sure. libffi is going to be the hardest. You have to support Apple's calling conventions; I am not sure how different they are from say Microsoft (Windows) or SVR4 (Linux) calling conventions. My understanding is that the differences are tiny -- just doubles in structs. Andrew.
Re: Problem with pex-win32.c
I'll happily test a patch to that file for you...the only box at my house runs Windows... =-O Ian Lance Taylor wrote: Mark Mitchell [EMAIL PROTECTED] writes: The new pex-win32.c code doesn't operate correctly when used for MinGW-hosted tools invoked from a Cygwin window. In particular, process creation (gcc invoking as, say) results in a DOS console window popping up. When invoked from a DOS window, things are fine. The reason for this problem is that the current code uses MSVCRT's spawn to create the process, and that function doesn't provide fine enough control. You have to use CreateProcess to make this work as desired. When invoking CreateProcess, you must set bInheritHandle to TRUE and pass a long a STARTUPINFO structure with dwFlags set to STARTF_USESTDHANDLES, and the various hStd* handle fields set to the values from the calling process. (I'm pretty sure that CodeSourcery posted patches that did that at one point; they were in our 3.4-based toolchains.) You might think that linking with -mwindows would work, and, indeed that avoids the DOS windows popping up in Cygwin -- but they you get no output at all under Windows. I guess I have two questions: (a) do you feel like fixing this, and (b) if not, do you have any objection to using CreateProcess? I just copied the use of spawn from the earlier pex-win32 implementation. The pex_win32_exec_child function is basically exactly the same code as before. I certainly have no objection to using CreateProcess instead. I could try a patch, but I can't test it, because I don't have a Windows system. So it might be better if somebody else tackled it. Ian
Re: GCC for SPARC Systems
When you're a company like Intel with a relatively small gap between gcc on x86 and icl, it's worth improving the gcc backend, but on Sparc the gap is much wider, so the effort to bridge it may not be justified from a resource point of view. Eh, SPARC is not IA-64 so improving the SPARC back-end should not be more resource-consuming than designing and maintaining a hybrid compiler. If I'm not mistaken, the gap is wide for FP code essentially but Sun doesn't seem to care much about FP anymore if I read the Niagara specs correctly. Personally I wouldn't mind working towards improving gcc sparc backend. Actually we are fixing gcc own bugs and contribute them back. To be clear, not bugs in the SPARC back-end. May I also suggest to find a different name for the product? Presumably it doesn't run on Linux or FreeBSD so GCC for SPARC Systems is a bit misleading, given that FSF GCC for SPARC does run on the aforementioned operating systems in addition to Solaris. Something like Sun GCC for SPARC/Solaris Systems although I'm not sure if using GCC is not already misleading. -- Eric Botcazou
Memory layout of complex data types on the RTL level
Hi, I'm working on a research project that performs static source code vulnerability analysis on the RTL layer. (http://rtl-check.sf.net) For the analysis we need to manually annotate the amount of memory needed to represent local variables and global static variables. For the stack level this information is easy to get from GCC, but we need it for the RTL level and I couldn't find it after some digging in the GCC sources. I assume this information is already available in one of the stages, can anyone please point me where too have a deeper look? Cheers, Moritz
Using only regular register names in emitted assembly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there how is it possible to emit regular register names (e.g. for the MIPS to use $31 and not $ra) when producing assembly output (with mips-elf-gcc -S)? I want to just use the arithmetic names ($0 to $31). regards Nikolaos Kavvadias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEEaTPMPiy0tCWlz4RAmB7AKCcccJKNm6DZLE4ZRy1cnLAIBUjRQCgj2J4 Jz4Ntxn7dsjC69JZDQDOuS0= =4eRz -END PGP SIGNATURE-
RE: Crazy ICE from gcc 4.1.0
I suspect it isn't matching pattern #2, because it couldn't get a QI
register, and instead it falls back to the general case of moving to a
normal register. I believe the gcc_assert should contain a check for
CONST_INT as well as a QI register or memory.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Alan Lehotsky
Sent: Thursday, March 09, 2006 1:05 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Crazy ICE from gcc 4.1.0
I've built a generic 4.1.0 for RH7.3 x86 linux (I did a make bootstrap)
Compiling a rather large file, I get
tmp.f_00.cxx:26432: error: unrecognizable insn:
(insn 173 172 174 9 (set (reg:QI 122)
(const_int 128 [0x80])) -1 (nil)
(nil))
tmp.f_00.cxx:26432: internal compiler error: in extract_insn, at
recog.c:2020
Which looks insane, because there's a perfectly good define_insn (cf
*movqi_1 in i386.md)
I'm trying to reduce this to a reasonably sized test case (and I'm going
to try debugging this in the recognizer),
but I can't see why this instruction isn't matching the 2nd constraint
alternative and just producing a movb r,#128
(define_insn *movqi_1
[(set (match_operand:QI 0 nonimmediate_operand =q,q ,q ,r,r ,?r,m)
(match_operand:QI 1 general_operand
q,qn,qm,q,rn,qm,qn))]
GET_CODE (operands[0]) != MEM || GET_CODE (operands[1]) != MEM
{
switch (get_attr_type (insn))
{
case TYPE_IMOVX:
gcc_assert (ANY_QI_REG_P (operands[1]) || GET_CODE (operands[1])
== MEM);
return movz{bl|x}\t{%1, %k0|%k0, %1};
default:
if (get_attr_mode (insn) == MODE_SI)
return mov{l}\t{%k1, %k0|%k0, %k1};
else
return mov{b}\t{%1, %0|%0, %1};
}
}
Re: GCC for SPARC Systems
Alexey Starovoytov writes: If Sun starts improving GCC backend now it will never be able to catch up with Sun's own backend. This is a completely ridiculous assertion. Do you have any evidence to back this up? There is no reason that GCC could not intercept Sun CC if some effort were made. SPARC is not that different from other RISC architectures that GCC supports well. If Sun wants to protect its compiler business, that is fine, but it is a business decision, not a technical decision. When you're a company like Intel with a relatively small gap between gcc on x86 and icl, it's worth improving the gcc backend, but on Sparc the gap is much wider, so the effort to bridge it may not be justified from a resource point of view. Has anyone at Sun investigated and analyzed the source of the gap relative to a recent version of GCC? If Sun does not want to cooperate with the Free Software community, that may be a reasonable business decision, but at least provide the real explanation or do not say anything instead of excuses. David
Re: Porting gcj to i386-darwin
Sandro == Sandro Tolaini [EMAIL PROTECTED] writes: Sandro Hi everyone, I would like to port gcj/libgcj to i386-darwin. Is there Sandro someone already working on that? Not that I know of. Sandro target-zlib: should be sufficient to add i386-darwin to the supported Sandro platforms Yeah. Sandro target-boehm-gc: a patch exists for porting to the new platform, so Sandro it should be a matter of applying it Yeah. We can also import a new GC if that helps. Sandro target-libffi, target-libmudflap, target-libjava: I don't know what Sandro exactly needs to be done, maybe someone could help me libffi and mudflap were covered by Paolo and Andrew. Note that if the only ABI difference is doubles in structs, then libffi should work fine for libgcj's purposes already -- libgcj never passes structs via libffi. Note also that you can disable libffi and still build libgcj. You will be missing some features, and we wouldn't consider this a real port... but this can be a convenient way to work on it in the order you prefer. For libjava some porting may be required, though it shouldn't be very much. For best results you will want to make sure that the code to turn signals into exceptions works properly. This is both OS- and architecture dependent. I haven't looked at the x86 darwin port, perhaps some gcc hacking is required. Sandro Another question: if I change a configure.am somewhere, is there a Sandro script that rebuilds all the configure things or I have to call Sandro autoconf (which version?) on it? You have to run autoconf et al by hand. Tom
Re: Segmentation fault in openmp simple routine from libgomp testsuite.
On Mar 7, 2006, at 6:31 PM, Andrew Pinski wrote: I bet the same issue now will happen with libstdc++ (and in 4.1.0 in fact). I want to say the weak references is the wrong way of doing things for non shared libraries. And it turned out I was correct in saying libstdc++ is also effected. See PR 26633. So this is not a libfortran specific issue any more. Adding Alexandre to the CC since it was his weak reference patch which caused this regression for libstdc++. Thanks, Andrew Pinski
Re: GCC for SPARC Systems
On Friday 03 March 2006 02:46, Alexey Starovoytov wrote: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ Instead of pleased, I'd be ashamed for announcing this. To me it feels like you're announcing with pride how you ripped off gcc. Nota bene on a list that exists to discuss how to improve GCC, not how to take the bits you like and evade the implications of its license And to make things worse, you are explaining to users the reason why gcc4ss should exist using arguments that are simply not true. For example: Especially considering very conservative heuristics and that inlining happens after all tree-level optimization are completed. (quoted from your blog). Anyone who has looked at GCC closely, knows that this is nonsense. Inlining happens _before_ all (tree-level and other) optimizations. I have to assume you also looked at GCC close enough to notice. It is unfortunate, but I guess typical, that Sun has not learned from the mistakes made by others in the past, for example from how SGI tried and failed to pull off the same trick with Pro64. Gr. Steven
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, Eric Botcazou wrote: Eh, SPARC is not IA-64 so improving the SPARC back-end should not be more resource-consuming than designing and maintaining a hybrid compiler. If I'm gcc4ss wasn't a big effort. gimple form made it easy for us. not mistaken, the gap is wide for FP code essentially but Sun doesn't seem to care much about FP anymore if I read the Niagara specs correctly. You're right about Niagara's FP, but it's just one line of products. May I also suggest to find a different name for the product? Presumably it doesn't run on Linux or FreeBSD so GCC for SPARC Systems is a bit misleading, given that FSF GCC for SPARC does run on the aforementioned operating systems in addition to Solaris. Something like Sun GCC for SPARC/Solaris Systems although I'm not sure if using GCC is not already misleading. Glad you mentioned it. Really. I don't like that name either. Unfortunatelly that what we were told to use. May be we'll try to change it. Also your 'presumtion' is correct for the present only. Alexey. -- Eric Botcazou
Re: Memory layout of complex data types on the RTL level
In fact, the url of the project seams to be http://rtlcheck.sourceforge.net/ CJ Moritz Muehlenhoff [EMAIL PROTECTED] a écrit dans le message de news:[EMAIL PROTECTED] Hi, I'm working on a research project that performs static source code vulnerability analysis on the RTL layer. (http://rtl-check.sf.net) For the analysis we need to manually annotate the amount of memory needed to represent local variables and global static variables. For the stack level this information is easy to get from GCC, but we need it for the RTL level and I couldn't find it after some digging in the GCC sources. I assume this information is already available in one of the stages, can anyone please point me where too have a deeper look? Cheers, Moritz
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, David Edelsohn wrote: Alexey Starovoytov writes: If Sun starts improving GCC backend now it will never be able to catch up with Sun's own backend. This is a completely ridiculous assertion. Do you have any evidence to back this up? There is no reason that GCC could not intercept Sun CC if some effort were made. SPARC is not that different from other RISC architectures that GCC supports well. If Sun wants to protect its compiler business, that is fine, but it is a business decision, not a technical decision. So you're saying your team will be able to beat xlc. Ahh. Ok. Good for you. Personally I don't think that sparc gcc backend will be able to catch up with Sun's across the range of tests and benchmarks any time soon. Few major infrastructure features needs to be done first. I'm not here to defend Sun's compilers. The scope of gcc4ss is to deliver performance on SPARC chips. Period. If GCC can beat Sun there. Great! We wouldn't need to do any of this work. Has anyone at Sun investigated and analyzed the source of the gap relative to a recent version of GCC? If Sun does not want to cooperate with the Free Software community, that may be a reasonable business decision, but at least provide the real explanation or do not say anything instead of excuses. Yes. We know the reasons, but it doesn't sound that you want to hear them. You're just concerned about 'excuses'. Again I'm not representing any 'business' decisions. We just want SPARC chips to run faster and gcc4ss is just a tool to deliver that. Alexey.
Re: Segmentation fault in openmp simple routine from libgomp testsuite.
On Mar 10, 2006, at 3:14 PM, Andrew Pinski wrote: And it turned out I was correct in saying libstdc++ is also effected. See PR 26633. So this is not a libfortran specific issue any more. Actually that turned out to the TLS not be updated correctly for threads issue with static linking problem. -- Pinski
Re: GCC for SPARC Systems
On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote: Few major infrastructure features needs to be done first. Like? Please give examples. If link time optimizations, that is already starting to be worked on. -- Pinski
Re: Problem with pex-win32.c
Mark Mitchell wrote: The new pex-win32.c code doesn't operate correctly when used for MinGW-hosted tools invoked from a Cygwin window. In particular, process creation (gcc invoking as, say) results in a DOS console window popping up. When invoked from a DOS window, things are fine. What sort of Cygwin window are you talking about? Cygwin bash running in a normal Windows console window, or an rxvt or xterm window? The reason for this problem is that the current code uses MSVCRT's spawn to create the process, and that function doesn't provide fine enough control. You have to use CreateProcess to make this work as desired. When invoking CreateProcess, you must set bInheritHandle to TRUE and pass a long a STARTUPINFO structure with dwFlags set to STARTF_USESTDHANDLES, and the various hStd* handle fields set to the values from the calling process. Setting bInheritHandle to TRUE causes the newly created process to inherit all of its parent process's inheritable handles. There's no point in using the STARTUPINFO structure to specify handles for stdin, stdout, and/or stderr unless you're changing them. Since MSVCRT's spawn sets bInheritHandle to TRUE, I don't see what difference this would make. I think you're barking up the wrong tree here. Windows only creates console windows automagically when a console application starts that can't inherit its parent's console window. Either gcc is somehow losing it's console window or it never had one to begin with. Hmm... if that #! kludge is being used here then it could be the shell that's losing the console. Ross Ridge
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, Steven Bosscher wrote: On Friday 03 March 2006 02:46, Alexey Starovoytov wrote: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ Instead of pleased, I'd be ashamed for announcing this. To me Being in hardware org I'm ashamed that SPARC cpus are not performing well with GCC, so I'm pleased that we can do something about it with gcc4ss. it feels like you're announcing with pride how you ripped off gcc. We are proud to make SPARC cpus faster. The users care about performance and reliability of their apps. I don't think it's matter to them how compiler is called or that it's rip off of something else. Inlining happens _before_ all (tree-level and other) optimizations. I have to assume you also looked at GCC close enough to notice. I apologize. Not sure what I was thinking when I wrote that. gcc does inline on tree-level. Fixed that. It is unfortunate, but I guess typical, that Sun has not learned from the mistakes made by others in the past, for example from how SGI tried and failed to pull off the same trick with Pro64. I wasn't making any legal/license decisions. I'm aware of open64, but here is way different imho. What do you think is wrong from GPL point of view? Alex. Gr. Steven
Re: Problem with pex-win32.c
Ross Ridge wrote: Mark Mitchell wrote: The new pex-win32.c code doesn't operate correctly when used for MinGW-hosted tools invoked from a Cygwin window. In particular, process creation (gcc invoking as, say) results in a DOS console window popping up. When invoked from a DOS window, things are fine. What sort of Cygwin window are you talking about? Cygwin bash running in a normal Windows console window, or an rxvt or xterm window? The latter. The reason for this problem is that the current code uses MSVCRT's spawn to create the process, and that function doesn't provide fine enough control. You have to use CreateProcess to make this work as desired. When invoking CreateProcess, you must set bInheritHandle to TRUE and pass a long a STARTUPINFO structure with dwFlags set to STARTF_USESTDHANDLES, and the various hStd* handle fields set to the values from the calling process. Setting bInheritHandle to TRUE causes the newly created process to inherit all of its parent process's inheritable handles. There's no point in using the STARTUPINFO structure to specify handles for stdin, stdout, and/or stderr unless you're changing them. Since MSVCRT's spawn sets bInheritHandle to TRUE, I don't see what difference this would make. I think you're barking up the wrong tree here. Windows only creates console windows automagically when a console application starts that can't inherit its parent's console window. Exactly -- there is no parent console window here. Hence, we need the child (which is a console application) created without a console window, but with its standard input/output connected to its parent. Empirically, if you do not set CREATE_NO_WINDOW dwCreationFlags, a console appears, which is undesirable. However, if you do set CREATE_NO_WINDOW, but do not set the standard handles in the STARTUPINFO structure, the child's standard output/error do not appear anywhere; perhaps they are closed because there is no console. Unfortunately, I've also just found that setting CREATE_NO_WINDOW means that the child's standard output/error do not appear when run from a console. Perhaps we have to actually check whether we already have a console before we can know how to invoke CreateProcess. Either gcc is somehow losing it's console window or it never had one to begin with. Hmm... if that #! kludge is being used here then it could be the shell that's losing the console. No, it's not that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, Andrew Pinski wrote: On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote: Few major infrastructure features needs to be done first. Like? Please give examples. If link time optimizations, that is already starting to be worked on. I doesn't look that my opinion here worth even 1 cent, but here are few things: - inter-proc (link time) opt I think LLVM is a better approach. - 2nd link time opt not re-optimization like above, but asm code optimizations. Looks like LLVM is targeting that as well. Check -xlinkopt flag and BIT - profile driven opt Great progress in 4.1. I'm very interested to see how you can match it with link time opts. - value profiling doesn't look anything is done - openmp I think it needs to be fully platform dependent, but anyway. Certainly would be interesting to compare with Sun's approach. - struct reorg opts very intersting item on gcc's todo list - loop opts Not sure what exactly is being done, but what I can see in 4.0 and 4.1 needs to be improved. Try -xloopinfo for verbosity. - prefetch It rather hurts performance when I tried it. Check -xprefetch* flags - struct type aliasing Great progress in 4.1, but still much behind Sun. Check -xalias_level flag - auto parallelization doesn't look anything is being done here. Check -xautopar - -ffast-math just compare it with Sun's -fsimple=2 - optimized inline assembler All of the above is done by sun compiler and gcc4ss (except openmp). A lot of other things are coming. Also I don't want to start tree vs orc flame, but it seems that Sun's IR is better suited for the above opts. Ok. Ok. It's not. Alex. -- Pinski
Re: GCC for SPARC Systems
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote: - value profiling doesn't look anything is done Done and already in 3.4.0 and improved for the tree level in 4.1.0. - openmp I think it needs to be fully platform dependent, but anyway. Certainly would be interesting to compare with Sun's approach. Done on the mainline. -- Pinski
Re: GCC for SPARC Systems
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote: - prefetch It rather hurts performance when I tried it. Check -xprefetch* flags There is a new tree level prefetching pass on the mainline, maybe you should try it again. -- Pinski
Re: Porting gcj to i386-darwin
On 10/mar/2006, at 20:42, Tom Tromey wrote: libffi and mudflap were covered by Paolo and Andrew. I have done some work on sysv.S and now libffi compiles fine on OSX/ Intel. Unfortunately, I had to put some #ifdef __APPLE__ this file because Apple ships an old cctools with as that doesn't understand some directives. My patch works on the 4.0 branch, I tried it on the 4.2 branch but libffi has changed in such a way that compiling it with the Apple as is not easily feasible (and I don't chew enough assembly code to change it). For libjava some porting may be required, though it shouldn't be very much. libjava compiled out-of-the-box after tweaking the configure scripts. For boehm, I copied the one in the 4.2 branch and applied a patch that Hans should have already put in the current CVS version. For best results you will want to make sure that the code to turn signals into exceptions works properly. This is both OS- and architecture dependent. I haven't looked at the x86 darwin port, perhaps some gcc hacking is required. How can I try this? Is there some test case I can use? Considering all of the above facts, how can I submit a patch, and how much likely it is to be accepted? Anyway, I'm very happy because I can finally use my MacBook Pro for development: our software has a key component that is written in C++ and Java and needs to be compiled in native code, with this patch everything seems to work fine :) Cheers, Sandro smime.p7s Description: S/MIME cryptographic signature
Re: Problem with pex-win32.c
Ross Ridge wrote: I think you're barking up the wrong tree here. Windows only creates console windows automagically when a console application starts that can't inherit its parent's console window. Mark Mitchell wrote: Exactly -- there is no parent console window here. Why isn't there a console window? The Cygwin version of rxvt, and I think xterm, creates (and keeps hidden) a console window that should be inherited by gcc and as. If there wasn't console window for gcc to inherit, why didn't Windows create one for gcc? Maybe gcc was linked with -mwindows. That would cause gcc not have console window, neither an inherited one nor an automagically created one, and so one would have be created for the invoked tools. Hence, we need the child (which is a console application) created without a console window, but with its standard input/output connected to its parent. More precisely, the child should inherit its standard input and output handles from its parent. Empirically, if you do not set CREATE_NO_WINDOW dwCreationFlags, a console appears, which is undesirable. Using CREATE_NO_WINDOW really isn't an option here because it's not supported by Windows 9x/ME. However, if you do set CREATE_NO_WINDOW, but do not set the standard handles in the STARTUPINFO structure, the child's standard output/error do not appear anywhere; perhaps they are closed because there is no console. With CREATE_NO_WINDOW the new process has no attached console. Like a -mwindows application, it neither inherits one, nor is one created for it. Since a process can't use a console other than the one attached to it, there's nowhere for the output to go to. Ross Ridge
Re: GCC for SPARC Systems
On Fri, 2006-03-10 at 14:06 -0800, Alexey Starovoytov wrote: On Fri, 10 Mar 2006, Andrew Pinski wrote: On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote: Few major infrastructure features needs to be done first. Like? Please give examples. If link time optimizations, that is already starting to be worked on. I doesn't look that my opinion here worth even 1 cent, but here are few things: - inter-proc (link time) opt I think LLVM is a better approach. So is Sun moving to it? We are considering it (GCC being we) - 2nd link time opt not re-optimization like above, but asm code optimizations. Looks like LLVM is targeting that as well. Not as far as i know, actually. Check -xlinkopt flag and BIT - struct type aliasing Great progress in 4.1, but still much behind Sun. Check -xalias_level flag Actually, we aren't. I've looked at what Sun does, and the tree level does better in 4.2 than what you do in terms of struct aliasing. The RTL level doesn't. - auto parallelization doesn't look anything is being done here. Check -xautopar This isn't a useful optimization for more than 10% of users, which is why it's not done yet. All of the above is done by sun compiler and gcc4ss (except openmp). A lot of other things are coming. Also I don't want to start tree vs orc flame, but it seems that Sun's IR is better suited for the above opts. Ok. Ok. It's not. The reality is, you can either sit on the sidelines and pretend that GCC isn't going to each your lunch on every other platform in 5-10 years, or you can help make it work well on your platform. Sitting on the sidelines and saying Look, you don't have this, instead of implementing *that thing* is a bit silly.
Re: GCC for SPARC Systems
On Fri, 2006-03-10 at 12:34 -0800, Alexey Starovoytov wrote: On Fri, 10 Mar 2006, David Edelsohn wrote: Alexey Starovoytov writes: If Sun starts improving GCC backend now it will never be able to catch up with Sun's own backend. This is a completely ridiculous assertion. Do you have any evidence to back this up? There is no reason that GCC could not intercept Sun CC if some effort were made. SPARC is not that different from other RISC architectures that GCC supports well. If Sun wants to protect its compiler business, that is fine, but it is a business decision, not a technical decision. So you're saying your team will be able to beat xlc. Ahh. Ok. Good for you. Personally I don't think that sparc gcc backend will be able to catch up with Sun's across the range of tests and benchmarks any time soon. Few major infrastructure features needs to be done first. I'm not here to defend Sun's compilers. The scope of gcc4ss is to deliver performance on SPARC chips. Period. If GCC can beat Sun there. Great! We wouldn't need to do any of this work. You don't seem to get it. GCC isn't going to get better for *your platform* if you just sit on the sidelines. It will get better for those who work on it. This is why it is the way it performs the way it does for SPARC, not because of anything else. I would bet you Sun could intercept Sun CC using GCC within 5 years if they wanted to. HTH, Dan
Re: Problem with pex-win32.c
Ross Ridge wrote:
Why isn't there a console window? The Cygwin version of rxvt, and I
think xterm, creates (and keeps hidden) a console window that should
be inherited by gcc and as. If there wasn't console window for gcc to
inherit, why didn't Windows create one for gcc?
I can't answer that. I will, however, attach test test code I've used;
these are tiny programs, nothing to do with GCC. Compiled as:
i686-mingw32-gcc -o child.exe child.c
i686-mingw32-gcc -o parent.exe parent.c
The child just prints a message.
The parent, based on the command line argument its given, invokes the
child in one of several ways; for example parent spawn uses spawnv to
invoke the child, while parent std uses CreateProcess, with the hStd*
handles filled in and START_USESTDHANDLES.
Here's a table showing what happens:
Cygwin Xterm
parent spawn: Pops up DOS window.
parent nostd: No output from child.
parent std: Works.
DOS Console
===
parent spawn: Works.
parent nostd: No output from child.
parent std: No output from child.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
#include stdio.h
#include process.h
#include string.h
#include windows.h
int main (int arcgc, char **argv) {
fprintf (stderr, Parent started\n);
fflush (stderr);
if (strcmp (argv[1], spawn) == 0) {
const char *const child_argv[2] = { child.exe, NULL };
spawnvp (_P_WAIT, child.exe, child_argv);
} else {
PROCESS_INFORMATION pi;
STARTUPINFO si;
si.cb = sizeof (si);
si.lpReserved = NULL;
si.lpDesktop = NULL;
si.cbReserved2 = 0;
si.lpReserved2 = NULL;
if (strcmp (argv[1], nostd) == 0) {
si.dwFlags = 0;
} else {
si.dwFlags = STARTF_USESTDHANDLES;
si.hStdInput = _get_osfhandle (0);
si.hStdOutput = _get_osfhandle (1);
si.hStdError = _get_osfhandle (2);
}
if (!CreateProcess (child.exe,
child.exe,
NULL,
NULL,
/*bInheritHandles=*/TRUE,
/*dwCreationFlags=*/CREATE_NO_WINDOW,
/*lpEnvironment=*/NULL,
/*lpCurrentDirectory=*/NULL,
si,
pi)) {
fprintf (stderr, Could not start child\n);
} else {
WaitForSingleObject(pi.hProcess, INFINITE);
}
}
fprintf (stderr, Parent done\n);
}
#include stdio.h
int main () {
printf (Child.\n);
return 0;
}
FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET
Morning all! Sorry to bore everyone with old-fashioned 3.x stuff :) but I was just wondering if there's a little loophole here that I may have fallen into? snip `FUNCTION_OK_FOR_SIBCALL (DECL)' A C expression that evaluates to true if it is ok to perform a sibling call to DECL from the current function. It is not uncommon for limitations of calling conventions to prevent tail calls to functions outside the current unit of translation, or during PIC compilation. Use this macro to enforce these restrictions, as the `sibcall' md pattern can not fail, or fall over to a normal call. snip As I understand it, stack frame layout is iteratively converged on in a process that repeatedly calls I_F_P_O, and the final frame size isn't known for sure until the final iteration of this process, yes? However F_O_F_S is called much earlier on in function compilation, before I_F_P_O is even called once. So, what if the decision it needs to make depends on the stack frame size of the current function? The comment above suggests that we can't say OK to it now and refuse to match the sibcall_epilog pattern later by testing in the pattern condition whether the stack frame size is in range and refusing to match if so, as it says we can't fall back. And we can't test this condition at F_O_F_S time, because the stack frame size is still unknown. Is this right? Is get_frame_size() valid at F_O_F_S time, so that we can at least take a best-guess at the final frame size? cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC for SPARC Systems
Alexey Starovoytov writes: Alexey I doesn't look that my opinion here worth even 1 cent, Alexey but here are few things: ... Alexey All of the above is done by sun compiler and gcc4ss (except openmp). Alexey A lot of other things are coming. None of the items you listed are SPARC-specific or absent from other proprietary compilers. You previously said: ... relatively small gap between gcc on x86 and icl [sic] ..., which means that the gap is in the SPARC-specific part of GCC that Sun is ignoring and not fundamental to GCC. If Sun and its partners do not care about GCC performance on SPARC, no one else will do it for them. No points for heckling from the sidelines. The users care about performance and reliability of their apps. I don't think it's matter to them how compiler is called or that it's rip off of something else. This is an oversimplified assertion. A small but lucrative portion of the market cares about the absolute best performance and specific HPC Features, while most of the market cares about good performance and portability. Any customer who wants a proprietary, lock-in compiler solution would chose Sun CC with GCC compatibility, with or without GCC for SPARC. If Sun want customers to have a better experience with GCC, it should help improve GCC. David
Re: Porting gcj to i386-darwin
Sandro == Sandro Tolaini [EMAIL PROTECTED] writes: For best results you will want to make sure that the code to turn signals into exceptions works properly. This is both OS- and architecture dependent. I haven't looked at the x86 darwin port, perhaps some gcc hacking is required. Sandro How can I try this? Is there some test case I can use? Yes, one of the test cases in the libjava test suite checks this. Offhand I forget which one... but if you do a 'make check' and send the list of FAILs we can help analyze them. (This would be better done on the gcj list, [EMAIL PROTECTED]) You can run just these tests by using 'make check' in the libjava build tree. You'll need dejagnu. Sandro Considering all of the above facts, how can I submit a patch, and how Sandro much likely it is to be accepted? There's a bunch of info here: http://gcc.gnu.org/contribute.html The most important thing is dealing with the paperwork. We can help walk you through submitting the patches... these should go to [EMAIL PROTECTED] I think your chances of getting your changes in is very good :-) This port has come up a few times already; if you're set up to test things then we're in great shape. Tom
ICE with GCC 4.1
I have strange ICEs (that come and go as I rearrange the source - like the sequence of include statements). They appear also to affect different files on different machines we compile on. This one here seems to go away if I remove -fprofile-arcs -ftest-coverage from the commandline. It would be great if anyone knows what's going on here and if there's a patch to gcc to fix it. I tried to reproduce the ICE with a precompiled (-E) source and it doesn't show (compiles without a problem). I would really like to provide you (GCC developers) with a sample that reproduces the ICE, but I haven't found a way to do it. Here's a log of the command line to show you the behaviour: [EMAIL PROTECTED] /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ -O0 -pipe -g -D_REENTRANT -DACE_HAS_AIO_CALLS -DACE_USE_RCSID=0 -DACE_HAS_EXCEPTIONS -DOTL_STL -DOTL_ORA10G -DOTL_ORA_TIMESTAMP -DOTL_STREAM_NO_PRIVATE_BOOL_OPERATORS -DOTL_STREAM_NO_PRIVATE_UNSIGNED_LONG_OPERATORS -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -DCOVERAGE -fprofile-arcs -ftest-coverage -m64 -fPIC -Isrc -I/home/lothar/workspace/tradescapeAPI -I/opt2/linux/x86_64/ACE_wrappers -I/opt2/linux/x86_64/ACE_wrappers/TAO -I/opt2/linux/x86_64/ACE_wrappers/TAO/orbsvcs -I/opt2/linux/x86_64/include -I/opt2/linux/x86_64/include/boost-1_33_1 -I/opt2/linux/x86_64/include/python2.4 -I/opt2/linux/x86_64/instantclient10_1/sdk/include -I/opt2/src/otl4/include -c -o src/utility/.build/linux/x86_64/coverage/PythonException.os src/utility/PythonException.cpp /opt2/linux/x86_64/include/boost-1_33_1/boost/python/detail/wrapper_base.hpp:24: warning: unused parameter ‘x’ /opt2/linux/x86_64/include/boost-1_33_1/boost/python/detail/wrapper_base.hpp:82: warning: unused parameter ‘self’ src/utility/PythonException.cpp: In function ‘(static initializers for src/utility/PythonException.cpp)’: src/utility/PythonException.cpp:275: 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. ~/workspace/tradescape [EMAIL PROTECTED] /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ -O0 -pipe -g -D_REENTRANT -DACE_HAS_AIO_CALLS -DACE_USE_RCSID=0 -DACE_HAS_EXCEPTIONS -DOTL_STL -DOTL_ORA10G -DOTL_ORA_TIMESTAMP -DOTL_STREAM_NO_PRIVATE_BOOL_OPERATORS -DOTL_STREAM_NO_PRIVATE_UNSIGNED_LONG_OPERATORS -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -DCOVERAGE -fprofile-arcs -ftest-coverage -m64 -fPIC -Isrc -I/home/lothar/workspace/tradescapeAPI -I/opt2/linux/x86_64/ACE_wrappers -I/opt2/linux/x86_64/ACE_wrappers/TAO -I/opt2/linux/x86_64/ACE_wrappers/TAO/orbsvcs -I/opt2/linux/x86_64/include -I/opt2/linux/x86_64/include/boost-1_33_1 -I/opt2/linux/x86_64/include/python2.4 -I/opt2/linux/x86_64/instantclient10_1/sdk/include -I/opt2/src/otl4/include -E -o src/utility/PythonException.cpp.cpp src/utility/PythonException.cpp ~/workspace/tradescape [EMAIL PROTECTED] /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ -O0 -pipe -g -D_REENTRANT -DACE_HAS_AIO_CALLS -DACE_USE_RCSID=0 -DACE_HAS_EXCEPTIONS -DOTL_STL -DOTL_ORA10G -DOTL_ORA_TIMESTAMP -DOTL_STREAM_NO_PRIVATE_BOOL_OPERATORS -DOTL_STREAM_NO_PRIVATE_UNSIGNED_LONG_OPERATORS -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -DCOVERAGE -fprofile-arcs -ftest-coverage -m64 -fPIC -c -o src/utility/.build/linux/x86_64/coverage/PythonException.os src/utility/PythonException.cpp.cpp /opt2/linux/x86_64/include/boost-1_33_1/boost/python/detail/wrapper_base.hpp:24: warning: unused parameter ‘x’ /opt2/linux/x86_64/include/boost-1_33_1/boost/python/detail/wrapper_base.hpp:82: warning: unused parameter ‘self’ ~/workspace/tradescape Lothar
g++ 4.1.0/4.2.x, x86/x86-64, segfaults due to bogus SSE alignments
This bug is really transient, and AFAIK i only trigger it when using
the cluebat on g++, that is bloating every function in sight
appropriately with always_inline/noinline attributes, in a unit that
inflates much.
Tracked one occurence to something like that:
union float4_t {
float f[4];
__m128 v;
...
};
static void foobar() {
float4_t __attribute__((aligned (16))) bar;
...
__m128 foo;
...
bar = foo;
}
If i let g++ decide if foobar() should be inlined or not, everything's
fine (but performance of course). Then if i force_inline foobar() i
may or may not get something to the effect of:
40666a: movaps %xmm0,0x348(%esp)
406672: mov0x348(%esp),%eax
406679: mov%eax,0x310(%esp)
406680: mov0x34c(%esp),%eax
406687: movaps 0x210(%esp),%xmm0
40668f: mov%eax,0x314(%esp)
406696: mov0x350(%esp),%eax
40669d: movaps %xmm0,0x40(%esp)
4066a2: mov%eax,0x318(%esp)
4066a9: mov0x354(%esp),%eax
Why that value gets suddenly copied around, i don't know. It doesn't
matter much anyway, as the program won't survive past the bogus store.
It's not just related to that kind of mixed unions either, and again
it clearly depends on surrounding functions being force_inlined and
noinlined and lots of stuff ending up on the stack.
I can trigger it on cygwin and linux, with g++ 4.1.0 and various 4.2.x
and once triggered using -0s or -Ox doesn't matter; it's been there
for a long time but that's the first time i can track it down somehow
(inlining heuristics being extremly anyway).
I haven't made a bugreport yet, as that would require disclosing large
amounts of code, but i'd like to know if it's a known issue by any
chance.
Regards,
tbp.
autogen -T ../../trunk/fixincludes/check.tpl ../../trunk/fixincludes/inclhack.def
Gentlemen, I get the following building 111952 (all languages except treelang): /home/toon/compilers/obj-t/./gcc/gfortran -B/home/toon/compilers/obj-t/./gcc/ -B/usr/snp/x86_64-unknown-linux-gnu/bin/ -B/usr/snp/x86_64-unknown-linux-gnu/lib/ -isystem /usr/snp/x86_64-unknown-linux-gnu/include -isystem /usr/snp/x86_64-unknown-linux-gnu/sys-include -g -O2 -Wall -fsyntax-only omp_lib.f90 make[4]: Leaving directory `/home/toon/compilers/obj-t/x86_64-unknown-linux-gnu/libgomp' make[3]: Leaving directory `/home/toon/compilers/obj-t/x86_64-unknown-linux-gnu/libgomp' make[2]: Leaving directory `/home/toon/compilers/obj-t/x86_64-unknown-linux-gnu/libgomp' make[1]: Leaving directory `/home/toon/compilers/obj-t' make[1]: Entering directory `/home/toon/compilers/obj-t' make[2]: Entering directory `/home/toon/compilers/obj-t/fastjar' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/home/toon/compilers/obj-t/fastjar' make[2]: Entering directory `/home/toon/compilers/obj-t/fixincludes' autogen -T ../../trunk/fixincludes/check.tpl ../../trunk/fixincludes/inclhack.def make[2]: autogen: Command not found -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ My next laptop will have a crank
Re: autogen -T ../../trunk/fixincludes/check.tpl ../../trunk/fixincludes/inclhack.def
On Mar 10, 2006, at 10:13 PM, Toon Moene wrote: autogen -T ../../trunk/fixincludes/check.tpl ../../trunk/fixincludes/inclhack.def make[2]: autogen: Command not found Maybe we should change this to be autogen || true so that we don't get that many complaints about this. Anyways the recommeneded way to run the testsuite is make -k check. This is not really an error but a warning that autogen was not found and fixincludes checking is almost never really need to be worried about either. -- Pinski
Re: g++ 4.1.0/4.2.x, x86/x86-64, segfaults due to bogus SSE alignments
On Sat, Mar 11, 2006 at 03:43:45AM +0100, tbp wrote: I haven't made a bugreport yet, as that would require disclosing large amounts of code, but i'd like to know if it's a known issue by any chance. Unlikely, since you haven't described at all what the problem is. That's why we prefer bug reports with testcases. -- Daniel Jacobowitz CodeSourcery
GCC 4.0.3 Released
GCC 4.0.3 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC 4.0.3 contains changes to correct regressions from previous releases, but no new features. GCC 4.1.0 is the most current release of GCC and is our recommended version for most users. However, current users of 4.0.0, 4.0.1, or 4.0.2 who are unable upgrade to 4.1.0 may wish to upgrade to 4.0.3. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.0.3 subdirectory. If you encounter any difficulties using GCC 4.0.3, please do not send them directly to me. Instead, please http://gcc.gnu.org/ for information about getting help and filing problem reports. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.0 branch open
The GCC 4.0 branch is now open, under the usual release-branch rules. However, I do not plan to make any further releases from the 4.0 branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: g++ 4.1.0/4.2.x, x86/x86-64, segfaults due to bogus SSE alignments
On 3/11/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: Unlikely, since you haven't described at all what the problem is. That's why we prefer bug reports with testcases. ...segfaults due to bogus SSE alignments 40666a: movaps %xmm0,0x348(%esp)
Re: GCC for SPARC Systems
I apologize in advance if this is a bit long or off-topic, but you might be interested to hear first-hand what some of current Sun customers have to say. On Fri, 10 Mar 2006, Alexey Starovoytov wrote: On Fri, 10 Mar 2006, Steven Bosscher wrote: On Friday 03 March 2006 02:46, Alexey Starovoytov wrote: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ This kind of attitude shows, once more, how much your company still has to learn to reach to free software users and understand what they mean by 'community', 'free' and 'appealing'. (hint: 'free' is not free-beer and 'community' is not a group listening to a coordinator) Instead of pleased, I'd be ashamed for announcing this. Especially to this audience! Being in hardware org I'm ashamed that SPARC cpus are not performing well with GCC, so I'm pleased that we can do something about it with gcc4ss. slightly off-topic Well, these days one should be ashamed at SPARC performance, period. GCC is the least of SPARC's problems. Our lab is a large Genome center which used to be SPARC/Solaris-only, and remember when I joined two years ago and argued with our scientists about why I personally ditched SPARCs for cpu-intensive tasks around 1995 (ah, the late Alpha chip, sob!) and couldn't come close to performance of GNU/Linux on Pentiums since 1999. Showing people that for some of our high-performance bioinformatics applications, I would crush a $30,000 2-CPU V880 UltraSparc 1.2GHz with my $2,000 Dell PentiumIV laptop was, I would say, an eye opener. I am glad Sun has seen the light in terms of hardware and has been selling AMD Opterons (very nice ones by the way) for the last couple of years, which is the only way they could stay in the server/workstation business with us (we bought a lot of their Opteron boxes here, all models). They haven't got it yet for laptops apparently, given the recently announced Ultra-3 SPARC-based line (which my Acer Ferrari will eat for breakfast in energy-saving mode). As for niagara chips, I will consider it the day GNU/Linux and GCC run on it. I can tell you that what we call performance today in my field is called dual-core-Opterons, GNU/Linux and GCC. We let our SPARCs do legacy, file-serving and non-performance tasks, trying to get all our university students off them as well so that they don't get disgusted of Unix by exposure to Solaris, java desktop and X terminals (we give them KDE/GNU/Linux on Opteron workstations). We will publish various performance metrics when time permits in the coming months on Single/Dual core Sun Opterons with GCC-4.1.0 on Fedora Core 5 and GCC-3.4.4 on Fedora Core 3. /slightly off-topic it feels like you're announcing with pride how you ripped off gcc. We are proud to make SPARC cpus faster. The users care about performance and reliability of their apps. I don't think it's matter to them how compiler is called or that it's rip off of something else. You are wrong, and in my case by a long shot. First because, as an engineer I do not like inefficent processes consisting in making something slightly better if you are in a position to contribute to it and make it a lot better. Second because having worked 15 years in the field of genomics and bioinfromatics, I can tell you that the sequencing of genomes and molecular understanding of biology that was produced over the last two decades owes pretty much everything to the power of open raw data access and free software to handle it, for which GCC can claim to be a cornerstone. I have witnessed this in academia, biotechs and large pharma companies. We (creators and users of this information) have been _delayed_ by attitudes like yours. So you are not bringing performance, you are reaping short-term gains but preventing larger ones by not putting your energy where it would have the most impact. So please start contributing to GCC, and then we will consider looking at what you are doing. And thank you very much to all GCC developpers. Best regards, -- Philippe Rigault (GCC user since 1990). Bioinformatics Director, Centre de Génomique de Québec
Re: 4.1.0 install mistake in libssp
On Wed, 2006-03-08 at 16:43 -0600, Joel Sherrill wrote: Andreas Schwab wrote: Joel Sherrill [EMAIL PROTECTED] writes: RPM invoked make install with the prefixes overriden: make prefix=/home/rtems/tmp/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.1.0newlib1.14.0-1-root-rtems/opt/rtems-4.7 Why don't you just set DESTDIR? Wasn't needed for years before now. :) Umm, that's not quite correct. We could not use DESTDIR for older GCCs, because it was not supported in and/or broken in GCC [1]. Until GCC-4.1, non-DESTDIR installs continued to work, therefore we continued using non-DESTDIR installs, because we had wanted to keep compatibility of our build scripts (actually rpm specs) to older GCCs - Now, non-DESTDIR installs seem to be broken. Doing that and tweaking the RPM spec to create the info directory if it didn't get done by make install-info seem to have resolved things. Similar considerations as above apply to info handling. Throughout GCC's history make info|install-info had sometimes been required and sometimes not. For the sake of simplicity we kept on using them, though they aren't required for quite a while (newlib-infos are still not handled by GCC's toplevel configurations). Ralf [1] Several subpackages in GCC did not support DESTDIR.
Re: gcc-4.2-20060304 is now available
Gerald Pfeifer wrote: Looking at the current sizes gcc-core-4.2-20060304.tar.bz2 = 15703096 gcc-g++-4.2-20060304.tar.bz2 = 3905138 gcc-objc-4.2-20060304.tar.bz2 = 191280 gcc-fortran-4.2-20060304.tar.bz2 = 793478 gcc-testsuite-4.2-20060304.tar.bz2 = 3606941 I'd really suggest to make this part of gcc-objc instead of adding another one. Definitely. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: gcc-4.2-20060304 is now available
On Mar 11, 2006, at 1:04 AM, Mark Mitchell wrote: Gerald Pfeifer wrote: Looking at the current sizes gcc-core-4.2-20060304.tar.bz2 = 15703096 gcc-g++-4.2-20060304.tar.bz2 = 3905138 gcc-objc-4.2-20060304.tar.bz2 = 191280 gcc-fortran-4.2-20060304.tar.bz2 = 793478 gcc-testsuite-4.2-20060304.tar.bz2 = 3606941 I'd really suggest to make this part of gcc-objc instead of adding another one. Definitely. Wouldn't that make you dowload gcc-core, gcc-g++ and gcc-objc to just to compile an objective-C compiler as objcp depends on c++ also? -- Pinski
Re: Porting gcj to i386-darwin
On 11/mar/2006, at 02:09, Tom Tromey wrote: Yes, one of the test cases in the libjava test suite checks this. Offhand I forget which one... but if you do a 'make check' and send the list of FAILs we can help analyze them. (This would be better done on the gcj list, [EMAIL PROTECTED]) This is the result of make test in the libgcj directory. There are some unexpected failures, as you can see: Test Run By sandro on Sat Mar 11 07:42:56 2006 Native configuration is i686-apple-darwin8.5.2 === libjava tests === Schedule of variations: unix Running target unix Using /Users/sandro/staging/share/dejagnu/baseboards/unix.exp as board description file for target. Using /Users/sandro/staging/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/sandro/gcc-4.0.2/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.cni/ cni.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.compile/ compile.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jacks/ jacks.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jar/ jar.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jni/ jni.exp ... FAIL: PR15133 execution - gij test FAIL: cxxtest execution - gij test FAIL: directbuffer execution - gij test FAIL: martin execution - gij test FAIL: noclass execution - gij test FAIL: pr11951 run FAIL: throwit execution - gij test Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.lang/ lang.exp ... FAIL: ArrayStore execution - gij test FAIL: ArrayStore execution - gij test FAIL: Array_3 execution - source compiled test FAIL: Array_3 execution - gij test FAIL: Array_3 execution - bytecode-native test FAIL: Array_3 -O3 execution - source compiled test FAIL: Array_3 execution - gij test FAIL: Array_3 -O3 execution - bytecode-native test FAIL: Divide_1 execution - source compiled test FAIL: Divide_1 execution - bytecode-native test FAIL: Divide_1 -O3 execution - source compiled test FAIL: Divide_1 -O3 execution - bytecode-native test FAIL: FileHandleGcTest execution - gij test FAIL: FileHandleGcTest execution - gij test FAIL: Invoke_1 execution - source compiled test FAIL: Invoke_1 execution - bytecode-native test FAIL: Invoke_1 -O3 execution - source compiled test FAIL: Invoke_1 -O3 execution - bytecode-native test FAIL: PR218 execution - source compiled test FAIL: PR218 execution - gij test FAIL: PR218 execution - bytecode-native test FAIL: PR218 -O3 execution - source compiled test FAIL: PR218 execution - gij test FAIL: PR218 -O3 execution - bytecode-native test FAIL: Process_5 execution - gij test FAIL: Process_5 execution - gij test FAIL: Process_6 execution - gij test FAIL: Process_6 execution - gij test FAIL: StringBuffer_1 execution - gij test FAIL: StringBuffer_1 execution - gij test FAIL: StringBuffer_overflow execution - gij test FAIL: StringBuffer_overflow execution - gij test FAIL: String_overflow execution - gij test FAIL: String_overflow execution - gij test FAIL: Thread_Alive execution - gij test FAIL: Thread_Alive execution - gij test FAIL: Thread_Interrupt execution - gij test FAIL: Thread_Interrupt execution - gij test FAIL: Thread_Wait_2 execution - gij test FAIL: Thread_Wait_2 execution - gij test FAIL: Thread_Wait_Interrupt execution - gij test FAIL: Thread_Wait_Interrupt execution - gij test FAIL: Throw_2 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 execution - bytecode-native test FAIL: Throw_2 -O3 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 -O3 execution - bytecode-native test FAIL: instinit2 execution - gij test FAIL: instinit2 execution - gij test FAIL: invokethrow execution - source compiled test FAIL: invokethrow execution - gij test FAIL: invokethrow execution - bytecode-native test FAIL: invokethrow -O3 execution - source compiled test FAIL: invokethrow execution - gij test FAIL: invokethrow -O3 execution - bytecode-native test Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.loader/ loader.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.mauve/ mauve.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.verify/ verify.exp ... === libjava Summary === # of expected passes3687 # of unexpected failures63 # of expected failures 14 # of untested testcases 79 smime.p7s Description: S/MIME cryptographic signature
Re: GCC 4.0.3 Released
GCC 4.0.3 has been released. You need to add a link on the page http://gcc.gnu.org/gcc-4.0 Similarly for the 4.1.0 release on the page http://gcc.gnu.org/gcc-4.1 And don't you need to display the release date instead of current changes for 4.1.0 on the main page? -- Eric Botcazou
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #15 from kloedej at knmi dot nl 2006-03-10 08:27 --- (In reply to comment #14) All I'm saying is that in this situation there seems to be no way to jump to some label if something goes wrong (because there is no EOR parameter for WRITE). But I agree that this is not gfortran's problem, but rather an inconsistency in the standard. Dear people, thanks a lot for the discussion following my bug-report. The situation is clear to me now, and I agree this is not a real gfortran bug, but a problem in the standard. By the way, is there a way to warn/advise users to rather use the iostat keyword in stead of the err/end keywords in these problematic situations? In other words, is it possible for gfortran to detect potential problems like this, and then issue a warning, in addition to stopping with a runtime error? best regards, Jos de Kloe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug bootstrap/26628] Build fails trying to run ppc64 binaries on powerpc-apple-darwin8.5.0
--- Comment #2 from malcolmpurvis at optushome dot com dot au 2006-03-10 08:40 --- (In reply to comment #1) Use --disable-multilib. This has fixed the problem. Thank you. However, I would query the determination that this is not a bug. I don't expect the default configuration of a common system in an official release to fail. Either multilib should be disabled by default for this target or special mention of be made in INSTALL/specific.html (as I have subsequently discovered the case for mips-sgi-irix6 and sparc-sun-solaris2*). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26628
[Bug c++/26605] using + function templates troubles
--- Comment #12 from pcarlini at suse dot de 2006-03-10 09:38 --- I sent a message to the CWG reflector, and people kindly replied (c++std-core-11367 to 11370). In a nutshell, 7.3.3/11 should be clarified for function templates (a new issue has been opened), but apparently there is consensus that Comment #1 below is invalid while Comment #0 is fine (because the return types are different, and return types matter for function templates [14.5.5.1p4]). However, the first snippet is actually the same issue of c++/21682 and therefore I'm closing this one as duplicate. *** This bug has been marked as a duplicate of 21682 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/21682] Disallowed using declaration
--- Comment #3 from pcarlini at suse dot de 2006-03-10 09:38 --- *** Bug 26605 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-10 10:40 --- The testcase is also full of problems itself... - changing rv to a type with the size of U, we no longer ICE. Also -fno-strict-aliasing fixes the ICE. I'm curious on how the original code looks like before reduction... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #8 from mueller at gcc dot gnu dot org 2006-03-10 10:51 ---
shorter testcase:
=== Cut ===
typedef union {
int d;
int L;
} U;
void breakme()
{
int rv;
ovfl:
((U*)rv)-d = 42;
if (((U*)rv)-L)
goto ovfl;
}
=== Cut ===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-03-10 11:10 ---
L2:;
pretmp.23_2 = (union U *) rv;
# NMT.6_4 = PHI NMT.6_5(2), NMT.6_6(5);
ovfl:;
rv.0_1 = pretmp.23_2;
# NMT.6_6 = V_MAY_DEF NMT.6_4;
rv.0_1-d = 42;
# VUSE NMT.6_6;
D.1529_3 = rv.0_1-L;
if (D.1529_3 != 0) goto L5; else goto L1;
L5:;
goto bb 3 (ovfl);
we prop pretmp.23_2 to rv.0_1 in rv.0_1-d = 42 -- but we don't have the
NMT associated with pretmp.23_2:
$5 = {pt_anything = 0, value_escapes_p = 0, is_dereferenced = 0,
pt_global_mem = 0, pt_null = 0, pt_vars = 0xb7dec890, name_mem_tag = 0x0,
escape_mask = 0}
As we have in alias after PRE:
Pointed-to sets for pointers in breakme
pretmp.23_2, points-to vars: { rv }
rv.0_1, name memory tag: NMT.6, is dereferenced, points-to vars: { rv }
which looks inconsistent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug c++/26621] Template instantiation fails for -O1 -finline-functions
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-10 11:24 --- You need to make all templated definitions available in check_link.cc or explicitly instantiate all used templates in check_link.cc. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug c/26630] New: Incorrect result when subtracting, casting to short and back to int, adding and multiplying
As far as I can tell, c1 should be equal to 8, not -51072, or at least
equal to c2.
Sorry if I'm mistaken, but I can't see how c1 and c2 can be different. The
result is the same using gcc 3.3.6, gcc 3.4.4 and gcc 4.0.2.
Program (error.c):
-
#include stdio.h
int main()
{
int a1 = 4;
#define b1 ((int)(short)(a1-1))
int c1 = ( b1 +1)*2;
int a2 = 4;
int b2 = ((int)(short)(a2-1));
int c2 = ( b2 +1)*2;
printf(sizeof(int) = %d, sizeof(short) = %d\na1 = %d, b1 = %d, c1 = %d\na2
= %d, b2 = %d, c2 = %d (c1 and c2 should both be 8)\n,
sizeof(int), sizeof(short), a1, b1, c1,
a2, b2, c2);
if( c1!=8 || c2!=8 )
{
printf(Error!\n);
return 1;
}
return 0;
}
--
Output:
[EMAIL PROTECTED] ~/tmp $ cat /proc/version
Linux version 2.6.15-gentoo-r1 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Gentoo
3.3.6,
ssp-3.3.6-1.0, pie-8.7.8)) #1 PREEMPT Wed Jan 25 11:58:26 CET 2006
[EMAIL PROTECTED] ~/tmp $ gcc-3.3.6 -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
Configured with: /var/tmp/portage/gcc-3.3.6/work/gcc-3.3.6/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.6
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6/info
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
[EMAIL PROTECTED] ~/tmp $ gcc-3.3.6 -o error error.c -Wall
[EMAIL PROTECTED] ~/tmp $ ./error
sizeof(int) = 4, sizeof(short) = 2
a1 = 4, b1 = 3, c1 = -51072
a2 = 4, b2 = 3, c2 = 8 (c1 and c2 should both be 8)
Error!
[EMAIL PROTECTED] ~/tmp $ gcc-3.4.4 -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libmudflap --disable-libgcj --enable-languages=c,c++,f77
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
[EMAIL PROTECTED] ~/tmp $ gcc-3.4.4 -o error error.c -Wall
[EMAIL PROTECTED] ~/tmp $ ./error
sizeof(int) = 4, sizeof(short) = 2
a1 = 4, b1 = 3, c1 = -51072
a2 = 4, b2 = 3, c2 = 8 (c1 and c2 should both be 8)
Error!
[EMAIL PROTECTED] ~/tmp $ gcc-4.0.2 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.0.2-r3/work/gcc-4.0.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.0.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libmudflap --disable-libgcj --enable-languages=c,c++,f95
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8)
[EMAIL PROTECTED] ~/tmp $ gcc-4.0.2 -o error error.c -Wall
[EMAIL PROTECTED] ~/tmp $ ./error
sizeof(int) = 4, sizeof(short) = 2
a1 = 4, b1 = 3, c1 = -51072
a2 = 4, b2 = 3, c2 = 8 (c1 and c2 should both be 8)
Error!
[EMAIL PROTECTED] ~/tmp $
--
Summary: Incorrect result when subtracting, casting to short and
back to int, adding and multiplying
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc
[Bug tree-optimization/26629] tree load PRE does not work on array references
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-10 12:50 ---
Here is another testcase:
typedef long dtype;
typedef dtype longarray[];
int g (longarray *array1, unsigned long i, dtype j)
{
if (!(*array1)[i])
i++;
if (j (*array1)[i])
h();
return i;
}
int g1 (longarray *array1, unsigned long i, dtype j)
{
dtype a = (*array1)[i];
if (!a)
{
i++;
a = (*array1)[i];
}
if (j a)
h();
return i;
}
FRE handles this just fine, it is PRE which does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26629
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-10 12:57 --- Confirmed, just a regression on the 4.0 branch, 3.4.6 was the last release of the 3.4 branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||3.4.0 4.0.0 4.0.3 3.3.3 ||3.0.4 Known to work||2.95.3 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-10 12:57:24 date|| Summary|Incorrect result when |[4.0 Regression] Incorrect |subtracting, casting to |result when subtracting, |short and back to int, |casting to short and back to |adding and multiplying |int, adding and multiplying Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug tree-optimization/26629] tree load PRE does not work on array references
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-10 12:59 ---
(In reply to comment #1)
FRE handles this just fine, it is PRE which does not.
Let me clarify that comment, For FRE I am talking about code like:
typedef long dtype;
typedef dtype longarray[];
int g (longarray *array1, unsigned long i, dtype j)
{
if (!(*array1)[i])
j++;
if (j (*array1)[i])
h();
return i;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26629
[Bug tree-optimization/26524] [4.1 Regression] ICE when compiling with -ffast-math and -O3 clatm5.f (lapack)
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-10 13:00 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26524
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-10 13:52 --- We fold ((intD.0) ((short intD.7) a1D.1133 - 1) + 1) * 2 via extract_muldiv to (intD.0) (short intD.7) a1D.1133 * 2 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-10 13:53 ---
shorter testcase:
extern void abort(void);
int main()
{
int a1 = 4;
int c1 = ( ((int)(short)(a1-1)) + 1)*2;
if (c1 != 8)
abort();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug c++/26621] Template instantiation fails for -O1 -finline-functions
--- Comment #5 from _talyn_ at web dot de 2006-03-10 13:54 --- Created an attachment (id=11015) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11015action=view) test case that shows the difference between dynamic/static alloc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug rtl-optimization/21485] [4.0/4.1/4.2 Regression] codegen regression due to PRE increasing register pressure
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-03-10 13:56
---
What happens to the time if you replace that function with:
void
NumSift (long *array, unsigned long i, unsigned long j)
{
unsigned long k;
while ((i + i) = j)
{
k = i + i;
long t, t1;
t = array[k];
if (k j)
{
t1 = array[k+1];
if (t t1)
++k, t = t1;
}
t1 = array[i];
if (t1 t)
{
array[k] = t1;
array[i] = t;
i = k;
}
else
i = j + 1;
}
return;
}
---
The semantics should be the same, I just pulled out the PREs as much as I
could.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug c++/26621] Template instantiation fails for -O1 -finline-functions
--- Comment #6 from _talyn_ at web dot de 2006-03-10 13:56 --- (From update of attachment 11015) Certainly, I see your point with respect to the get* methods, a hint in the g++-4.X release notes about the more aggressive inlining would probably be helpful. However, this doesn't explain, why the reference to TTypeWrapper::~TTypeWrapper is missing if the instance of CVectorWrap is allocated statically, and it is not missing, if it is allocated dynamically. The VMT of CVectorWrap should be created with instance.o the reference to TTypeWrapper::~TTypeWrapper will be needed there. Hence, it should be instanciated automatically, and creating CVectorWrap dynamically seems to proof that indeed it is. Explicit instanciation is a orkaround, but IMHO it is not the solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug c++/26621] Template instantiation fails for -O1 -finline-functions
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-10 13:58 --- Subject: Re: Template instantiation fails for -O1 -finline-functions However, this doesn't explain, why the reference to TTypeWrapper::~TTypeWrapper is missing if the instance of CVectorWrap is allocated statically, and it is not missing, if it is allocated dynamically. The VMT of CVectorWrap should be created with instance.o the reference to TTypeWrapper::~TTypeWrapper will be needed there. Hence, it should be instanciated automatically, and creating CVectorWrap dynamically seems to proof that indeed it is. Explicit instanciation is a orkaround, but IMHO it is not the solution. divirtualization is really what is happening and not inlining. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug rtl-optimization/21485] [4.0/4.1/4.2 Regression] codegen regression due to PRE increasing register pressure
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-03-10 14:10 --- (In reply to comment #17) What happens to the time if you replace that function with: This helps about 5% but it does not get the score back up. 3.4.0's score for this machine is about 900. 4.1.0's score is 720. 4.1.0+scource modification is about 780. so it helps but there is something else which needs to be improved still. I don't think this is a RA issue now after looking into the source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords|ra | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug rtl-optimization/21485] [4.0/4.1/4.2 Regression] codegen regression due to PRE increasing register pressure
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-03-10 14:13 --- (In reply to comment #18) (In reply to comment #17) What happens to the time if you replace that function with: This helps about 5% but it does not get the score back up. Also the asm is about the same for this function, at least on i686 between 3.4.0 and the source modified version with 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-10 14:31 --- with 4.1 we start with ((intD.0) (short intD.7) ((short unsigned intD.8) a1D.1280 - 1) + 1) * 2 which convert builds from converting a - 1 to short: (short intD.7) ((short unsigned intD.8) a1D.1280 - 1) this prevents the (now latent) problem in extract_muldiv to show up. I believe case CONVERT_EXPR: case NON_LVALUE_EXPR: case NOP_EXPR: /* If op0 is an expression ... */ if ((COMPARISON_CLASS_P (op0) || UNARY_CLASS_P (op0) || BINARY_CLASS_P (op0) || EXPRESSION_CLASS_P (op0)) /* ... and is unsigned, and its type is smaller than ctype, then we cannot pass through as widening. */ ((TYPE_UNSIGNED (TREE_TYPE (op0)) ! (TREE_CODE (TREE_TYPE (op0)) == INTEGER_TYPE TYPE_IS_SIZETYPE (TREE_TYPE (op0))) (GET_MODE_SIZE (TYPE_MODE (ctype)) GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0) /* ... or this is a truncation (t is narrower than op0), then we cannot pass through this narrowing. */ || (GET_MODE_SIZE (TYPE_MODE (type)) GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0 the last check needs to read !=, but this extract_muldiv looks like a mess... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug c/26632] New: spurious warning: value computed is not used
Using gcc 4.1.0 on amd64, with -Wall (64 bit target):
int g(void);
long h(void);
void f(void)
{
0 ? h() : g();
}
foo.c:6: warning: value computed is not used
Either changing 0 to 1 or swapping g and h makes the warning go away.
This was the result of a (very reasonable) macro expansion.
--
Summary: spurious warning: value computed is not used
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mattias at virtutech dot se
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=26632
[Bug middle-end/26632] spurious warning: value computed is not used
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-10 15:16 --- Hmm, what is going on here is the following. 0 ? h() : g(); is not really just that but instead: 0 ? h() : (long)g(); which then gets foldded into: (long)g(); and we warn about the cast. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
[Bug middle-end/26632] [4.1/4.2 Regression] spurious warning: value computed is not used
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-10 15:17 --- I don't know if we should be warning or not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||diagnostic Summary|spurious warning: value |[4.1/4.2 Regression] |computed is not used|spurious warning: value ||computed is not used Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
[Bug middle-end/19430] Missing uninitialized warning
--- Comment #7 from ciaccio at disi dot unige dot it 2006-03-10 15:25
---
An even simpler test case of this bug (tested with gcc 3.4.5):
int main( void ) {
int rc;
return rc;
*rc = 0;
}
gcc -O -Wall program.c
(more stunning silence)
NOTE: in this example, there is no function invocation inside main().
NOTE: remove the last statement in the program, and the warning will show up.
g.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug middle-end/19430] Missing uninitialized warning
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-10 15:28 --- (In reply to comment #7) An even simpler test case of this bug (tested with gcc 3.4.5): That works correctly in 4.0.0 and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug middle-end/26632] [4.1/4.2 Regression] spurious warning: value computed is not used
--- Comment #3 from mattias at virtutech dot se 2006-03-10 15:30 --- Yes, I realise it's the implicit integral conversion that causes the warning, but since the result is not used no matter what it seems wrong to warn for it - it cannot reasonably a sign of an error in the code. It can be hard to avoid unless the exact types and sizes are known - for instance, adding (long) casts to both branches will not prevent the warning from being generated. This causes headaches with -Werror. In fact, adding an (int) cast before h() will suppress the warning but a (long) cast before g() will not. I see no sensible way of getting rid of the warning at all, save casting the whole result to void (which isn't desirable for a function-like macro). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
[Bug middle-end/19430] Missing uninitialized warning
--- Comment #9 from dnovillo at gcc dot gnu dot org 2006-03-10 15:31 --- Not going to work on this problem any time soon. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug tree-optimization/13962] [tree-ssa] make fold use alias information to optimize pointer comparisons
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
[Bug tree-optimization/20168] const function causes the creation of GLOBAL_VAR
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-03-10 15:36 --- Fixed in 4.2. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20168
[Bug middle-end/19430] Missing uninitialized warning
--- Comment #10 from mike at codeweavers dot com 2006-03-10 15:37 --- Can I bribe you to work on it by fixing a Wine bug in exchange? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug tree-optimization/22254] We never call may_alias_p for PARM_DECL's
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-03-10 15:45 --- The two pointers are assigned the same SMT. Is this still a problem? Dereferenced pointers D.1541, UID 1541, int *, symbol memory tag: SMT.5 D.1542, UID 1542, int *, symbol memory tag: SMT.5 Or do you need to analyze g1 and g2? -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22254
[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-03-10 16:07 --- Not working on this anymore. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug c++/26633] New: Minimal c++ program using threads and exceptions crashes when compiled statically
The below does not crash with g++ 4.0.2, nor when removing -static:
(see also http://ds9a.nl/minimal.cc.txt)
#include stdexcept
/*
compiled with g++ 4.1.0 (g++ minimal.cc -o minimal -static -pthread), on
Ubuntu Breezy:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure --prefix=/opt/gcc-4.1/
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-debug
Thread model: posix
gcc version 4.1.0
Crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 8238)]
__gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
58get_global() throw()
Current language: auto; currently c++
(gdb) bt
#0 __gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
#1 0x0804c767 in __cxa_get_globals () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:71
#2 0x0804c33f in __cxa_allocate_exception (thrown_size=8)
at ../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_alloc.cc:154
#3 0x08048298 in doStuff ()
#4 0x080577af in pthread_start_thread (arg=0xaf5ffbe0) at manager.c:310
#5 0x08057827 in pthread_start_thread_event (arg=0xaf5ffbe0) at manager.c:334
#6 0x08069d9a in clone ()
*/
void *doStuff(void *)
try
{
throw std::runtime_error(boe);
}
catch(std::exception e)
{}
int main()
{
pthread_t tid;
pthread_create(tid, 0, doStuff,0);
void *result;
pthread_join(tid, result);
}
--
Summary: Minimal c++ program using threads and exceptions crashes
when compiled statically
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ahu at ds9a dot nl
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=26633
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-10 16:17 --- The patch from 25125 fixes the problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25125 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC build triplet|i686-pc-linux-gnu-gcc-3.3.6 | GCC host triplet|i686-pc-linux-gnu-gcc-3.3.6 | GCC target triplet|i686-pc-linux-gnu-gcc-3.3.6 | Last reconfirmed|2006-03-10 12:57:24 |2006-03-10 16:17:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #6 from patchapp at dberlin dot org 2006-03-10 16:25 --- Subject: Bug number PR26630 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/2006-03/msg00616.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug c++/25322] ISO compliance of defining structs in anonymous unions
--- Comment #3 from jvalenzu at infinite-monkeys dot org 2006-03-10 16:25 --- Would someone mind specifying what section of the standard this violates? We have a codebase that makes heavy use of (3). -- jvalenzu at infinite-monkeys dot org changed: What|Removed |Added CC||jvalenzu at infinite-monkeys ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25322
[Bug c/26634] New: spurious strtok_r warning with -Wwrite-strings
I'm not sure whether to report this to gcc or glibc - maybe it falls
in-between.
#include string.h
void g(char *);
void f(char *a)
{
char *p, *q;
while ((q = strtok_r(a, :, p)))
g(q);
}
with -O1 -Wall -Wwrite-strings, gives:
warning: 'p' may be used uninitialized in this function
This comes from the inline expansion of strtok_r(), after reduction:
extern __inline char *
__strtok_r_1c (char *__s, char __sep, char **__nextp)
{
char *__result;
if (__s == ((void *)0))
__s = *__nextp;
while (*__s == __sep)
++__s;
__result = ((void *)0);
if (*__s != '\0')
{
__result = __s++;
while (*__s != '\0')
if (*__s++ == __sep)
{
__s[-1] = '\0';
break;
}
*__nextp = __s;
}
return __result;
}
void g(char *);
void f(char *a)
{
char *p, *q;
while ((q = __strtok_r_1c (a, ':', p)))
g(q);
}
I don't know what glibc could do to prevent this (except dropping this
optimisation).
--
Summary: spurious strtok_r warning with -Wwrite-strings
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mattias at virtutech dot se
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=26634
[Bug middle-end/26565] [4.0/4.1/4.2 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-03-10 16:44 --- Subject: Bug 26565 Author: rguenth Date: Fri Mar 10 16:44:01 2006 New Revision: 111934 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111934 Log: 2006-03-10 Richard Guenther [EMAIL PROTECTED] PR middle-end/26565 * builtins.c (get_pointer_alignment): Handle component references for field alignment. * gcc.dg/torture/pr26565.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr26565.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug middle-end/26565] [4.0/4.1 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-03-10 16:44 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.3.3 3.4.2 |3.3.3 3.4.2 4.2.0 Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |Unaligned accesses with |Unaligned accesses with |__attribute__(packed) and |__attribute__(packed) and |memcpy |memcpy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug other/26633] [4.1/4.2 Regression] Minimal c++ program using threads and exceptions crashes when compiled statically
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-10 16:54 --- Just as I had expected in http://gcc.gnu.org/ml/gcc/2006-03/msg00256.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://ds9a.nl/minimal.cc.tx| |t | Severity|normal |blocker Status|UNCONFIRMED |NEW Component|c++ |other Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-10 16:54:23 date|| Summary|Minimal c++ program using |[4.1/4.2 Regression] Minimal |threads and exceptions |c++ program using threads |crashes when compiled |and exceptions crashes when |statically |compiled statically Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
[Bug other/26633] [4.1/4.2 Regression] Minimal c++ program using threads and exceptions crashes when compiled statically
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-10 16:55 --- Some information about this bug in both the libstdc++ library and the libgfortran library on the mainline: http://gcc.gnu.org/ml/gcc/2006-03/msg00248.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
[Bug middle-end/26634] spurious strtok_r warning with -Wall
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-10 16:59 --- This is not a gcc bug as the warning is correct as the following is true, a can be null entering f so p is used uninitialized. If this is a bug, this is a bug in glibc for being over optimizing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Keywords||diagnostic Resolution||INVALID Summary|spurious strtok_r warning |spurious strtok_r warning |with -Wwrite-strings|with -Wall http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26634
[Bug other/26633] [4.1/4.2 Regression] Minimal c++ program using threads and exceptions crashes when compiled statically
--- Comment #3 from ahu at ds9a dot nl 2006-03-10 17:54 ---
Subject: Re: [4.1/4.2 Regression] Minimal c++ program using threads and
exceptions crashes when compiled statically
Sure this is (exactly) related? I tried to pull in some of the symbols that
might be missing to no avail.
Interestingly, the problem does not appear on my x86-64!
Also:
Starting program: /home/ahu/programming-new/exploit/minimal
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 11300)]
[New Thread 32769 (LWP 11301)]
[New Thread 16386 (LWP 11302)]
[Switching to Thread 16386 (LWP 11302)]
Breakpoint 1, __cxa_allocate_exception (thrown_size=8)
at ../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_alloc.cc:115
115 thrown_size += sizeof (__cxa_exception);
(gdb) step
116 ret = malloc (thrown_size);
(gdb) print thrown_size
$1 = 88
(gdb) step
118 if (! ret)
(gdb) print ret
$2 = (void *) 0x8115a60
(gdb) step
116 ret = malloc (thrown_size);
(gdb) step
118 if (! ret)
(gdb)
154 __cxa_eh_globals *globals = __cxa_get_globals ();
(gdb)
__cxa_get_globals () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:71
71 { return __gnu_internal::get_global(); }
(gdb)
__gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
58get_global() throw()
(gdb)
Program received signal SIGSEGV, Segmentation fault.
__gnu_internal::get_global () at
../../../../gcc-4.1.0/libstdc++-v3/libsupc++/eh_globals.cc:58
58get_global() throw()
On Fri, Mar 10, 2006 at 04:55:41PM -, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-10 16:55
---
Some information about this bug in both the libstdc++ library and the
libgfortran library on the mainline:
http://gcc.gnu.org/ml/gcc/2006-03/msg00248.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
!DSPAM:4411af8b239412042891523!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26633
[Bug middle-end/26635] New: [4.1/4.2 Regression] Bogus Storage_Error warning
The patch 2006-01-09 Kazu Hirata [EMAIL PROTECTED] PR tree-optimization/25125 * convert.c (convert_to_integer): Don't narrow the type of a PLUX_EXPR or MINUS_EXPR if !flag_wrapv and the unwidened type is signed. has introduced a regression for the Ada testcase that I'm about to attach: [EMAIL PROTECTED]:~/gnat/bugs/F217-005 gcc -S p.ads p.ads:12:03: warning: Storage_Error will be raised at run-time The testcase should compile silently. Analysis: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00198.html I think Kazu's original patch was the correct fix. -- Summary: [4.1/4.2 Regression] Bogus Storage_Error warning Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26635
[Bug middle-end/26635] [4.1/4.2 Regression] Bogus Storage_Error warning
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-03-10 18:00 --- Created an attachment (id=11016) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11016action=view) Reduced Ada testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26635
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #3 from mark at gcc dot gnu dot org 2006-03-10 18:13 --- While importing 0.90 into libgcj I also noticed this. Setting this package to bc (like the other awt peer implementations) gives: make[3]: Entering directory `/home/mark/src/gcc-obj/i686-pc-linux-gnu/libjava' /bin/sh ./libtool --mode=compile /home/mark/src/gcc-obj/gcc/gcj -B/home/mark/src/gcc-obj/i686-pc-linux-gnu/libjava/ -B/home/mark/src/gcc-obj/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/home/mark/src/gcc-obj/i686-pc-linux-gnu/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -c -o gnu-java-awt-peer-swing.lo @gnu-java-awt-peer-swing.list /home/mark/src/gcc-obj/gcc/gcj -B/home/mark/src/gcc-obj/i686-pc-linux-gnu/libjava/ -B/home/mark/src/gcc-obj/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/home/mark/src/gcc-obj/i686-pc-linux-gnu/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -c @gnu-java-awt-peer-swing.list -fPIC -o .libs/gnu-java-awt-peer-swing.o gnu/java/awt/peer/swing/SwingFramePeer.java: In class 'gnu.java.awt.peer.swing.SwingFramePeer': gnu/java/awt/peer/swing/SwingFramePeer.java: In method 'gnu.java.awt.peer.swing.SwingFramePeer.setBounds(int,int,int,int)': gnu/java/awt/peer/swing/SwingFramePeer.java:118: error: verification failed at PC=6: didn't see expected constant make[3]: *** [gnu-java-awt-peer-swing.lo] Error 1 where line 118 is indeed: super.setBounds(x, y, w, h); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug target/26636] use of r1-r3 across __sdivsi3_4 call
--- Comment #1 from rmansfield at qnx dot com 2006-03-10 18:23 ---
When attaching the test case, I experience a internal error with gcc bugzilla
which I reported to dberlin. I am going to attach the test case in a comment.
I attempted to reduce the test case, but it changed reg. allocation which made
reproducing it difficult.
#include stdlib.h
#include stdio.h
# define M 14
# define PIT_MIN 30
# define SS_AUDIO_SAMPLE_SIZE 2
int main(int argc, char *argv[]) {
int iMarkEvntDelayTime = 0;
int iSampleRate = 0;
int iBlockSize = 0;
int t_op;
int corr[1];
int f_io4[1];
int daten[1];
t_op = wbe_ol_pitch_estimate( daten, corr, f_io4);
return EXIT_SUCCESS;
}
#define PIT_MIN 30
#define PIT_MAX 193
#define L_SUBFR_LB 60
#define DIM (3*L_SUBFR_LB)
#define OLPX_SHIFT 4
int
wbe_ol_pitch_estimate
(
short *x_i,
int *corr,
int *x_local
)
{
inttemp, temp1;
int energy;
intdenom;
intthresh, thresh2;
int *x_t1_ptr, *x_t2_ptr;
int *x_t_max;
int *x;
int i,index,p;
for (i=0; i PIT_MIN; i++)
corr[i] = 0;
x = x_local;
for (i = -PIT_MAX; i DIM; i++)
{
*(x++) = x_i[i]OLPX_SHIFT;
}
x = x_local+PIT_MAX;
x_t_max = x +DIM;
x_t1_ptr = x;
x_t2_ptr = x-PIT_MIN;
energy= 0;
temp = 0;
while( x_t1_ptr x_t_max)
{
temp1 = (int)(*x_t2_ptr);
temp += (*x_t1_ptr) * temp1;
energy += temp1 * temp1;
x_t1_ptr++;
x_t2_ptr++;
}
denom = energy10;
if (denom = 0) denom=1;
corr[PIT_MIN] = temp/denom;
index = PIT_MIN;
for( i=PIT_MIN+1; iPIT_MAX; i++)
{
temp = 0;
x_t1_ptr = x;
x_t2_ptr = x-i;
while( x_t1_ptr x_t_max)
{
temp += (*x_t1_ptr) * (*x_t2_ptr);
x_t1_ptr++;
x_t2_ptr++;
}
temp1 = (int)x[DIM-i];
temp1 *= temp1;
energy -= temp1;
temp1 = (int)x[-i];
temp1 *= temp1;
energy += temp1;
/* calculate the normalized correlation temp/energy */
denom = energy10;
if (denom = 0) denom=1;
temp = temp/denom;
corr[i] = temp;
thresh = (temp2) + (temp1);
if( i((index1)-5))
if( temp corr[index] )
index = i;
if( i=((index1)-5))
if( thresh corr[index] )
index = i;
}
thresh2=(corr[index]1);
p = index/3;
for( i=p-5; ip+5; i++)
{
if( thresh2 corr[i] )
{
index = i;
thresh2=(corr[index]1);
}
}
return( index );
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
[Bug target/26098] [4.0 Regression] ICE in multiplication of 16-byte longlong vector on x86_64
--- Comment #3 from dtemirbulatov at gmail dot com 2006-03-10 19:09 --- Created an attachment (id=11018) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11018action=view) bug fix this a backport form the mainline 2005-05-17 Richard Henderson [EMAIL PROTECTED] * config/i386/sse.md (mulv16qi3, mulv2di3): New -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26098
[Bug target/26636] New: use of r1-r3 across __sdivsi3_4 call
[EMAIL PROTECTED] rmansfield]$ /home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu/bin/sh4-unknown-linux-gnu-gcc -v -o t.s -S -m4 -O2 t.c Using built-in specs. Target: sh4-unknown-linux-gnu Configured with: /home/rmansfield/crosstool-0.42/build/sh4-unknown-linux-gnu/gcc-4.0-20060309-glibc-2.3.6/gcc-4.0-20060309/configure --target=sh4-unknown-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu --with-multilib-list=m4,m4-nofpu --with-headers=/home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/include --with-local-prefix=/home/rmansfield/crosstool/gcc-4.0-20060309-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.0.3 mov.l .L66,r0 mov r11,r1 mov.w .L65,r12 add #64,r1 ; use here mov r3,r8 mov #30,r13 jsr @r0 ; call to __sdivsi3_4 nop sts fpul,r2 add #-124,r8 mov #120,r0 add r3,r12 mov.l r0,@(8,r14) mov #31,r7 mov.l r2,@(56,r1) ; kaboom ... .L66: .long __sdivsi3_i4 Then in the plt stub r1 gets clobbered. 0x804041c _sdivsi3_i4:mov.l 0x8040424 _sdivsi3_i4+8,r1! 0x80418a0 0x804041e _sdivsi3_i4+2: mov.l @r1,r1 0x8040420 _sdivsi3_i4+4: jmp @r1 /home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu/bin/sh4-unknown-linux-gnu-gcc -v -o t.s -S -m4 -O2 t.c Using built-in specs. Target: sh4-unknown-linux-gnu Configured with: /home/rmansfield/crosstool-0.42/build/sh4-unknown-linux-gnu/gcc-4.1.0-glibc-2.3.6/gcc-4.1.0/configure --target=sh4-unknown-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu --with-multilib-list=m4,m4-nofpu --with-headers=/home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/include --with-local-prefix=/home/rmansfield/crosstool/gcc-4.1.0-glibc-2.3.6/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.1.0 gcc 4.1 generates the following code: mov.l .L57,r0 jsr @r0 nop sts fpul,r4 .L8: mov.w .L55,r8 mov r9,r1 mov.w .L56,r12 add #64,r1 add r10,r8 mov.l r4,@(56,r1) ... .L57: .long __sdivsi3_i4 I think this hasn't been previously observed because the .hidden directive in lib1funcs.asm makes each shared library get its own private __sdivsi3_i4 that it can call directly and no registers end up being clobbered. But shouldn't (clobber (reg:SI R1_REG)) in divsi3 prevent the use of R1-R3 across the __sdivsi3 call? -- Summary: use of r1-r3 across __sdivsi3_4 call Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmansfield at qnx dot com GCC build triplet: i686-host_pc-linux-gnu GCC host triplet: i686-host_pc-linux-gnu GCC target triplet: sh4-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #6 from law at redhat dot com 2006-03-10 19:37 --- Subject: Re: [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops On Wed, 2006-03-08 at 00:07 +, janis at gcc dot gnu dot org wrote: --- Comment #5 from janis at gcc dot gnu dot org 2006-03-08 00:07 --- A regression hunt on powerpc64-linux using the C test case from comment #4 identified this patch: http://gcc.gnu.org/viewcvs?view=revrev=110705 r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006) That date doesn't match up with when the Fortran test started failing so I ran another regression hunt using it, which identified this patch: http://gcc.gnu.org/viewcvs?view=revrev=108425 r108425 | law | 2005-12-12 19:59:16 + (Mon, 12 Dec 2005) Just an FYI -- I probably won't be able to start looking at this until Monday. Hopefully it'll be something I can hunt down with a cross compiler as I don't have a ppc64 box :-) jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
