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 reviewers&maintainers 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 reviewers&maintainers 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 N>0. 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 A&M 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.
