Re: Release Schedule issues and doubts
Andrew Pinski [EMAIL PROTECTED] writes: Now for the fix I have in mind (which might or might not work): If you are a maintainer of an area and you approve a patch which causes a regression in that new code, you have to fix it or have the person whos patch it was fix it or face losing your maintainer-ship if it is not handled 2 months after the regression was (openly) reported (which means either to the gcc email lists or to bugzilla). If the patch exposes a latent bug in some other code, the person who approved the code is let off the hook and maintainers of that area would be required to look into the problem if the patch's own is not able to figure out the fix. [snip] The other problem I see currently is not getting patches reviewed in a timely fashion but that is for a different email and it looks like it is getting fixed. I think the two issues are closely related though. One of the reasons that it's difficult to get a patch reviewed is that, to be really confident in a patch, a reviewer has to understand what every line does, and be fairly sure that it's doing it in the right way. Some of the new feature patches that have been posted recently have been very big, and must have taken the reviewers a long time to review. Even if it's not intended that way, your proposal is probably going to be interpreted at some stage as a way of punishing maintainers. If by accepting a patch, you take on the responsibility of organising fixes for every problem that gets traced to that patch, there's going to be even less incentive to review the thing in the first place. Richard
Re: Expansion of __builtin_frame_address
Mark Mitchell [EMAIL PROTECTED] writes:
I'd suggest we leave backtrace() aside, and just talk about
__builtin_frame_address(0), which does have well-defined semantics.
_b_f_a(0) is currently broken on ARM, and we all agree we should fix it.
I don't want to fan the flames here, but I'm not sure either statement
is true. Does __builtin_frame_address(0) really have well-defined
semantics on a target for which the ABI does not specify a frame layout?
I think that's Richard's point.
If I've understood the ARM case, then ARM is in the same boat as MIPS:
everything about the frame is an internal implementation detail. I don't
think you can deference anything relative to __builtin_frame_address(0) on
MIPS and assume that it contains a particular value.
(Ironically, on MIPS, the soft frame pointer is if anything more stable
than the hard frame pointer. The way things are set up in gcc, the soft
frame pointer always points to the bottom of the initial frame, whereas
in MIPS16 code, the hard frame pointer is offset from the soft frame
pointer by the size of the outgoing arguments.)
I'm probably going over old ground here, but:
The frame is the area on the stack which holds local variables and saved
registers. The frame address is normally the address of the first word
pushed on to the stack by the function. However, the exact definition
depends upon the processor and the calling convention. If the processor
has a dedicated frame pointer register, and the function has a frame,
then @code{__builtin_frame_address} will return the value of the frame
pointer register.
doesn't seem very well-defined from a predictability point of view,
since a user cannot in general know if the function has a frame.
In some sense though, it argues that MarkS's patch isn't quite doing
what the documentation implies, since his patch effectively forces
_every_ caller of __builtin_frame_address to have a frame.
You can then argue about whether $30 on MIPS counts as the _processor_
having a dedicated frame pointer register. I'd say no, but...
(FWIW, MIPS is also like ARM in that MIPS gcc uses a different hard
frame pointer -- $17 -- for MIPS16 code.)
Richard
Re: Release Schedule issues and doubts
On 6/4/06, Richard Sandiford [EMAIL PROTECTED] wrote: Even if it's not intended that way, your proposal is probably going to be interpreted at some stage as a way of punishing maintainers. And what is wrong with that? Maybe it would help clean up the long list of maintainers who don't actually do any maintenance. Then, at last, you get a more fair picture of the number of reviewersmaintainers that we really have. Maybe it turns out that patches don't get reviewed not because there are not enough maintainers, but not enough _active_ maintainers. If by accepting a patch, you take on the responsibility of organising fixes for every problem that gets traced to that patch, there's going to be even less incentive to review the thing in the first place. With power comes responsibility. If you can't handle the responsibility, you shouldn't accept the power. Being a maintainer of some part of the compiler should be more than just being listed in MAINTAINERS. Gr. Steven
TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)
[First, a warning: I'm neither an expert in TLS, nor in Windows nor in GCC guts can we have chance to solve the problem of threadprivate by adding the TLS support to mingw32? The support for TLS (Thread Local Storage) would probably come from the compiler itself. Windows has TLS (see for example http:// dotnet.di.unipi.it/Content/sscli/docs/doxygen/pal/localstorage_8c- source.html and http://www.ddj.com/dept/cpp/184403874, or the MSDN documentation at http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/dllproc/base/tlsalloc.asp), so you'd only need to teach GCC how to call that. Now, I don't have competence, time and motivation to do that. So, if my analysis above is correct, there are three things you can do: ask around here if someone is interested in this and is planning to do it; do it yourself, if you have the competence; find someone you know, that you have leverage on, to do it :) Now, for an idea of how much work it represents... perhaps someone here can tell us? FX
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Hello Rask, On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote: There may be a faster way of seeing if the modification is going to work for the DS at all. I noticed from the output template swp%?b\\t%1, %1, [%M0] that swp takes three operands. I don't know ARM assembler, but you may be able to choose to always clobber a specific register. Make it a fixed register (see FIXED_REGISTERS), refer to this register directly in the output template and don't add a clobber to the movqi patterns. IMHO, that's an acceptable hack at an experimental stage. If the resulting code runs correctly on the DS, you can then undo the FIXED_REGISTERS change and add the clobber statements. I have tried this. No luck. Problem is the lack of addressing modes for the swp instruction. Only a simple pointer in a register (no offset, no auto-increment is allowed). After reading most of the gcc rtl documentation (and forgetting way too much..) I came up to the following conclusion: Splitting the insn (define_insn *arm_movqi_insn [(set (match_operand:QI 0 nonimmediate_operand =r,r,r,m) (match_operand:QI 1 general_operand rI,K,m,r))] into 4 different insns: (define_insn *arm_movqi_insn [(set (match_operand:QI 0 register_operand ) (match_operand:QI 1 register_operand ))] (define_insn *arm_movnqi_insn [(set (match_operand:QI 0 register_operand ) (match_operand:QI 1 constant_operand ))] (define_insn *arm_loadqi_insn [(set (match_operand:QI 0 register_operand ) (match_operand:QI 1 memory_operand ))] (define_insn *arm_storeqi_insn [(set (match_operand:QI 0 memory_operand ) (match_operand:QI 1 register_operand ))] This should give the same function as before, but I then I can do (define_insn *arm_storeqi_insn [(set (match_operand:QI 0 simple_memory_operand ) (match_operand:QI 1 register_operand ))] etc to limit the addressing modes of the store insn to the limits of the swpb instruction. And then I can recode the (define_expand movqi [(set (match_operand:QI 0 general_operand ) (match_operand:QI 1 general_operand ))] to cope with the movqi requirements defined in the gcc manual. Hmmm... wondering who all these xxx_operand functions are defined, and where they are documented... Is this the right way to go? regards Wolfgang -- We're back to the times when men were men and wrote their own device drivers. (Linus Torvalds)
Re: TLS on windows
FX Coudert wrote: Now, for an idea of how much work it represents... perhaps someone here can tell us? It's not too hard but it requires changing GCC and binutils, plus a bit of library support. In my implementation (more or less finished, but I have had time to test it yet), I did the following: - Used the existing __thread support in the front-end. Silently ignore the ELF TLS models, because Windows only has one model. - Added target specific (cygming) support for __attribute__((thread)) aka __declspec(thread) for MSC compatibility. - Created an legitimize_win32_tls_address() to replace legitimize_tls_address() in i386.c. It outputs RTL like: (set (reg:SI tp) (mem:SI (unspec [(const_int 44)] WIN32_TIB))) (set (reg:SI index) (mem:SI (symbol_ref:SI __tls_index__))) (set (reg:SI base) (mem:SI (add:SI (reg:SI tp) (mult:SI (reg:SI index) (const_int 4) (plus:SI (reg:SI base) (const:SI (unspec:SI [(symbol_ref:SI foo)] SECREL - Handled the WIN32_TIB unspec by outputting %fs:44 and the SECREL unspec by outputting foo`SECREL. I couldn't use [EMAIL PROTECTED] because @ is valid in identifiers with PECOFF. - Support .tls sections in PECOFF by creating an i386_pe_select_section() based on the generic ELF version. - Added an -mfiber-safe-tls target specific option that makes the references to the WIN32 TIB non-constant. - Modified gas to handle foo`SECREL, based on the ELF support for @ relocations - Fixed some problems with TLS handling in the PECOFF linker script - Created an object file that defines the __tls_used structure (and thus the TLS directory entry) and __tls_index__. Actually, the last one I haven't done yet. I've just been using a linker script to do that, but it should be in a library so the TLS directory entry isn't created if the executable doesn't use TLS. Ross Ridge
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Sunday 04 June 2006 11:31, Wolfgang Mües wrote: Hello Rask, On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote: There may be a faster way of seeing if the modification is going to work for the DS at all. I noticed from the output template swp%?b\\t%1, %1, [%M0] that swp takes three operands. I don't know ARM assembler, but you may be able to choose to always clobber a specific register. Make it a fixed register (see FIXED_REGISTERS), refer to this register directly in the output template and don't add a clobber to the movqi patterns. IMHO, that's an acceptable hack at an experimental stage. If the resulting code runs correctly on the DS, you can then undo the FIXED_REGISTERS change and add the clobber statements. I have tried this. No luck. Problem is the lack of addressing modes for the swp instruction. Only a simple pointer in a register (no offset, no auto-increment is allowed). After reading most of the gcc rtl documentation (and forgetting way too much..) I came up to the following conclusion: Splitting the insn (define_insn *arm_movqi_insn [(set (match_operand:QI 0 nonimmediate_operand =r,r,r,m) (match_operand:QI 1 general_operand rI,K,m,r))] into 4 different insns: No. This is completely the wrong approach. You should just change the valid QImode memory addresses, adding a new constraint if neccessary. You also need to tweak the reload legitimate address bits to obey the new restrictions. For the record these hacks are unlikely to ever be acceptable in mainline gcc. They're relatively invasive changes who's only purpose is to support fundamentally broken hardware. Paul
Re: Release Schedule issues and doubts
On Sun, 4 Jun 2006, Steven Bosscher wrote: Maybe it would help clean up the long list of maintainers who don't actually do any maintenance. Then, at last, you get a more fair picture of the number of reviewersmaintainers that we really have. Agreed. It will provide a clearer picture at least, though it won't solve the problem per se. (Among maintainers of specific parts, I think there aren't too many not doing anything about those parts. Write after approval is another story -- I guess we have at least a dozen of nominal members -- and global write does not necessarily reflect reality, either.) With power comes responsibility. If you can't handle the responsibility, you shouldn't accept the power. Being a maintainer of some part of the compiler should be more than just being listed in MAINTAINERS. If think nobody will disagree with the second sentence. However, we should account for periods of inactivity and reduced activity caused by personal issues, employer changes, illness, whatever. Other projects have a certain period of time (one year, eighteen months) after which inactive contributors are contacted and eventually purged, and I think we should do something similar. Also, when we talk about responsibility, let's be careful not to demand too much: just because someone is listed as a maintainer for foo, does not means her or she shall be responsible for each and every patch or bug in that area. Even fixing one bug a month and reviewing one patch a month is an important contribution. If this is not sufficient in a specific area, we need to try and get additional maintainers, not alienate existing ones. Gerald
Re: TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)
FX Coudert wrote: The support for TLS (Thread Local Storage) would probably come from the compiler itself. Windows has TLS (see for example http:// dotnet.di.unipi.it/Content/sscli/docs/doxygen/pal/localstorage_8c- source.html and http://www.ddj.com/dept/cpp/184403874, or the MSDN documentation at http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/dllproc/base/tlsalloc.asp), so you'd only need to teach GCC how to call that. fs:[0x14] is a per-thread 32-bit word available for applications, so you can store a pointer to your own TLS array there. fs:[0x2c] points to a Windows-specific TLS array, so you can make use of it, too, but you must conform to the limitations of the WinAPI constraints related with TLS management. IMO the best would be the offset 0x14 + a custom design of TLSes (BTW, it must be extremely fast! Many applications get their TLS values very often). Now, for an idea of how much work it represents... perhaps someone here can tell us? I don't know much about GCC internals, but I use my own implementation based on inline assembly and the implementation took, hm, 20 minutes? Best regards Piotr Wyderski
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Paul, On Sunday 04 June 2006 13:24, Paul Brook wrote: On Sunday 04 June 2006 11:31, Wolfgang Mües wrote: Splitting the insn (define_insn *arm_movqi_insn [(set (match_operand:QI 0 nonimmediate_operand =r,r,r,m) (match_operand:QI 1 general_operand rI,K,m,r))] into 4 different insns: No. This is completely the wrong approach. Why? I am learning. You should just change the valid QImode memory addresses, adding a new constraint if neccessary. H... I have tried this. I have changed the operand constraint from m to Q. But these constraints are only used to select the right alternative inside the insn, not which insn is invoked. It might be possible to modify nonimmediate_operand into something else, to select this insn only if the address is fitting in a single register, without offset or increment. But this will not give me the freedom to allocate a temporary register. According to the manual, mov insns are not supposed to clobber a register. I suppose I will have to allocate these registers in (define_expand movqi [(set (match_operand:QI 0 general_operand ) (match_operand:QI 1 general_operand ))] So I have to narrow down the constraint nonimmediate_operand, so that every memory address not fitting in a single register will not invoke arm_movqi_insn. Please correct me if I'm wrong. This is my first encounter with the inner contents of gcc. I may have completely missed your point. You also need to tweak the reload legitimate address bits to obey the new restrictions. Can you show me what you mean here? What to do where? For the record these hacks are unlikely to ever be acceptable in mainline gcc. They're relatively invasive changes who's only purpose is to support fundamentally broken hardware. Paul, this is clear to me. Homebrew software on the DS is not so important to justify such a change in mainline gcc. A patch will be fine. Its a big amount of - sometimes frustrating - work for a gcc newbie to make this change. I am doing this only because I know it's the only solution, and to turn the command line only DS linux into some nice PDA/browser/wireless client machine. regards Wolfgang -- We're back to the times when men were men and wrote their own device drivers. (Linus Torvalds)
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Sunday 04 June 2006 16:26, Wolfgang Mües wrote: Paul, On Sunday 04 June 2006 13:24, Paul Brook wrote: On Sunday 04 June 2006 11:31, Wolfgang Mües wrote: Splitting the insn (define_insn *arm_movqi_insn [(set (match_operand:QI 0 nonimmediate_operand =r,r,r,m) (match_operand:QI 1 general_operand rI,K,m,r))] into 4 different insns: No. This is completely the wrong approach. Why? I am learning. Because then you have several different patterns for the same operation. The different variants of movsi should be part of the same pattern so that the compiler can change its mind which variant it wants to use. You should just change the valid QImode memory addresses, adding a new constraint if neccessary. H... I have tried this. I have changed the operand constraint from m to Q. But these constraints are only used to select the right alternative inside the insn, not which insn is invoked. It might be possible to modify nonimmediate_operand into something else, to select this insn only if the address is fitting in a single register, without offset or increment. But this will not give me the freedom to allocate a temporary register. According to the manual, mov insns are not supposed to clobber a register. I suppose I will have to allocate these registers in (define_expand movqi [(set (match_operand:QI 0 general_operand ) (match_operand:QI 1 general_operand ))] So I have to narrow down the constraint nonimmediate_operand, so that every memory address not fitting in a single register will not invoke arm_movqi_insn. You're confusing constraints and predicates. general_operand is the predicate. The predicate says under which conditions the insn will match. The constraints tell regalooc/reload how to make sure the operands of the instruction are valid. To simplify greatly the predicates are used for pattern matching during early RTL generation and the constraints are used in the later regalloc/reload stages. Tightening the predicates isn't sufficient (and may not even be neccessary). You need to set the constraints so that the compiler knows *how* to fix invalid instructions. The compilcation is that while constraints give sufficient information for the compiler to generate correct code they don't help generating good code. There are often non-obvious target specific ways of reloading invalid addresses. So reload has additional hooks (eg. GO_IF_LEGITIMATE_ADDRESS) to provice clever ways of fixing invalid operands. Generally speaking it's up to the target backend to make sure the code generated by these satisfies the appropriate constraints, and gcc will ICE if they aren't consistent. I'm afraid I can't really be more specific that this. That would require me implementing your changes and figuring out what's going wrong. Paul
Re: Expansion of __builtin_frame_address
Richard Sandiford wrote: Mark Mitchell [EMAIL PROTECTED] writes: I'd suggest we leave backtrace() aside, and just talk about __builtin_frame_address(0), which does have well-defined semantics. _b_f_a(0) is currently broken on ARM, and we all agree we should fix it. I don't want to fan the flames here, but I'm not sure either statement is true. Does __builtin_frame_address(0) really have well-defined semantics on a target for which the ABI does not specify a frame layout? I think that's Richard's point. Thanks for explaining; after the latest messages from you and Richard E., I understand the ARM doesn't have a standard frame layout. I had not realized that before. However, even though there's not an ARM ABI layout, if GCC uses a standard layout, then it would make sense for _b_f_a(0) to return a pointer to that frame. (_b_f_a(0) is a GCC extension, so it can have a GCC-specific definition.) If even that condition does not hold, then I agree that _b_f_a(0) should just have undefined behavior on ARM. We might even consider making it an error to use it. We should document in the manual that you can't use _b_f_a(0) on reliably on some architectures. If, however, there are plausible semantics we like for _b_f_a(0) on ARM, then it doesn't seem to me that we should worry terribly much about pessimizing the code by requiring a hard frame pointer. Of course, it would be better not to do so -- but if the only functions affected are those that actually call _b_f_a(0), I doubt we'd be able to measure a change in any real-world program. Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. (I still think it's somewhat valid, in that there are a lot of people building GCC-only applications, and if backtrace() worked in that case, it would be better than not working at all.) The other examples I can think of are also odd hacks; for example, checking for stack overwrites, manually poking ones own return address pointer, or manually grabbing saved registers from a caller, or some such. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Release Schedule issues and doubts
On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote: On 6/4/06, Richard Sandiford [EMAIL PROTECTED] wrote: Even if it's not intended that way, your proposal is probably going to be interpreted at some stage as a way of punishing maintainers. And what is wrong with that? I have a different take... I think people should be responsible for the patches they put in, and that means that in general, they should work on bugs and regressions in those patches before going off on fun new work. This, if we wanted, could be enforced by accepting patches to fix regressions before accepting (any) other work by that person. This transfers responsibility from the person that approved the work, which, I'd rather not see in general, as it can discourage patch review, to the person doing the work. We can also have this as an optional sign me up for more responsibility type of declaration by patch submitters. I'm happy to fix regressions my patches cause, I consider it my obligation. With regressions fixed sooner, we then might be able to engineer a situation in which Mark isn't saddled with hundreds of bug fixes for regressions, well, unless he caused them all. :-) Maybe we could even ditch some of the stageness we presently do. This employs the standard motivation for work, the acceptance of a patch or not, instead of trying to use bullying tactics, we're gonna revoke your privilege, or other such mechanisms, which, I don't think increases the fun.
Re: Expansion of __builtin_frame_address
On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. Which there is no plausible way to do for the ARM EABI, due to ARM's other choices. -- Daniel Jacobowitz CodeSourcery
Re: Expansion of __builtin_frame_address
Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. Which there is no plausible way to do for the ARM EABI, due to ARM's other choices. If one compiled everything with -fexceptions, could you then use the ARM ABI EH unwind stuff? Or, is there just no way to do this in the ARM EABI? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
MAPPED_LOCATION update
I checked in a couple of patches, so now most front-ends work more-or-less (i.e with some but not a large number of regressions). The Java front-end compiles but fails to run, so bootstrapping fails if java is enabled. I haven't looked into it. This is a regression - it used to work. If the problem is specific to compiling from source, that may reduce its importance, if it's in code that will be replaced by ecj. I have two tentative volunteers to help finish MAPPED_LOCATION. Steven Bosscher hopes to find time to work on save/restore of the line-map table. Ben Elliston will take a look at the other (non-pch-related) regressions. We all have too many things on our plates, so if someone else would like to pitch in, just let us know. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Expansion of __builtin_frame_address
On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote: Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. Which there is no plausible way to do for the ARM EABI, due to ARM's other choices. If one compiled everything with -fexceptions, could you then use the ARM ABI EH unwind stuff? Or, is there just no way to do this in the ARM EABI? The DWARF unwinding tables are descriptive; you can interpret them however necessary, for unwinding or for backtraces. But the ARM unwinding tables are more opaque. You have to call the personality routines in order to do anything. I don't believe there's a way to get runtime backtraces from them, reliably. It might be possible to implement _Unwind_Backtrace, but it also might require additional changes similar to those we needed for forced unwind. -- Daniel Jacobowitz CodeSourcery
Re: Expansion of __builtin_frame_address
Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote: Daniel Jacobowitz wrote: On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote: Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. Which there is no plausible way to do for the ARM EABI, due to ARM's other choices. If one compiled everything with -fexceptions, could you then use the ARM ABI EH unwind stuff? Or, is there just no way to do this in the ARM EABI? The DWARF unwinding tables are descriptive; you can interpret them however necessary, for unwinding or for backtraces. But the ARM unwinding tables are more opaque. In that case, I guess the only open question is whether _b_f_a(0) has a sensible GCC-specific meaning, or whether we should just declare it invalid/undefined on ARM. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [Bug middle-end/27590] [4.1/4.2 Regression] ICE when compiling catalina.jar from tomcat 5.0.30
mmitchel at gcc dot gnu dot org writes: --- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-04 19:02 --- Java is not release critical. I protest. This is not a Java bug but an exception handling bug. The simple fact that the test case for this bug is written in Java should not disqualify this bug from being release-critical because it potentially affects other languages too. I have already submitted a patch. Andrew.
Re: [Bug middle-end/27590] [4.1/4.2 Regression] ICE when compiling catalina.jar from tomcat 5.0.30
Andrew Haley wrote: mmitchel at gcc dot gnu dot org writes: --- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-04 19:02 --- Java is not release critical. I protest. This is not a Java bug but an exception handling bug. Do you have a C++ test-case? I'm all for fixing the bug and there's plenty of time to get this into GCC 4.2. So, don't think this means that this bug can't be fixed; it just means I wouldn't hold up the release for it, at this point. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Expansion of __builtin_frame_address
Mark Mitchell [EMAIL PROTECTED] writes: Richard Sandiford wrote: Mark Mitchell [EMAIL PROTECTED] writes: I'd suggest we leave backtrace() aside, and just talk about __builtin_frame_address(0), which does have well-defined semantics. _b_f_a(0) is currently broken on ARM, and we all agree we should fix it. I don't want to fan the flames here, but I'm not sure either statement is true. Does __builtin_frame_address(0) really have well-defined semantics on a target for which the ABI does not specify a frame layout? I think that's Richard's point. Thanks for explaining; after the latest messages from you and Richard E., I understand the ARM doesn't have a standard frame layout. I had not realized that before. However, even though there's not an ARM ABI layout, if GCC uses a standard layout, then it would make sense for _b_f_a(0) to return a pointer to that frame. (_b_f_a(0) is a GCC extension, so it can have a GCC-specific definition.) If even that condition does not hold, then I agree that _b_f_a(0) should just have undefined behavior on ARM. We might even consider making it an error to use it. We should document in the manual that you can't use _b_f_a(0) on reliably on some architectures. Sounds like a good idea. Richard E. asked what possible uses this function might have. Obviously, GLIBC's backtrace() function is one, though I guess that's a weak example, in that we all agree one should really be using unwind information. (I still think it's somewhat valid, in that there are a lot of people building GCC-only applications, and if backtrace() worked in that case, it would be better than not working at all.) The other examples I can think of are also odd hacks; for example, checking for stack overwrites, manually poking ones own return address pointer, or manually grabbing saved registers from a caller, or some such. I think it would be better to add builtin-functions that do the things we think would be useful, and that we're prepared to keep working in the forseeable future. Otherwise the knowledge about the exact stack layout has to be pushed to each user's code, for each architecture that the user supports. For example, if all we want in the immediate term is to get a backtrace() that works on ARM, and we have logic that we think would work, then we should first make sure that __builtin_return_address(N) implements that logic for N0. To avoid quadrictness in backtrace() itself, we could add new interfaces, such as a version of __builtin_return_address that provides the return addresses for a range of call depths. That probably sounds like a lot of work, but I'm not sure it is. It might be something we could implement using our existing target hooks. And it's probably less work than documenting what is and isn't guaranteed about gcc's frame layout -- and its relation to __builtin_frame_address() -- for each supported architecture. Richard
Re: Release Schedule issues and doubts
Mike Stump [EMAIL PROTECTED] writes: On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote: On 6/4/06, Richard Sandiford [EMAIL PROTECTED] wrote: Even if it's not intended that way, your proposal is probably going to be interpreted at some stage as a way of punishing maintainers. And what is wrong with that? I have a different take... I think people should be responsible for the patches they put in, and that means that in general, they should work on bugs and regressions in those patches before going off on fun new work. This, if we wanted, could be enforced by accepting patches to fix regressions before accepting (any) other work by that person. This transfers responsibility from the person that approved the work, which, I'd rather not see in general, as it can discourage patch review, to the person doing the work. I agree. And I don't think a new gcc by-law is needed here (we seem so many of those already). Maintainers can already refuse to review a fun new feature patch until the submitter has fixed some problem with one of the submitter's earlier patches (if the maintainer thinks that's appropriate). I remember at least one case where it has already happened. Richard
Re: Release Schedule issues and doubts
On Jun 4, 2006, at 1:03 PM, Richard Sandiford wrote: I agree. And I don't think a new gcc by-law is needed here (we seem so many of those already). Maintainers can already refuse to review a fun new feature patch until the submitter has fixed some problem with one of the submitter's earlier patches (if the maintainer thinks that's appropriate). I remember at least one case where it has already happened. Yes but that is not all the problem because a lot of the time the maintainer is also the submitter. There is no way to discourage the behavior of the maintainer on going on to other stuff while there are known regressions to fix. -- Pinski
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Sun, Jun 04, 2006 at 12:31:08PM +0200, Wolfgang Mües wrote: Hello Rask, On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote: There may be a faster way of seeing if the modification is going to work for the DS at all. I noticed from the output template swp%?b\\t%1, %1, [%M0] that swp takes three operands. I don't know ARM assembler, but you may be able to choose to always clobber a specific register. Make it a fixed register (see FIXED_REGISTERS), refer to this register directly in the output template and don't add a clobber to the movqi patterns. IMHO, that's an acceptable hack at an experimental stage. If the resulting code runs correctly on the DS, you can then undo the FIXED_REGISTERS change and add the clobber statements. I have tried this. No luck. Problem is the lack of addressing modes for the swp instruction. Only a simple pointer in a register (no offset, no auto-increment is allowed). What about the Q constraint? From gcc/config/arm/constraints.md: In ARM state an address that is a single base register. Reload knows how to fix up addresses in a number of cases that happen often, and I believe this is one of them. Hmmm... wondering who all these xxx_operand functions are defined, and where they are documented... They are documented in section Machine-Independent Predicates of the manual. I haven't checked where they are defined, but grep -e '^.*_operand_p' -e '^.*_address_p' gcc/*.c should tell you where. Note that strict_memory_address_p() is just a special case of memory_address_p() which checks for specific hard registers as base/index registers if the target has such requirements. This is used starting with the reload pass. Is this the right way to go? I'm pretty sure it is best to have one insn pattern with several alternatives. Reload might change the instruction enough that it ends up using a different alternative. For example, using a register alternative for a constant operand because the constant isn't a valid immediate operand. -- Rask Ingemann Lambertsen
Re: Release Schedule issues and doubts
Gerald Pfeifer [EMAIL PROTECTED] writes: However, we should account for periods of inactivity and reduced activity caused by personal issues, employer changes, illness, whatever. Agreed. Other projects have a certain period of time (one year, eighteen months) after which inactive contributors are contacted and eventually purged, and I think we should do something similar. I don't really see what we gain by having a fixed limit (and another rule ;)). The SC have removed people in the past in cases where it was obvious that they were no longer active. That's really just a house-cleaning exercise, though; I don't think we gain anything other than cleanliness. Like you said, there are good reasons why people might not be able to review patches for a while. But (as you also said) if someone in MAINTAINERS manages to review an average one patch every two months, say, that's still better than nothing! Even if those patches come after a long period of inactivity. Some maintainers with a lot of experience don't review patches as often as they used to, but they still provide good reviews when they do. I think a system of punishing maintainers is going to make it less attractive for less active maintainers to do anything at all. It's not like we have a fixed limit on the number of active maintainers. At the end of the day, if the SC think that someone would make a good maintainer for a particular part of the compiler, they should just go ahead and approach them. Obviously having more maintainers introduces more risk of disagreement, but (a) folks have generally seemed to work through such disagreements in the past (b) I think any judgement about whether the risk is too high is more likely to be based on the way recent development has been going, _not_ on a count of the number of people in MAINTAINERS. Richard
GCC 4.2 Status Report (2006-06-04)
This status report has been a long time coming, for which I apologize. As fwprop is no longer on the table for 4.2, and as the vectorizer improvements seem to have stalled due to a combination of lack of review and Dorit's leave, I think it's time to declare 4.2 feature-complete. That leaves us looking at regressions. There are lots; presently 56 P1s. About half of those are new in 4.2. So, we're not ready to create a 4.2 branch. Therefore, we need to make the mainline open for regression-fixes only to force ourselves to attack the open bugs. Please consider the mainline operating under release-branch rules as of 12:01 AM Wednesday, California time. That will give everyone a few days to check in any in-progress bug-fixes that are not regressions. At this time, I don't think it makes sense to set a 4.2 target branch date. We have to see how fast the bug-fixing goes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Release Schedule issues and doubts
On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote: I think a system of punishing maintainers is going to make it less attractive for less active maintainers to do anything at all. You are not punishing the good maintainers, just not so good ones. The idea is keep maintainers active in GCC and not just sit in the side lines while their code gets bitrotten (which happens too much in GCC already). We can have a reward system for good maintainers in that they get first priority for committing in stage 1 and maybe allowing them to decide what is the best way to do something. In the sense they are can override the other maintainers in that same area. Thanks, Andrew Pinski
Re: Release Schedule issues and doubts
Andrew Pinski [EMAIL PROTECTED] writes: | On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote: | I think a system of | punishing maintainers is going to make it less attractive for | less active maintainers to do anything at all. | | You are not punishing the good maintainers, just not so good | ones. The trouble is there does not seem to be a clear gain in your punishment system. At best it may just discourage people. In a commercial organization, that might be a good system. For a free project like GCC, it is not obvious where the long-term benefits for the project are, given its unconventional way of hiring people. People get inactive for some period of time for various reasons, some of whichg are not subject of public debate. -- Gaby -- Gabriel Dos Reis [EMAIL PROTECTED] Texas AM University -- Department of Computer Science 301, Bright Building -- College Station, TX 77843-3112
Re: Release Schedule issues and doubts
On Jun 4, 2006, at 1:11 PM, Andrew Pinski wrote: Yes but that is not all the problem because a lot of the time the maintainer is also the submitter. There is no way to discourage the behavior of the maintainer on going on to other stuff while there are known regressions to fix. A wiki page of top regressions we care about? We could politely request general agreement that the ones listed be given priority.
Re: Release Schedule issues and doubts
On Jun 4, 2006, at 1:52 PM, Mike Stump wrote: A wiki page of top regressions we care about? We could politely request general agreement that the ones listed be given priority. There is already a link from the main page of GCC to the regressions and they are given priorities by the release manager already. -- Pinski
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote: For the record these hacks are unlikely to ever be acceptable in mainline gcc. They're relatively invasive changes who's only purpose is to support fundamentally broken hardware. We don't yet know if they'll be invasive. There's a good chance that they won't be more than a few new insn patterns, a secondary output reload to provide a scratch register and a pair of new options. There are other targets with targets specific options to work around this or that bug, quirk, defect or errata. In this case, why would two options -mno-byte-writes and -mbyte-writes, with the latter being the default, be unlikely to be acceptable? In particular, the MT port has these two options: -mbacc Use byte loads and stores when generating code. -mno-bacc Do not use byte loads and stores when generating code. -- Rask Ingemann Lambertsen
Re: Release Schedule issues and doubts
On Jun 4, 2006, at 1:43 PM, Gabriel Dos Reis wrote: The trouble is there does not seem to be a clear gain in your punishment system. At best it may just discourage people. In a commercial organization, that might be a good system. For a free project like GCC, it is not obvious where the long-term benefits for the project are, given its unconventional way of hiring people. Which is why in my previous message, I proposed in giving rewards to ones which stick around and maintain. Do we want positive or negative reenforcement? People get inactive for some period of time for various reasons, some of whichg are not subject of public debate. My system said nothing about inactive people, only the active ones. The way I consider a person active maintainer is approving patches/ creating patches. If a person cannot follow up on the approval and/or creation, then why should we take the contribution if it causes problems? 2 months after the regression was found seems like a good time frame for figuring if the maintainer could handle the work load. Maybe we should have a time limit on how far after the patch went in, we should consider the regression significant to worry to give a punishment out. -- Pinski
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Sun, Jun 04, 2006 at 05:26:42PM +0200, Wolfgang Mües wrote: Paul, On Sunday 04 June 2006 13:24, Paul Brook wrote: You should just change the valid QImode memory addresses, adding a new constraint if neccessary. H... I have tried this. I have changed the operand constraint from m to Q. But these constraints are only used to select the right alternative inside the insn, not which insn is invoked. It might be possible to modify nonimmediate_operand into something else, to select this insn only if the address is fitting in a single register, without offset or increment. There's no need to modify nonimmediate_operand or use another predicate. It matches a memory operand, which is fine. But this will not give me the freedom to allocate a temporary register. See TARGET_SECONDARY_RELOAD in the section Register Classes. According to the manual, mov insns are not supposed to clobber a register. I can't find any statement to that effect. Where does it say so? But I can see why it would be a problem when reload_in_progress. (It would make it difficult to convert the m68k backend from cc0 to CC_REG.) -- Rask Ingemann Lambertsen
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote: (define_insn *arm_movqi_insn [(set (match_operand:QI 0 nonimmediate_operand =r,r,r,m) (match_operand:QI 1 general_operand rI,K,m,r))] TARGET_ARM ( register_operand (operands[0], QImode) || register_operand (operands[1], QImode)) @ mov%?\\t%0, %1 mvn%?\\t%0, #%B1 ldr%?b\\t%0, %1 str%?b\\t%1, %0 [(set_attr type *,*,load1,store1) (set_attr predicable yes)] ) I think you should go back to this (i.e. the unmodified version) and only change the m into Q in the fourth alternative of operand 0. See if that works, i.e. generates addresses that are valid for the swp instruction. If it does, then begin to add other changes. -- Rask Ingemann Lambertsen
Why are we installing libtool files now?
I noticed that with a full build (including all of GCJ and libgcj), we now install a bootload of libtool files into $PREFIX/share: .../share/libtool/libltdl/COPYING.LIB .../share/libtool/libltdl/Makefile.am .../share/libtool/libltdl/Makefile.in .../share/libtool/libltdl/README .../share/libtool/libltdl/acinclude.m4 .../share/libtool/libltdl/aclocal.m4 .../share/libtool/libltdl/config-h.in .../share/libtool/libltdl/config.guess .../share/libtool/libltdl/config.sub .../share/libtool/libltdl/configure .../share/libtool/libltdl/configure.ac .../share/libtool/libltdl/install-sh .../share/libtool/libltdl/ltdl.c .../share/libtool/libltdl/ltdl.h .../share/libtool/libltdl/ltmain.sh .../share/libtool/libltdl/missing Is this really necessary? If so, I'd like to understand why? Gerald
Re: Why are we installing libtool files now?
On 6/4/06, Gerald Pfeifer [EMAIL PROTECTED] wrote: I noticed that with a full build (including all of GCJ and libgcj), we now install a bootload of libtool files into $PREFIX/share: .../share/libtool/libltdl/COPYING.LIB .../share/libtool/libltdl/Makefile.am .../share/libtool/libltdl/Makefile.in .../share/libtool/libltdl/README .../share/libtool/libltdl/acinclude.m4 .../share/libtool/libltdl/aclocal.m4 .../share/libtool/libltdl/config-h.in .../share/libtool/libltdl/config.guess .../share/libtool/libltdl/config.sub .../share/libtool/libltdl/configure .../share/libtool/libltdl/configure.ac .../share/libtool/libltdl/install-sh .../share/libtool/libltdl/ltdl.c .../share/libtool/libltdl/ltdl.h .../share/libtool/libltdl/ltmain.sh .../share/libtool/libltdl/missing Is this really necessary? If so, I'd like to understand why? PR27818 Richard.
Re: Why are we installing libtool files now?
On Jun 4, 2006, at 2:59 PM, Gerald Pfeifer wrote: Is this really necessary? If so, I'd like to understand why? It is a libtool/libltdl bug which was fixed after GCC imported the new libltdl. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27818 -- Pinski
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Rask Ingemann Lambertsen wrote: There are other targets with targets specific options to work around this or that bug, quirk, defect or errata. In this case, why would two options -mno-byte-writes and -mbyte-writes, with the latter being the default, be unlikely to be acceptable? In particular, the MT port has these two options: -mbacc Use byte loads and stores when generating code. -mno-bacc Do not use byte loads and stores when generating code. I was just about to ask about this very thing since I'm quite sure that there would be interest in adding this to devkitARM. How much work would it be to implement these switches? I assume that the toolchain would need multilibs for these options in order to use newlib etc. Dave
apply for the relevant forms
Dear maintainer, Our Co. have a new 32b embedded processor, and we have ported the gcc backend for it(support c/c++), now we want add its backend code into gcc packages. i read the Contributing to GCC pages that we must sign some forms, can you kindly send the forms to me? Best Regards Liqin
Re: GCC 4.2 Status Report (2006-06-04)
Mark Mitchell wrote: This status report has been a long time coming, for which I apologize. As fwprop is no longer on the table for 4.2, and as the vectorizer improvements seem to have stalled due to a combination of lack of review and Dorit's leave, I think it's time to declare 4.2 feature-complete. That leaves us looking at regressions. There are lots; presently 56 P1s. About half of those are new in 4.2. So, we're not ready to create a 4.2 branch. Just FYI, I went through the ones that were ICE's in add_virtual_operand, or otherwise look like aliasing, and quickly checked whether they still cause ICE's without the whole used_alone stuff. I've noted whether they do or not in the PR's. Hopefully this will help someone who wants to analyze them.
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 fail
--- Comment #17 from christian dot joensson at gmail dot com 2006-06-04 08:27 --- just a ping here, is anyone here able to say anything about status of this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug fortran/27889] New: gfortran 4.1.1 ICE on espresso (PWscf)
Trying to compile the espresso electronic structure package from pwscf.org with gfortran 4.1.1 fails with an ICE: make[1]: Entering directory `/home/donnie/espresso-3.1/Modules' cpp -P -traditional -D__FFTW -I../include constraints_module.f90 -o constraints_module.F90 gfortran -O3 -D__FFTW -I../include -I. -I../Modules -I../PW -I../PH -I../iotk/src -I../CPV -c constraints_module.F90 -o constraints_module.o constraints_module.F90: In function 'set_structure_factor': constraints_module.F90:304: internal compiler error: in find_lattice_value, at tree-complex.c:133 Interestingly, this ICE only occurs at optimization levels greater than -O0. I've uploaded constraints_module.F90 and the required *.mod files to http://dev.gentoo.org/~spyderous/espresso-ice.tar.bz2 to assist in fixing this. -- Summary: gfortran 4.1.1 ICE on espresso (PWscf) Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: spyderous at gentoo dot org GCC host triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug tree-optimization/17506] [4.0/4.1/4.2 regression] warning about uninitialized variable points to wrong location
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven 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=17506
[Bug tree-optimization/26251] [4.2 Regression] code size increase with -Os
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-04 09:32 --- This should have a higher priority than P3 IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
[Bug libstdc++/27867] compile error in repeated application of valarray::operator==
--- Comment #3 from paolo at gcc dot gnu dot org 2006-06-04 09:33 --- Subject: Bug 27867 Author: paolo Date: Sun Jun 4 09:32:56 2006 New Revision: 114356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114356 Log: 2006-06-04 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/27867 * include/bits/valarray_before.h (struct _BinClos_Oper, _ValArray, _ValArray, _Tp, _Tp): Fix value_type typedef. * testsuite/26_numerics/valarray/27867.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/valarray/27867.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/valarray_before.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27867
[Bug libstdc++/27867] compile error in repeated application of valarray::operator==
--- Comment #4 from pcarlini at suse dot de 2006-06-04 09:34 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27867
[Bug rtl-optimization/27616] [4.1/4.2 Regression] Internal error with -O1 (CSE)
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-04 09:34 --- Would be fixed with fwprop due to not recursively calling fold_rtx. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-04 09:36:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug fortran/25096] Non-conforming shapes of DATA object and data
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-04 09:38 --- g95 emits a hard error on this one, while Intel accept it. $ g95 a.f90 In file a.f90:5 DATA (D(i)%I,i=1,4) /8*0/ 1 Error: Array section not allowed in DATA statement at (1) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid, diagnostic Last reconfirmed|-00-00 00:00:00 |2006-06-04 09:38:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25096
[Bug bootstrap/25502] Werror problem in build
--- Comment #6 from rmathew at gcc dot gnu dot org 2006-06-04 09:47 --- By the way, x-mingw32 contains: # On MinGW, we use %IA64d to print 64-bit integers, and the format-checking # code does not handle that, so we have to disable checking here. WERROR_FLAGS += -Wno-format This should have fixed the problem, but it doesn't for some reason. See also: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02223.html (and the follow-up messages). -- rmathew at gcc dot gnu dot org changed: What|Removed |Added CC||rmathew at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug fortran/25095] Disallowed intrinsic in initialization statement
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-04 09:52 --- By F2003: C561 (R528) In an array-element or a scalar-structure-component that is a data-i-do-object , any subscript shall be an expression whose primaries are either constants, subobjects of constants, or DO variables of this data-implied-do or the containing data-implied-dos, and each operation shall be intrinsic. Now, MODULO is found under 13.5 (Standard generic intrinsic procedures) so, by my reading of the standard, this is allowed. And the F95 standard seems to have exactly the same wording. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-04 10:01 --- I marked it as ice-on-valid-code, but I'm not sure it's valid code. g95 emits an error, but Intel and Sun compilers don't. Uttam, do you know if that code is valid? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||ice-on-valid-code Last reconfirmed|2005-11-21 21:02:12 |2006-06-04 10:01:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/23209] array shape conformance not checked
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-06-04 10:04 --- It's been fixed: $ gfortran a.f90 In file a.f90:6 b = b + a 12 Error: Shapes for operands at (1) and (2) are not conformable -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED GCC build triplet|powerpc-linux | GCC host triplet|powerpc-linux | GCC target triplet|powerpc-linux | Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23209
[Bug c++/27884] [4.2 regression] bogus error: invalid use of 'register' in linkage specification
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-04 10:04 --- It's certainly a questionable use of 'register'. What is the expected effect of this parameter declaration from perls point of view? -- 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=27884
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-06-04 10:18 --- I agree with Steve's comment that a maximal number of errors should be allowed, after which the compiler should bail out. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org OtherBugsDependingO|19292 | nThis|| Keywords||diagnostic Last reconfirmed|2005-08-23 21:18:45 |2006-06-04 10:18:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug c++/27884] [4.2 regression] bogus error: invalid use of 'register' in linkage specification
--- Comment #3 from tbm at cyrius dot com 2006-06-04 10:24 --- I don't know why Perl uses it, I simply noticed that lots of packages in Debian now fail to build because its part of a Perl header... they do this: extern C SV* Perl_Gsv_placeholder_ptr(register PerlInterpreter *my_perl __attribute__((unused))); In an IRC discussion whether this is valid, the following comments were made: 18:11 Womble2 a linkage-specification directly containing a single declaration shall not specify a storage class (7.5/8) 18:12 Womble2 but I think it really means at the top-level of the declaration 18:12 pinskia Womble2: I think that means extern C static int t; is invalid 18:12 Womble2 yes the example it gives has a function declared a static 18:13 pinskia but register allows to the argument and not to the declaration 18:13 pinskia s/allows/applies/ 18:14 Womble2 indeed, though the statement could be (rather perversely) read as disallow specification of a storage class anywhere in the declaration, as the person who made the change may have done [Womble2 = Ben Hutchings, pinskia = Andrew Pinski] Do you disagree with that interpretation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27884
[Bug fortran/23371] internal compiler error when missing a module procedure
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-04 10:30 --- This is fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23371
[Bug fortran/25095] Disallowed intrinsic in initialization statement
--- Comment #2 from jv244 at cam dot ac dot uk 2006-06-04 10:42 --- (In reply to comment #1) .. and each operation shall be intrinsic Now, MODULO is found under 13.5 (Standard generic intrinsic procedures) But MODULO is not an intrinsic operation (these are defined in 7.1.2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095
[Bug c++/27884] [4.2 regression] bogus error: invalid use of 'register' in linkage specification
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-04 10:48 --- I agree that the code is valid from a standards perspective. Just not very clever ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27884
[Bug c++/27884] [4.2 regression] bogus error: invalid use of 'register' in linkage specification
--- Comment #5 from tbm at cyrius dot com 2006-06-04 10:52 --- OK, I'll let the Perl people know. It would be nice though to revert this error before 4.1.2/4.2.0 come out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27884
[Bug bootstrap/25502] Werror problem in build
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-06-04 11:02 --- In my local tree (and in the 3.4.x mingw tree), I have added a modification and extension of this patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02296.html I plan to follow up in stage 1 of 4.3 This patch silences the worst of the warnings. However, because of the -pedantic switch, I still get warnings like ../../gcc/gcc/gcov-dump.c:408: warning: ISO C does not support the 'I64' printf length modifier -Wno-pedantic-errors doesn't work for me, so --disable-werror is still necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug libgcj/27890] New: [4.2 regression] lib/logging.properties pollutes common namespace
Now that I can build libgcj again on HEAD, I found that it pollutes the common namespace by installing $PREFIX/lib/logging.properties. This break the installation of several versions of GCC into the same $PREFIX using --program-suffix=. -- Summary: [4.2 regression] lib/logging.properties pollutes common namespace Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug target/27891] New: [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
ICE on Alpha in tree_split_edge, at tree-cfg.c:3107. Works with gcc 3.4 and current gcc 4.2, fails with 4.0 and 4.1. [EMAIL PROTECTED]:~/delta/bin$ g++-4.1 -c -O1 mini.c mini.c: In function 'int domisc(const char*)': mini.c:27: internal compiler error: in tree_split_edge, at tree-cfg.c:3107 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. Preprocessed source stored into /tmp/cctyNtwC.out file, please attach this to your bugreport. [EMAIL PROTECTED]:~/delta/bin$ g++-4.1 -c mini.c [EMAIL PROTECTED]:~/delta/bin$ g++-4.0 -c -O2 mini.c mini.c: In function 'int domisc(const char*)': mini.c:27: internal compiler error: in tree_split_edge, at tree-cfg.c:3226 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. [EMAIL PROTECTED]:~/delta/bin$ /usr/lib/gcc-snapshot/bin/g++ -c -O2 mini.c [EMAIL PROTECTED]:~/delta/bin$ -- Summary: [4.0/4.1 regression] ICE in tree_split_edge, at tree- cfg.c:3107 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: alpha-linux-gnu GCC host triplet: alpha-linux-gnu GCC target triplet: alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #1 from tbm at cyrius dot com 2006-06-04 11:14 --- Created an attachment (id=11593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11593action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #1 from gerald at pfeifer dot com 2006-06-04 11:15 --- Also, does a configuration file, in text format, like this really belong under /lib? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-04 11:17 --- Also it should be beyond /usr/share, as it is not arch dependent. Same problem for /usr/lib/security/classpath.security and /usr/lib64/security/libgcj.security. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-04 11:17:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug middle-end/27889] ICE on complex assignment
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-04 11:24
---
I can reproduce this on i686-linux and reduced it to this minimal testcase:
COMPLEX z
CONTAINS
SUBROUTINE foo
z = z + cmplx(1.0,0.0)
z = z + z
END SUBROUTINE foo
END
It fails for me at all optimization levels, including -O0. I've tried it with
current mainline as well as mainline from 2006-05-01, it exhibits the same
errors.
I can't make a C testcase easily, but I think it's a middle-end issue because
the same testcase compiled on 4.1.2 works, although it gives the same tree
(with -fdump-original-tree):
foo ()
{
z = z + __complex__ (1.0e+0, 0.0);
z = z + z;
MAIN__ ()
{
complex4 z;
static void foo (void);
_gfortran_set_std (70, 127, 0);
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org, stevenb dot gcc at
||gmail dot com
Status|UNCONFIRMED |NEW
Component|fortran |middle-end
Ever Confirmed|0 |1
GCC host triplet|powerpc-unknown-linux-gnu |
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2006-06-04 11:24:33
date||
Summary|gfortran 4.1.1 ICE on |ICE on complex assignment
|espresso (PWscf)|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug fortran/27889] ICE on complex assignment
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-04 11:49 --- I now also have a slightly different testcase that fails on 4.1.1 and current 4.1 branch, on i686-linux, at optimization levels -O1 or higher: MODULE constraints_module REAL target CONTAINS SUBROUTINE init_constraint COMPLEX struc_fac CALL set_structure_factor RETURN CONTAINS SUBROUTINE set_structure_factor target = CONJG( struc_fac ) * struc_fac END SUBROUTINE set_structure_factor END SUBROUTINE init_constraint END MODULE constraints_module Paul, I'm adding you to the CC list since this looks fully module-related. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC|stevenb dot gcc at gmail dot|paul dot richard dot thomas |com |at cea dot fr Component|middle-end |fortran Last reconfirmed|2006-06-04 11:24:33 |2006-06-04 11:49:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #2 from falk at debian dot org 2006-06-04 12:51 ---
Here is a cleaned-up testcase:
int firstkey();
void DBM_error(int);
void domisc() {
int i = 0;
try {
try {
firstkey();
while (1) {
i++;
firstkey();
}
} catch (int) {
;
}
DBM_error(i);
} catch (int) {
;
}
}
I have no idea why this would happen only on Alpha, it seems unlikely it's
actually a target bug...
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.0.3 4.1.0
Known to work||3.4.6 4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-06-04 12:59 --- Subject: Bug 27039 Author: rguenth Date: Sun Jun 4 12:59:40 2006 New Revision: 114357 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114357 Log: 2006-06-04 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27039 * fold-const.c (fold_comparison): Handle pointer comparison again for all comparison codes. Compare offsets in signed size type. (fold_binary): Move code from here. * gcc.dg/tree-ssa/loop-17.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-17.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug tree-optimization/27039] [4.1 Regression] Unable to determine # of iterations for a simple loop
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-06-04 13:16 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] Unable |[4.1 Regression] Unable to |to determine # of iterations|determine # of iterations |for a simple loop |for a simple loop http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug fortran/27889] ICE on complex assignment
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-04 14:38
---
I examined the different tree dumps for
COMPLEX z
CONTAINS
SUBROUTINE foo
z = z + z
END SUBROUTINE foo
END
and the last non-empty one before the error message:
complex.f90: In function foo:complex.f90:4: error: invalid operand to binary
operator
D.906
complex.f90:4: internal compiler error: verify_stmts failed
is complex.f90.021t.eh, which has the following content:
;; Function foo (foo.899)
foo ()
{
complex4 D.908;
complex4 D.907;
complex4 D.906;
complex4 z [value-expr: CHAIN.1-z];
D.906 = CHAIN.1-z;
D.907 = CHAIN.1-z;
D.908 = D.906 + D.907;
CHAIN.1-z = D.908;
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug libgcj/27892] New: gij.cc:104: error: 'setenv' was not declared in this scope
/mnt/gnu/gcc-3.3/objdir/./gcc/xgcc -shared-libgcc -B/mnt/gnu/gcc-3.3/objdir/./gc c -nostdinc++ -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src - L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu /gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-h pux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/include -isy stem /opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I . -I../../../gcc/libjava -I./include -I./gcj -I../../../gcc/libjava -Iinclude -I ../../../gcc/libjava/include -I../../../gcc/libjava/classpath/include -Iclasspat h/include -I../../../gcc/libjava/classpath/native/fdlibm -I../../../gcc/libjava/ ../boehm-gc/include -I../boehm-gc/include -I../../../gcc/libjava/libltdl -I../.. /../gcc/libjava/libltdl -I../../../gcc/libjava/.././libjava/../gcc -I../../../gc c/libjava/../zlib -I../../../gcc/libjava/../libffi/include -I../libffi/include - fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum - D_FILE_OFFSET_BITS=64 -I/usr/include/X11R6 -Wextra -Wall -D_GNU_SOURCE -DPREFIX= \/opt/gnu/gcc/gcc-4.2.0\ -DLIBDIR=\/opt/gnu/gcc/gcc-4.2.0/lib\ -DJAVA_HOME=\ /opt/gnu/gcc/gcc-4.2.0\ -DBOOT_CLASS_PATH=\/opt/gnu/gcc/gcc-4.2.0/share/java/ libgcj-4.2.0.jar\ -DJAVA_EXT_DIRS=\/opt/gnu/gcc/gcc-4.2.0/share/java/ext\ -DG CJ_ENDORSED_DIRS=\/opt/gnu/gcc/gcc-4.2.0/share/java/gcj-endorsed\ -DGCJ_VERSIO NED_LIBDIR=\/opt/gnu/gcc/gcc-4.2.0/lib/gcj-4.2.0\ -DPATH_SEPARATOR=\:\ -DLIB GCJ_DEFAULT_DATABASE=\/opt/gnu/gcc/gcc-4.2.0/lib/gcj-4.2.0/classmap.db\ -DLIBG CJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.2.0/classmap.db\ -DTOOLEXECLIBDIR=\/opt/ gnu/gcc/gcc-4.2.0/lib\ -g -O2 -MT gij.lo -MD -MP -MF .deps/gij.Tpo -c ../../../ gcc/libjava/gij.cc -fPIC -DPIC -o .libs/gij.o ../../../gcc/libjava/gij.cc: In function 'int main(int, const char**)': ../../../gcc/libjava/gij.cc:104: error: 'setenv' was not declared in this scope make[3]: *** [gij.lo] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libjav a' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libjav a' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/mnt/gnu/gcc-3.3/objdir' make: *** [bootstrap] Error 2 Sat Jun 3 22:03:34 EDT 2006 This was introduced by the following change: 2006-05-30 Thomas Fitzsimmons [EMAIL PROTECTED] * gij.cc (main): Prepend LD_LIBRARY_PATH with GCJ_VERSIONED_LIBDIR and re-exec self. -- Summary: gij.cc:104: error: 'setenv' was not declared in this scope Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27892
[Bug fortran/27478] getting : error: invalid operand to binary operator
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-04 15:16:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug fortran/27478] getting : error: invalid operand to binary operator
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-04 15:16 --- *** Bug 27889 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||spyderous at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug fortran/27889] ICE on complex assignment
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-04 15:16 --- *** This bug has been marked as a duplicate of 27478 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug c++/27884] [4.1/4.2 regression] bogus error: invalid use of 'register' in linkage specification
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-04 15:35 --- Confirmed. Breaking perl is not nice. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-04 15:35:07 date|| Summary|[4.2 regression] bogus |[4.1/4.2 regression] bogus |error: invalid use of |error: invalid use of |'register' in linkage |'register' in linkage |specification |specification Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27884
[Bug c/25161] [4.0/4.1/4.2 Regression] Internal compiler error (segfault) instead of error message
--- Comment #11 from jsm28 at gcc dot gnu dot org 2006-06-04 16:49 --- Testing a fix. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-12 18:03:48 |2006-06-04 16:49:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25161
[Bug c/27020] [4.0/4.1/4.2 regression] ICE on invalid array size
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-06-04 16:50 --- Testing a fix. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-04 09:24:36 |2006-06-04 16:50:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27020
[Bug c/27893] New: [4.0/4.1/4.2 Regression] ICE with TREE_CONSTANT VLA sizes inside functions
int a;
void f(void) { int b[(__SIZE_TYPE__)a]; }
yields
t.c: In function 'f':
t.c:2: internal compiler error: in tree_low_cst, at tree.c:4413
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Likewise if the size is 1/0. Related to but not the same as bug 25161 and bug
27020 (both involve VLAs with TREE_CONSTANT array sizes, but in this case the
code is valid).
--
Summary: [4.0/4.1/4.2 Regression] ICE with TREE_CONSTANT VLA
sizes inside functions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27893
[Bug c/7948] gcc fails to fault gnu extension with -std=c99
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-06-04 17:00 --- Fixed for 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7948
[Bug c/18740] Execution-time sizeof drops side effects
--- Comment #8 from jsm28 at gcc dot gnu dot org 2006-06-04 17:01 --- Fixed for 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18740
[Bug c/25802] VM types of external and internal linkage variables not diagnosed
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-06-04 17:03 --- Fixed for 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25802
Return code of gcc
Hi, I'm writing a program, which executes gcc for compiling a C proram. Now, I need the returned code of gcc after compiling. Can you help me? Thanks! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Return code of gcc
On Jun 4, 2006, at 10:12 AM, Vu Quang Cao wrote: Hi, I'm writing a program, which executes gcc for compiling a C proram. Now, I need the returned code of gcc after compiling. This is offtopic of this channel. Also it depends on what OS you are using? From an unix shell script you can use $? as the return code. -- Pinski
[Bug c/27489] [4.1/4.2 regression] ICE on broken switch condition
--- Comment #8 from jsm28 at gcc dot gnu dot org 2006-06-04 17:16 --- The patch in comment#2 is OK for 4.1 and mainline with the change to comparing expr2 == error_mark_node, provided the testcases from this bug and bug 27490 are added to the testsuite. Regarding that referenced in comment#6, the test against ERROR_MARK being removed is probably intended to avoid excess diagnostics in that case. That patch is OK for mainline if the error (switch quantity not an integer); is made conditional on (orig_type != error_mark_node). -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, jsm28 at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27489
[Bug middle-end/24998] [4.2 Regression] Build failure: undefined symbol __floatunsitf
--- Comment #28 from mmitchel at gcc dot gnu dot org 2006-06-04 17:19 --- Joseph -- Would you please summarize the current state of this bug, and whether or not you intend to do any more work on it? I'm trying to figure out how to prioritize it for 4.2. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug bootstrap/25438] [4.2 Regression] make: *** No rule to make target `bubblestrap'. Stop.
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-04 17:19 --- Not release-critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438
[Bug bootstrap/25470] [4.2 Regression] fixincludes/ subdirectory not cleaned by make distclean
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-04 17:22 --- Not release-critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25470
[Bug libgomp/25938] [4.2 regression] libgomp installs header files in version and target independent location
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-04 17:26 --- This is a show-stopper; an installation problem like this would be embarassing. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
[Bug target/26146] [4.2 Regression] Bootstrapping mainline on Solaris 10/x86 fails
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146
[Bug c/26154] [4.2 Regression] OpenMP extensions to the C language is not documented
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-06-04 17:33 --- Yes, there should at least be a reference to online information about OpenMP in our manual. At this is one of the major new features in 4.2, it should definitely be documented. Diego, would you be able to put a pointer in the manual? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
[Bug middle-end/24998] [4.2 Regression] Build failure: undefined symbol __floatunsitf
--- Comment #29 from joseph at codesourcery dot com 2006-06-04 17:35 --- Subject: Re: [4.2 Regression] Build failure: undefined symbol __floatunsitf On Sun, 4 Jun 2006, mmitchel at gcc dot gnu dot org wrote: --- Comment #28 from mmitchel at gcc dot gnu dot org 2006-06-04 17:19 --- Joseph -- Would you please summarize the current state of this bug, and whether or not you intend to do any more work on it? I'm trying to figure out how to prioritize it for 4.2. The state is still as in comment#23 and I don't intend to do any more work on it (though I could do the US_SOFTWARE_GOFAST removal if desired). * MIPS16 (mips16.S needs implementations of the relevant functions, mips_init_libfuncs should arrange for them to be called) - preferably to be done by someone set up to test MIPS16. * FRV - see comment#9 - could do with knowledge of the intent behind the C functions such as __uitod and again with someone to test on FRV. * US_SOFTWARE_GOFAST - should be removed - see my list at http://gcc.gnu.org/ml/gcc/2006-05/msg00440.html of the various pieces to remove. * powerpc-linux glibc -mabi=ieeelongdouble - not supported by glibc in any meaningful way but it does provide the ABI-mandated functions for arithmetic on IEEE long double; however, there is a glibc bug whereby it provides _q_uitoq instead of the correct name _q_utoq which GCC will now call. There is no GCC bug here since GCC calls the ABI-specified function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug bootstrap/26188] [4.2 Regression] 4.2.0 fails to compile on FreeBSD 4.11
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-06-04 17:36 --- i386-freebsd is a primary platform, so we should ensure that we can build there. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
[Bug libgomp/26175] [4.2 Regression] In gcc-4.2.0 libgomp/.../powerpc/futex.h SYS_futex undefined
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-04 17:35 --- Yes, this is a critical problem. OpenMP is a major feature in 4.2. It would be embarassing for it to break builds for users. We should fix the configury so as not to build the library on unsupported systems. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26175
[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name with vectorizer
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-06-04 17:40 --- Has anyone tested Dorit's patch? (IIUC, Dorit is on maternity leave.) -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
[Bug c++/26740] [4.2 regression] ICE taking the address of a bound member function
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-04 17:41 --- Subject: Bug 26740 Author: pinskia Date: Sun Jun 4 17:40:51 2006 New Revision: 114360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114360 Log: 2006-06-01 Andrew Pinski [EMAIL PROTECTED] PR c++/26740 * typeck.c (build_unary_op): Mark the function as being used. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug c++/26740] [4.2 regression] ICE taking the address of a bound member function
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-04 17:41 --- Subject: Bug 26740 Author: pinskia Date: Sun Jun 4 17:40:51 2006 New Revision: 114360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114360 Log: 2006-06-01 Andrew Pinski [EMAIL PROTECTED] PR c++/26740 * typeck.c (build_unary_op): Mark the function as being used. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c --- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-04 17:41 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug tree-optimization/26251] [4.2 Regression] code size increase with -Os
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
