Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Mon, Apr 4, 2011 at 10:30 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/04/11 19:14, Bernd Schmidt wrote: >>> >> Another danger is getting a mob effect as in PR48403 (which I've also >> seen happen on other occasions) and getting the wrong set of patches >> reverted by trigger-happy people. To be blunt, there are some people on >> this list who tend to react panicky to bugs and skip proper analysis (as >> in this case); I don't want to encourage such folks to revert stuff >> willy-nilly. Sometimes you just need a bit of time and assistance from >> testers who actually see the problem to understand it. >> >> If there's a change in policy I'd at least make allowances for weekends. >> There's considerably less traffic on the mailing lists on Saturdays and >> Sundays, which suggests few people will be inconvenienced if the tree is >> broken during such a time. We also don't want everyone to only check >> things in on Mondays because they worry they'll come back after a >> weekend to find their stuff gone from the tree. > I definitely think that if there is a policy change that an allowance be > made for weekends/holidays and that if a patch has been identified and > the offender has acknowledged the issue and is actively working on the > problem give the offender time to resolve the issue. If a developer breaks bootstrap and cannot fix it immediately, the patch should be reverted and the developer can fix the patch offline and re-merge the patch. The focus of the policy should not be the convenience of the developer who broke bootstrap on multiple targets. - David
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 00:51, Ian Lance Taylor wrote: > I agree. > > At the summit in October there was a discussion about this. I was on > the side of fast rollback for new failures. Would anybody care to > present the opposite view with regard to a patch like this? Can we > agree on fast rollback for bootstrap failures on x86/x86_64 GNU/Linux > systems? I completely support this approach. Diego.
Re: constraints for push byte on word-aligned stack
Peter Bigot writes: > I have a target that supports a "push.b x" operation that puts a byte onto > the stack but pre-decrements the stack pointer by 2 to maintain alignment. That looks like the same as what m68k does, see PUSH_ROUNDING. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
> I definitely think that if there is a policy change that an allowance be > made for weekends/holidays and that if a patch has been identified and > the offender has acknowledged the issue and is actively working on the > problem give the offender time to resolve the issue. This weekends/holidays allowance would be dangerous and counter-productive: people would rush to install risky changes on Friday and leave for the week-end fingers crossed. This would be worse than the current policy IMO. -- Eric Botcazou
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 10:50, Eric Botcazou wrote: >> I definitely think that if there is a policy change that an allowance be >> made for weekends/holidays and that if a patch has been identified and >> the offender has acknowledged the issue and is actively working on the >> problem give the offender time to resolve the issue. > > This weekends/holidays allowance would be dangerous and counter-productive: > people would rush to install risky changes on Friday and leave for the > week-end fingers crossed. This would be worse than the current policy IMO. I agree. If it's broken, it should be taken out. It doesn't make a lot of difference to the patch owner, and if the fix takes more than a day or so to be produced, then the cost of the breakage is much higher. As an example, I recently broke ObjC++, and the fix for it took more than 3-4 days to get in. My patch should've been reverted in the meantime. Diego.
Re: [RFC] Creating builtin functions on demand
On Mon, Apr 4, 2011 at 9:31 PM, Michael Meissner wrote: > I am looking at finishing up the PowerPC support for functions compiled with > target specific options, and the PowerPC will have the same problem that the > x86 has, namely in order to support target functions, you need to have all of > the machine specific builtins created, even if the user did not say -m, > because they might use the appropriate pragma or attribute to compile code for > a different machine. > > As far as I could tell with a quick search: > x86 has 818 machine specific builtins > ppc has 958 machine specific builtins > arm has 90 machine specific builtins > mips has 262 machine specific builtins > > Ideally, these should all be created on the first usage. Not only is the > space > wasted for the tree decl itself, but there is the space for representing the > argument list. We should put some infrastructure into GCC 4.7 that helps > automate this process. > > I'm wondering what the various maintainers feel we need in terms of > infrastructure for these create on demand functions? Should we put the > majority of non-machine dependent builtins into create on demand as well? Maybe, but it's not that important. > Do we want to have the ability to make the enum's for MD builtin functions to > be in the same space as the non-MD builtins. I have had to track down several > bugs where code was not checking if the builtin class was BUILT_IN_NORMAL > before indexing into the built_in_decl arrays. Yes, we do. Places not checking the builtin class are simply bogus. > Obviously, we need to look at built_in_decl and implicit_built_in_decl uses. > I > would probably make new macros to replace those two arrays (with GET and SET > versions), and poison the old usage. I'd separate the target/non-target builtin issue for now (we have some general issues with non-target builtins and checks for their "availability"). As for target builtins we do already have a target hook that gets you a builtin decl for a function-code, what we lack is a proper way to integrate with frontend name-lookup that doesn't rely on the current way of simply injecting all names into it. That's also where the current scheme is lacking - even for non-target builtins we want to know in the middle-end if the user provided a (compatible) declaration of the builtin, but currently we only have partitioned the set of builtins into C standard groups. Richard. > > -- > Michael Meissner, IBM > 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA > meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899 >
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 12:51 AM, Ian Lance Taylor wrote: > Steven Bosscher writes: > >> My proposal would be: A patch may be reverted immediately by anyone >> with SVN write access if bootstrap is broken for more than 24 hours on >> any primary target. With proper notification to everyone involved, >> obviously. > > I agree. > > At the summit in October there was a discussion about this. I was on > the side of fast rollback for new failures. Would anybody care to > present the opposite view with regard to a patch like this? Can we > agree on fast rollback for bootstrap failures on x86/x86_64 GNU/Linux > systems? And we disagreed. The course of action is to simply ask the offender to revert his patches for now. It has worked reliably in the past, but I can't see any such suggestion in this particular case (on the mailing-list). Richard. > Ian >
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 10:50 AM, Eric Botcazou wrote: >> I definitely think that if there is a policy change that an allowance be >> made for weekends/holidays and that if a patch has been identified and >> the offender has acknowledged the issue and is actively working on the >> problem give the offender time to resolve the issue. > > This weekends/holidays allowance would be dangerous and counter-productive: > people would rush to install risky changes on Friday and leave for the > week-end fingers crossed. This would be worse than the current policy IMO. Indeed. I usually try to avoid committing such patches on Fridays. It's not an inconvenience to delay committing to Monday if you don't work on weekends anyway, is it? So, I simply expect people to apply common sense when they commit (large) patches. If you are not available to fix possible fallout on the next day(s), don't commit. Similar, don't commit such things 5 minutes before you leave office. The next morning will also do. Richard. > -- > Eric Botcazou >
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 11:49 AM, Diego Novillo wrote: > On Tue, Apr 5, 2011 at 10:50, Eric Botcazou wrote: >>> I definitely think that if there is a policy change that an allowance be >>> made for weekends/holidays and that if a patch has been identified and >>> the offender has acknowledged the issue and is actively working on the >>> problem give the offender time to resolve the issue. >> >> This weekends/holidays allowance would be dangerous and counter-productive: >> people would rush to install risky changes on Friday and leave for the >> week-end fingers crossed. This would be worse than the current policy IMO. > > I agree. If it's broken, it should be taken out. It doesn't make a > lot of difference to the patch owner, and if the fix takes more than a > day or so to be produced, then the cost of the breakage is much > higher. As an example, I recently broke ObjC++, and the fix for it > took more than 3-4 days to get in. My patch should've been reverted > in the meantime. Nobody asked for it and appearanty you didn't feel it's worth either. Richard. > > Diego. >
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On 04/05/2011 08:26 AM, Steven Bosscher wrote: > On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt wrote: > >> For i686-linux bootstraps it's hard to argue against it, but in general >> I find it easier to cope with the occasional broken tree than with >> getting patches reverted when you can't reproduce the failure. > > Maybe you find that easier, but auto-testers do not. The auto-testers serve the developers, not the other way round. Bernd
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 12:43 PM, Bernd Schmidt wrote: > On 04/05/2011 08:26 AM, Steven Bosscher wrote: >> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt >> wrote: >> >>> For i686-linux bootstraps it's hard to argue against it, but in general >>> I find it easier to cope with the occasional broken tree than with >>> getting patches reverted when you can't reproduce the failure. >> >> Maybe you find that easier, but auto-testers do not. > > The auto-testers serve the developers, not the other way round. At least our ones were completely unaffected and appearantly couldn't reproduce the bootstrap failure either. Richard.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
Hi, On Mon, Apr 04, 2011 at 03:51:21PM -0700, Ian Lance Taylor wrote: > Steven Bosscher writes: > > > My proposal would be: A patch may be reverted immediately by anyone > > with SVN write access if bootstrap is broken for more than 24 hours on > > any primary target. With proper notification to everyone involved, > > obviously. > > I agree. > > At the summit in October there was a discussion about this. I was on > the side of fast rollback for new failures. Would anybody care to > present the opposite view with regard to a patch like this? Can we > agree on fast rollback for bootstrap failures on x86/x86_64 GNU/Linux > systems? Depends on who would do it or have the right to do it. If the proposal is that just about anybody with SVN write access who has a bootstrap failure in their build and bisected it - or thinks they have bisected it - to a particular patch could revert the patch then I am against on the grounds that I do not trust all of these people to use common sense before acting. Having said that, I agree that broken trunk for more than a day is a very annoying and generally a very bad thing, be it a weekend or not. So I think that global reviewers and maintainers of the respected areas (or the patch authors themselves, for that matter) should be expected to approve reverting offending patches when this happens after some very basic evaluation of the situation because I trust them to use common sense. And there's no need to change the rules for that. Thanks, Martin
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 12:43 PM, Bernd Schmidt wrote: > On 04/05/2011 08:26 AM, Steven Bosscher wrote: >> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt >> wrote: >> >>> For i686-linux bootstraps it's hard to argue against it, but in general >>> I find it easier to cope with the occasional broken tree than with >>> getting patches reverted when you can't reproduce the failure. >> >> Maybe you find that easier, but auto-testers do not. > > The auto-testers serve the developers, not the other way round. The auto-testers serve no-one if they are broken. And developers also serve other developers. If you had just reverted your patches after being "mobbed" then we would not have this discussion in the first place. Ciao! Steven
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 12:33 PM, Richard Guenther wrote: > The course of action is to simply ask the offender to revert his patches for > now. It has worked reliably in the past, but I can't see any such suggestion > in this particular case (on the mailing-list). You are right that no-one asked. Actually, I think most people expected the problem to be resolved sooner, either with a fix or by a temporary reverted commit. In this case Bernd could not reproduce the issue and that slowed things down of course. But personally, I would have reverted the patch for the moment and try to figure out the problem before re-committing. That's also worked reliably in the past (Vlad did so recentlty for his IRA improvements, for example) and that's the decent thing to do. The whole policy we're discussing here is a last resort. Ciao! Steven
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 12:38, Richard Guenther wrote: > Nobody asked for it and appearanty you didn't feel it's worth either. Only because it didn't occur to me at the time. I would've, otherwise. Diego.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On 04/05/2011 08:26 AM, Steven Bosscher wrote: > I don't understand, really, why it's such a big deal to revert a patch > quickly if it broke something. To answer this as well, firstly a proposal that comes with a request to revert the wrong patch discredits itself. Breaking stuff by accident is a fact of life with gcc. You have to give people the chance to investigate and understand the problems. Since I know what it's like to break things by accident, I don't like to shout and complain at others when it happens to them, especially since it's never been more than an inconvenience for me if a particular revision of trunk was broken. I just use an earlier one, or revert the problematic patch. We're in stage 1, and this isn't primarily about keeping the autotesters happy. If that was our goal we'd stay in stage 4. > You feel mobbed and I'm sorry you feel that > way, but it shows that a lot of people tried to work on GCC in that > weekend. Actually, this happened _after_ I checked in the fix for the bootstrap issue (well, HJ checked it in without waiting for the test results). When the tree was working again, you, HJ and bkoz decided that my patches needed to be reverted, based on no actual facts whatsoever. This demonstrates that we need to be careful, and that the decision to revert something cannot be left to the whims of random people. Once I managed to reproduce the problem I gave an ETA for the fix. After that (on Sunday and early Monday) there was little activity on the bug. No one asked me to revert anything until _after_ the problem was fixed. Bernd
Re: constraints for push byte on word-aligned stack
On Tue, Apr 5, 2011 at 2:35 AM, Andreas Schwab wrote: > Peter Bigot writes: > >> I have a target that supports a "push.b x" operation that puts a byte onto >> the stack but pre-decrements the stack pointer by 2 to maintain alignment. > > That looks like the same as what m68k does, see PUSH_ROUNDING. Thanks. In my existing machine description, PUSH_ROUNDING is already set. m68k is one of the three machine descriptions that explicitly uses pushm1 instructions rather than mov expanders, regardless of PUSH_ROUNDING. Perhaps that's the magic; in fact, pushqi1 seems to be the only the only variant ever implemented. It's not that push isn't working, it's that I'm surprised that the tree-to-rtl translation generates a RTL expression that passes push_operand() but not the "<" constraint, but only in a case where PUSH_ROUNDING has an effect. I'll try to look into pushqi1 sometime, but for now using =X seems to work fine. Peter
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 1:39 PM, Bernd Schmidt wrote: > On 04/05/2011 08:26 AM, Steven Bosscher wrote: >> I don't understand, really, why it's such a big deal to revert a patch >> quickly if it broke something. > > To answer this as well, firstly a proposal that comes with a request to > revert the wrong patch discredits itself. Agreed. Note that in this particular case (and in most cases I can remember) the commit that broke things was identified correctly. This is what HJ's autotester is really good at. > Breaking stuff by accident is a fact of life with gcc. Definitely agreed. See PR48441. > You have to give > people the chance to investigate and understand the problems. Since I > know what it's like to break things by accident, I don't like to shout > and complain at others when it happens to them, especially since it's > never been more than an inconvenience for me if a particular revision of > trunk was broken. I just use an earlier one, or revert the problematic > patch. That is what most people do. The breakage wasn't much of a concern to me except for the duration and the point about the autotesters. In my perception, there was no shouting and not that much complaining. People reported breakage, and some people even tried to help figure out what was wrong (that is now I noticed the incorrect use of the VEC stuff). But the part of the compiler that you touched is not well known to most developers. Maybe two or three people really know that code, and you're one of them. No-one else could have investigated and understood the problem properly in such a short time. However, my point is that developers can investigate breakage without keeping the trunk broken. It is easy to revert a patch, investigate off-line, and come back for another try if the problem is identified and fixed. Your point of view is that it's OK to keep the tree broken while one developer is investigating a problem. My point of view is that it is not right to inconvenience other developers like this. > Actually, this happened _after_ I checked in the fix for the bootstrap > issue (well, HJ checked it in without waiting for the test results). > When the tree was working again, you, HJ and bkoz decided that my > patches needed to be reverted, based on no actual facts whatsoever. This > demonstrates that we need to be careful, and that the decision to revert > something cannot be left to the whims of random people. I had hopes that HJ, bkoz, Pinski and I are not "random people", but I suppose that's misplaced arrogance ;-) The proposal is not to let random people decide, but even if it did then a proposal is something to discuss and to find a compromise. If you are open to other points of view and willing to find common ground, then we should be talking about what would be an acceptable change of the 48hr policy instead. That'd be more constructive. > Once I managed to reproduce the problem I gave an ETA for the fix. After > that (on Sunday and early Monday) there was little activity on the bug. > No one asked me to revert anything until _after_ the problem was fixed. I don't think anyone expected you to _not_ revert the patches in the mean time, actually :-) It's what I would have done if I'd be in a situation like this, and what happened most of the time in similar situations in recent history. But that's not currently required and you didn't do anything wrong AFAICT. It's just that the pace of checkins/checkouts in GCC is so fast these days, that the 48hr policy seems like a dinosaur to me :-) Ciao! Steven
VIRTUAL_STACK_VARS_REGNUM vs VIRTUAL_STACK_DYNAMIC_REGNUM
Hello,
Can anyone familiar with backend explain to me when we use
VIRTUAL_STACK_VARS_REGNUM (or) VIRTUAL_STACK_DYNAMIC_REGNUM in gcc?
Rather, when does the compiler decide to allocate a variable to
stack_vars region and when to stack_dynamic?
I encountered some trouble with virtual-stack-vars. Since it gets
translated to FRAME_POINTER_REGNUM and we don't actually have a
dedicated frame pointer register in picochip, i got a compiler ICE. I
have set ELIMINABLE_REGS to eliminate FRAME_POINTER in preference to
STACK_POINTER, but it doesn't work in this case (presumably
because FRAME_POINTER is used in a memory reference and elimination does
not work well with memory)
In the attached C code, at expand it saves the result from each call to
getPort function to the virtual_stack_vars region and then copies it
from there into virtual_stack_dynamic region. Why can it not copy
straight into virtual_stack_dynamic region? In the example, if i were to
write to the "int32_elements" instead of cmplx_elements, it does work
fine by writing it directly into virtual_stack_dynamic region.
I have attached the compiler dumps from expand, sched and ira for reference.
I tried this on GCC 4.6.0 release compiler. The port has had some local
changes for vector support, which i will submit into mainline after a while.
Cheers
Hari
#include
#define vector __attribute__((vector_size(16) ))
typedef signed short integer16;
typedef signed long integer32;
typedef struct complex16 {
integer16 re;
integer16 im;
} complex16;
long __builtin_get (int);
static inline complex16 getPort1(void) __attribute__((always_inline));
static inline complex16 getPort1(void) {
union{complex16 actualValue; long rawValue; } converter;
converter.rawValue = __builtin_get(1);
return converter.actualValue;
}
typedef union
{
complex16 cmplx_elements[4];
int32_t int32_elements[4];
vector int all_elements;
} vectComplex;
int fn1 (vector int * a)
{
vectComplex x;
x.cmplx_elements [0] = getPort1();
x.cmplx_elements [1] = getPort1();
x.cmplx_elements [2] = getPort1();
x.cmplx_elements [3] = getPort1();
a[0] = x.all_elements;
return 5;
}
;; Function fn1 (fn1)
fn1 (vector(8) int * a)
{
long int D.2134;
struct complex16 D.2133;
long int D.2129;
struct complex16 D.2128;
long int D.2124;
struct complex16 D.2123;
long int D.2119;
struct complex16 D.2118;
union vectComplex x;
vector(8) int D.2106;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
D.2119_10 = __builtin_get (1);
# DEBUG converter$rawValue => D.2119_10
MEM[(struct complex16 *)&D.2118].rawValue = D.2119_10;
x.cmplx_elements[0] = D.2118;
D.2124_11 = __builtin_get (1);
# DEBUG converter$rawValue => D.2124_11
MEM[(struct complex16 *)&D.2123].rawValue = D.2124_11;
x.cmplx_elements[1] = D.2123;
D.2129_12 = __builtin_get (1);
# DEBUG converter$rawValue => D.2129_12
MEM[(struct complex16 *)&D.2128].rawValue = D.2129_12;
x.cmplx_elements[2] = D.2128;
D.2134_13 = __builtin_get (1);
# DEBUG converter$rawValue => D.2134_13
MEM[(struct complex16 *)&D.2133].rawValue = D.2134_13;
x.cmplx_elements[3] = D.2133;
D.2106_1 = x.all_elements;
*a_2(D) = D.2106_1;
return 5;
# SUCC: EXIT [100.0%]
}
Partition map
Partition 1 (D.2106_1 - 1 )
Partition 2 (a_2(D) - 2 )
Partition 4 (.MEM_4(D) - 4 )
Partition 5 (.MEM_5 - 5 )
Partition 6 (.MEM_6 - 6 )
Partition 7 (.MEM_7 - 7 )
Partition 8 (.MEM_8 - 8 )
Partition 9 (.MEM_9 - 9 )
Partition 10 (D.2119_10 - 10 )
Partition 11 (D.2124_11 - 11 )
Partition 12 (D.2129_12 - 12 )
Partition 13 (D.2134_13 - 13 )
Partition 14 (.MEM_14 - 14 )
Partition 15 (.MEM_15 - 15 )
Partition 16 (.MEM_16 - 16 )
Partition 17 (.MEM_17 - 17 )
Partition 18 (.MEM_18 - 18 )
Partition 19 (.MEM_19 - 19 )
Partition 20 (.MEM_20 - 20 )
Partition 21 (.MEM_21 - 21 )
Partition 22 (.MEM_22 - 22 )
Partition 23 (.MEM_23 - 23 )
Partition 24 (.MEM_24 - 24 )
Partition 25 (.MEM_25 - 25 )
Partition map
Partition 0 (a_2(D) - 2 )
Live on entry to BB2 : a_2(D)
Conflict graph:
After sorting:
Coalesce List:
Partition map
Partition 0 (a_2(D) - 2 )
After Coalescing:
Partition map
Partition 0 (D.2106_1 - 1 )
Partition 1 (a_2(D) - 2 )
Partition 2 (D.2119_10 - 10 )
Partition 3 (D.2124_11 - 11 )
Partition 4 (D.2129_12 - 12 )
Partition 5 (D.2134_13 - 13 )
Replacing Expressions
D.2106_1 replace with --> D.2106_1 = x.all_elements;
fn1 (vector(8) int * a)
{
long int D.2134;
struct complex16 D.2133;
long int D.2129;
struct complex16 D.2128;
long int D.2124;
struct complex16 D.2123;
long int D.2119;
struct complex16 D.2118;
union vectComplex x;
vector(8) int D.2106;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
D.2119_10 = __builtin_get (1);
# DEBUG converter$rawValue => D.2119_10
MEM[(struct complex16 *)&D.2118].rawValue = D.2119_10;
x.cmplx_elements[0] = D.2118;
D.2124_11 = __builtin_get (1);
# DEBUG converter$rawValue => D.2124_11
MEM[(struct
Re: IRA/reload make bulky code: why stack slots where GPR is fine?
Georg-Johann Lay writes: > With new versions of gcc from trunk (like last snapshot SVN 171894), I > observe very bad code from register allocator. Could you check whether: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02053.html fixes the problem? It'd be nice to know if it's the same thing, or something else. Richard
Re: Give me advice on GSoC OpenMP
From: Jakub Jelinek Date: Tue, 5 Apr 2011 08:33:23 +0200 > On Tue, Apr 05, 2011 at 11:05:01AM +0900, Sho Nakatani wrote: >> - When task A encounters "#pragma omp task" derective, worker creates a >> task >> and immediately execute it. Worker pushes A to the head of deque. > > Immediately starting a freshly created task on #pragma omp task is nice for > cache > locality, ... Yes. Also, Lazy Task Creation has another good aspect. Look at the pictures below. Both shows the call-tree of fibonacci(8). One is compiled by gcc and the other is by icc. (GCC) https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-gcc.png (ICC) https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-icc.png Each node with the same color represents the task which is processed on the same thread (or core). These pictures show that the program compiled by icc, which might use Lazy Task Creation, executes nodes in subtree on the same core, while that compiled by gcc doesn't. Of course, fib(8) is doesn't clearly show if Lazy Task Creation really has good effect for the programs that need sophisticated parallelization. But other researches like https://iwomp.zih.tu-dresden.de/downloads/runtime-olivier.pdf also point out it. My teacher and senior associates know good about Lazy Task Creation and I also learned it by some Japanese paper. My teacher recommended me a paper related to Lazy Task Creation (in English). Please google the query and take a look at it if you have a time. "Lazy Task Creation: A Technique for Increasing the Granularity of Parallel Programs" > Immediately starting a freshly created task on #pragma omp task is nice for > cache > locality, except it doesn't work at all for tied tasks which you can't move > to other > threads. For tied tasks (and GCC currently has all tasks tied) it serializes > everything. Then, how about implementing `untied task' as a GSoC project? If it goes successful, I'll tackle better `tied task' also. What do you think about this idea? I'd like to write my proposal tomorrow :-) -- Sho Nakatani
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 02:50, Eric Botcazou wrote: >> I definitely think that if there is a policy change that an allowance be >> made for weekends/holidays and that if a patch has been identified and >> the offender has acknowledged the issue and is actively working on the >> problem give the offender time to resolve the issue. > > This weekends/holidays allowance would be dangerous and counter-productive: > people would rush to install risky changes on Friday and leave for the > week-end fingers crossed. This would be worse than the current policy IMO. If we have any such developers, then, frankly, those developer's patches should be ignored. Personally, I don't think we have any developers that want to throw stuff over the wall in that manner. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmxM4AAoJEBRtltQi2kC7LNoH/RY8IOj+kcsOBb3+XqEu8sGl GX62E4MOvklNz9l441TGT40aAsCaK2a6KQfJ7xfeQbOM6iwLZ5LKDafaqPjEpB3W zllqae9EZdA8qrRV+oi/dQLvVAsUU9T3G/83VyxU9SfkjzTC6VWZP/v1/6BUx4pO /yVDi5hoVIiM+KuP2y0bPrhHxugseft6VAuPH4s+OFR3rM991S9DawPx6jBPljsZ QTDuxAptzBfmxOaIg+MDfGA1qMpCY/5lhPu41ILbTAgh8RD+ZI03131WdzuNwk7K duxhUJUdhHW2Y74U3dBesDLg/wRx/oXCB2h63azhJayavPQ5NNFOPc48Br+voTk= =sU5a -END PGP SIGNATURE-
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 5:23 AM, Steven Bosscher wrote: > On Tue, Apr 5, 2011 at 1:39 PM, Bernd Schmidt wrote: >> On 04/05/2011 08:26 AM, Steven Bosscher wrote: >>> I don't understand, really, why it's such a big deal to revert a patch >>> quickly if it broke something. >> >> To answer this as well, firstly a proposal that comes with a request to >> revert the wrong patch discredits itself. > > Agreed. Note that in this particular case (and in most cases I can > remember) the commit that broke things was identified correctly. This > is what HJ's autotester is really good at. > >> Breaking stuff by accident is a fact of life with gcc. > > Definitely agreed. See PR48441. > There is another bootstrap failure: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48148 detected by my autotester. Since it only affects very few people, reverting it may not be the best course. But breaking trunk for most of developers for 3 days isn't a very good idea. -- H.J.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On 04/05/2011 02:23 PM, Steven Bosscher wrote: > However, my point is that developers can investigate breakage without > keeping the trunk broken. If they can reproduce it; you don't always have access to the system that shows the breakage. A reversion policy that's too trigger-happy can leave you unable to make forward progress on an important patch. At the very least you'd need to write in stone that a patch can be reinstalled if the reporter of the problem is unwilling to assist in debugging or testing candidate patches. I agree that i686-linux bootstraps could be treated slightly more aggressively, but I'd still like to limit the set of people who can make such a decision. In this particular case, if anyone wanted the patch reverted they should have said something on Friday or Saturday. The scale of the problem wasn't apparent to me at the beginning since I was bootstrapping successfully on two different machines, both on x86_64 and i686 (admittedly due to idiocy in the way I was configuring the compiler). Bernd
[PATCH, ARM] Switch to EABI version 5 for RTEMS
Hello,
there were several requests for ARM Cortex-M support on RTEMS recently. The
first step towards this is a suitable ARM tool chain. I want to use this event
to clean up the multilibs and switch to the EABI version 5. The benefit of
EABI version 5 is that this brings RTEMS more in line with the primary GCC
platform arm-linux-gnueabi. For standards related to this please have a look
at the following documents.
Base Platform ABI for the ARM Architecture (BPABI):
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0037b/IHI0037B_bpabi.pdf
ARM Architecture Procedure Call Standard (AAPCS):
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
ELF for the ARM Architecture:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf
The EABI makes the VFP floating point architecture mandatory and enables us to
use hardware floating point support in the future. RTEMS has currently no
support for hardware floating point units (the context switch part is missing).
The Thumb interwork support is mandatory with this ABI. The exception handling
implementation changes from SJLJ to unwind tables (DWARF 2).
I propose to change the ARM multilibs as follows:
1. Default: armv4, ARM
2. thumb: armv4t, Thumb
3. armv6-m: armv6-m, subset of Thumb 2
4. armv7: armv7, Thumb 2
5. armv7-m: armv7-m, Thumb 2, hardware integer division (SDIV/UDIV)
Multilib 1. and 2. support the standard ARM7TDMI and ARM926EJ-S targets.
Multilib 3. supports the Cortex-M0 and Cortex-M1 cores.
Multilib 5. supports the Cortex-M3 and Cortex-M4 cores, which have a special
hardware integer division instruction (this is not present in the A and R
profiles).
Multilib 4. supports Cortex-A and Cortex-R variants.
Does this make sense? Please have a look at the attached patch.
What bothers me a bit, is that some functions of libgcc are compiled
unnecessarily with the -fexceptions flag. This pulls in the unwind mechanic
for simple things like
int64_t f(int64_t a, int64_t b)
{
return a / b;
}
Is is possible to make parts of libgcc/Makefile.am target specific?
Have a nice day!
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
2011-04-05 Sebastian Huber
* config.gcc (arm*-*-rtems*), config/arm/rtems-elf.h: Switch to ARM
EABI version 5.
* config/arm/t-rtems: Provide multilibs for ARMv4, ARMv4T, ARMv6M,
ARMv7, and ARMv7M.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 58f6787..421279d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -895,8 +895,14 @@ arm*-*-eabi* | arm*-*-symbianelf* )
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
arm*-*-rtems*)
- tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h"
- tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
+ need_64bit_hwint=yes
+ default_use_cxa_atexit=yes
+ tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h"
+ tm_file="${tm_file} ../../libgcc/config/arm/bpabi-lib.h"
+ tm_file="${tm_file} rtems.h arm/rtems-elf.h newlib-stdint.h"
+ tm_file="${tm_file} arm/aout.h arm/arm.h"
+ tmake_file="arm/t-arm arm/t-arm-elf"
+ tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems"
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
arm*-*-elf)
diff --git a/gcc/config/arm/rtems-elf.h b/gcc/config/arm/rtems-elf.h
index dade74b..ad7e5b8 100644
--- a/gcc/config/arm/rtems-elf.h
+++ b/gcc/config/arm/rtems-elf.h
@@ -23,23 +23,10 @@
#define HAS_INIT_SECTION
+#undef TARGET_OS_CPP_BUILTINS
#define TARGET_OS_CPP_BUILTINS() \
do { \
builtin_define ("__rtems__"); \
- builtin_define ("__USE_INIT_FINI__"); \
builtin_assert ("system=rtems"); \
+ TARGET_BPABI_CPP_BUILTINS(); \
} while (0)
-
-/*
- * The default in gcc now is soft-float, but gcc misses it to
- * pass it to the assembler.
- */
-#undef SUBTARGET_EXTRA_ASM_SPEC
-#define SUBTARGET_EXTRA_ASM_SPEC "\
- %{!mhard-float: %{!msoft-float:-mfpu=softfpa}}"
-
-/*
- * The default includes --start-group and --end-group which conflicts
- * with how this used to be defined.
- */
-#undef LINK_GCC_C_SEQUENCE_SPEC
diff --git a/gcc/config/arm/t-rtems b/gcc/config/arm/t-rtems
index 52d14ba..9c68dc0 100644
--- a/gcc/config/arm/t-rtems
+++ b/gcc/config/arm/t-rtems
@@ -1,10 +1,6 @@
# Custom rtems multilibs
-MULTILIB_OPTIONS = marm/mthumb
-MULTILIB_DIRNAMES= arm thumb
-MULTILIB_EXCEPTIONS =
-MULTILIB_MATCHES = marm=mno-thumb
-
-MULTILIB_OPTIONS+= msoft-float/mhard-float
-MULTILIB_DIRNAMES += soft fpu
-MULTILIB_EXCEPTIONS += *mthumb/*mhard-float*
+MULTILIB_OPTIONS= mthumb march=armv6-m/march=armv7/march=armv7-m
+MULTILIB_DIRNAMES = thumb armv6-m armv7 armv7-m
+MULTILIB_EXCEPTIO
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
> A reversion policy that's too trigger-happy can leave you unable to > make forward progress on an important patch. At the very least you'd > need to write in stone that a patch can be reinstalled if the > reporter of the problem is unwilling to assist in debugging or > testing candidate patches. Although I certainly agree that the tree shouldn't remain broken, I'm also sympathetic to the need to be able to have an environment in which the developer can debug the patch because it presumably didn't fail in their environment if they commited it.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 03:49, Diego Novillo wrote: > On Tue, Apr 5, 2011 at 10:50, Eric Botcazou wrote: >>> I definitely think that if there is a policy change that an allowance be >>> made for weekends/holidays and that if a patch has been identified and >>> the offender has acknowledged the issue and is actively working on the >>> problem give the offender time to resolve the issue. >> >> This weekends/holidays allowance would be dangerous and counter-productive: >> people would rush to install risky changes on Friday and leave for the >> week-end fingers crossed. This would be worse than the current policy IMO. > > I agree. If it's broken, it should be taken out. It doesn't make a > lot of difference to the patch owner, and if the fix takes more than a > day or so to be produced, then the cost of the breakage is much > higher. As an example, I recently broke ObjC++, and the fix for it > took more than 3-4 days to get in. My patch should've been reverted > in the meantime. It can make a huge difference if the owner has been unable to reproduce and is waiting on the reporter to provide enough information to reproduce or debug the problem. I the case of the current x86 breakage, the only problem I've been aware of was an internal report from bkoz that bootstrap was breaking on x86_64 (with no other details). Meanwhile my bootstraps were running fine. It wasn't until HJ's autotester reported the key "--disable-checking" configury bits that we were able to confirm a problem and start the real process of diagnosing what went wrong. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmxxoAAoJEBRtltQi2kC7ShUH/A5sQ+9Hyu3E9AxEyyVWuCl8 FSu/szFMK4Qm/ES9LzFp/uVgfF9f5qKQSIJ9h4zC6IiByJqgerlBt3y2SpN3RZhS OMh76Jk7bnVjeOoHes1ZLxkWN3Eey73Q57WyH9jyqmSouTZqpPG686QBd17Lkslu 79d6BVz3YCFagZtNGES74HJAMJUrlrt5ywu1UEwKvMVrOOjOgLv4mzJ/xwb+3nM+ yRt9AcIm5adzqdiqg5TPb4ncm67BD34lwQOzJATgrc724+9jp0TQMhcC5U/AoOGS vExVGwxyS8Zhl2JOa5oSl3Re+fXcczUwfkhn5Nfncxr2yo/JVuV3m4309Rz6/kw= =hC4Y -END PGP SIGNATURE-
Re: Give me advice on GSoC OpenMP
On Tue, Apr 5, 2011 at 3:01 PM, Sho Nakatani wrote: > From: Jakub Jelinek > Date: Tue, 5 Apr 2011 08:33:23 +0200 > >> On Tue, Apr 05, 2011 at 11:05:01AM +0900, Sho Nakatani wrote: >>> - When task A encounters "#pragma omp task" derective, worker creates a >>> task >>> and immediately execute it. Worker pushes A to the head of deque. >> >> Immediately starting a freshly created task on #pragma omp task is nice for >> cache >> locality, ... > > Yes. Also, Lazy Task Creation has another good aspect. > Look at the pictures below. Both shows the call-tree of fibonacci(8). > One is compiled by gcc and the other is by icc. > > (GCC) > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-gcc.png > (ICC) > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-icc.png > > Each node with the same color represents the task which is processed on the > same > thread (or core). > These pictures show that the program compiled by icc, which might use Lazy > Task Creation, > executes nodes in subtree on the same core, while that compiled by gcc > doesn't. > Of course, fib(8) is doesn't clearly show if Lazy Task Creation really has > good effect > for the programs that need sophisticated parallelization. But other > researches like > https://iwomp.zih.tu-dresden.de/downloads/runtime-olivier.pdf > also point out it. > > My teacher and senior associates know good about Lazy Task Creation and I > also learned it > by some Japanese paper. > My teacher recommended me a paper related to Lazy Task Creation (in English). > Please google the query and take a look at it if you have a time. > "Lazy Task Creation: A Technique for Increasing the Granularity of > Parallel Programs" > > >> Immediately starting a freshly created task on #pragma omp task is nice for >> cache >> locality, except it doesn't work at all for tied tasks which you can't move >> to other >> threads. For tied tasks (and GCC currently has all tasks tied) it serializes >> everything. > > Then, how about implementing `untied task' as a GSoC project? > If it goes successful, I'll tackle better `tied task' also. > What do you think about this idea? > I'd like to write my proposal tomorrow :-) I think this could indeed be quite interesting, and a much needed improvement to GCC's OpenMP runtime. The overall idea behind Lazy Task Creation looks good. However, I would recommend starting with bibliographical work. I'm certain this solution could be an improvement over the current state, but it would be nice to know how it compares to other techniques, and also if there are slowdowns in less dynamic and unbalanced cases. The work I'm aware of in this area is "Evaluation of OpenMP task scheduling strategies" by Duran et al (http://www.sarc-ip.org/files/null/Workshop/1234128788173__TSchedStrat-iwomp08.pdf). It could be a reasonable starting point. You may also want to make sure the scheduling policy it enforces cannot interfere with OpenMP semantics. For example, how would the lazy task creation behave if a worker steals a bottom-of-the-stack task that has a taskwait and the tasks bound to this synchronization are left in the other worker's dequeue? There can be deadlock issues or just plain performance issues that can arise. I can't see any obvious issues, but it's worth thinking about. I believe the GSoC idea for working on the libGOMP scheduler is great! Antoniu
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 6:43 AM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/05/11 03:49, Diego Novillo wrote: >> On Tue, Apr 5, 2011 at 10:50, Eric Botcazou wrote: I definitely think that if there is a policy change that an allowance be made for weekends/holidays and that if a patch has been identified and the offender has acknowledged the issue and is actively working on the problem give the offender time to resolve the issue. >>> >>> This weekends/holidays allowance would be dangerous and counter-productive: >>> people would rush to install risky changes on Friday and leave for the >>> week-end fingers crossed. This would be worse than the current policy IMO. >> >> I agree. If it's broken, it should be taken out. It doesn't make a >> lot of difference to the patch owner, and if the fix takes more than a >> day or so to be produced, then the cost of the breakage is much >> higher. As an example, I recently broke ObjC++, and the fix for it >> took more than 3-4 days to get in. My patch should've been reverted >> in the meantime. > It can make a huge difference if the owner has been unable to reproduce > and is waiting on the reporter to provide enough information to > reproduce or debug the problem. In the case of PR 48403, it seems that most of developers see it. Only very few people weren't affected. I don't think everyone else should stop and wait for developer to reproduce it. -- H.J.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
> I the case of the current x86 breakage, the only problem I've been aware > of was an internal report from bkoz that bootstrap was breaking on > x86_64 (with no other details). Meanwhile my bootstraps were running > fine. It wasn't until HJ's autotester reported the key > "--disable-checking" configury bits that we were able to confirm a > problem and start the real process of diagnosing what went wrong. No, this isn't what happened, see the audit trail of PR48403. This was a big breakage. --disable-checking had nothing to do with the problem either. -- Eric Botcazou
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 08:15, Eric Botcazou wrote: >> I the case of the current x86 breakage, the only problem I've been aware >> of was an internal report from bkoz that bootstrap was breaking on >> x86_64 (with no other details). Meanwhile my bootstraps were running >> fine. It wasn't until HJ's autotester reported the key >> "--disable-checking" configury bits that we were able to confirm a >> problem and start the real process of diagnosing what went wrong. > > No, this isn't what happened, see the audit trail of PR48403. This was a big > breakage. --disable-checking had nothing to do with the problem either. - --disable-checking is the trigger for the bootstrap comparison failures I'm tracking right now. These may be separate from 48403. Which highlights the problem of reverting without doing an in-depth analysis of the problem. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmyTyAAoJEBRtltQi2kC79qIH/0+i+oE5gPYMvPmxuhNnVuAE VIedv6UiVStBIxm/bCyaVDZHdiPnldEEoKfANe7UT8WmEXD/iRNYJ3ZBG7JU8Qk6 9Ahq8pSYaYsyRO2BJgiH2WIXJxz9qvH4BDYmxWUmJ+h80q0qnKlCrcZsgSqW4IIy xwHa/ePXnXNmpuuRPpQFpv0pQgco4G7xDCUwn1UXZdkKCJulzHUwLcB1WP/urR/i HPuLfbzyD62ZpI2NKfiCJAm5xOh/2RJYqs9XTKGg5qsBlOf/BQ2yERTSjWiLykF/ FgDbxydIcSJv7nUbcwNH6rrII1WFTCg4JRS8/RPSS8jtwkxTAVyEJhopncUDLl4= =EzTa -END PGP SIGNATURE-
Re: Give me advice on GSoC OpenMP
On Tue, Apr 05, 2011 at 03:45:26PM +0200, Antoniu Pop wrote: > On Tue, Apr 5, 2011 at 3:01 PM, Sho Nakatani wrote: > > From: Jakub Jelinek > > Date: Tue, 5 Apr 2011 08:33:23 +0200 > > Yes. Also, Lazy Task Creation has another good aspect. > > Look at the pictures below. Both shows the call-tree of fibonacci(8). > > One is compiled by gcc and the other is by icc. > > > > (GCC) > > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-gcc.png > > (ICC) > > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-icc.png As your testcase doesn't have untied keywords, I doubt ICC uses such scheduling for it. See also the paper Antoniu referenced, e.g. figure 7 in there. If you want to do something about task scheduling as a GSoC project, you are certainly welcome, but starting with the idea that you want to implement Lazy Task Creation is probably not a good idea, you want to read a bunch of papers, download Mercurium project with its runtime OpenMP library, read it, see what they actually implement and how and if they have multiple strategies still implemented in there, see how they perform on the various OpenMP task testcases (we have some in libgomp testsuite, but the authors of Mercurium also have some testcases (called BOTS)), then try to implement some changes into libgomp/ and see how it performs on various testcases with various parameters. > You may also want to make sure the scheduling policy it enforces > cannot interfere with OpenMP semantics. For example, how would the > lazy task creation behave if a worker steals a bottom-of-the-stack > task that has a taskwait and the tasks bound to this synchronization > are left in the other worker's dequeue? There can be deadlock issues > or just plain performance issues that can arise. I can't see any > obvious issues, but it's worth thinking about. Tied tasks have quite strict rules on what can be actually scheduled, a new task to be scheduled must be descendant of all the tasks tied to current thread that aren't waiting in a barrier. Jakub
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/11 20:57, H.J. Lu wrote: > On Mon, Apr 4, 2011 at 7:51 PM, Jeff Law wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 04/04/11 16:20, H.J. Lu wrote: >>> On Mon, Apr 4, 2011 at 2:58 PM, Steven Bosscher >>> wrote: My proposal would be: A patch may be reverted immediately by anyone with SVN write access if bootstrap is broken for more than 24 hours on any primary target. With proper notification to everyone involved, obviously. >>> >>> I agree. >>> >>> FWIW, I reported the breakage and identified the cause within 8 hours of >>> the initial checkin. >> A report 8 hrs after a checkin may fall outside working for some >> developers, so they won't see it until the next work day. Obviously the >> developer would be expected to address the problem ASAP, but let's not >> get out of hand on reverting patches. >> > > Patch was checked in at Fri Apr 1 17:46:17 2011. I reported the failure > at 2011-04-01 18:49:28 and identified the range of causes. It is too bad > to take 3 days to fix it. Note the checking was Friday evening, it's entirely possible that the offender has a life and didn't work over the weekend. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmywCAAoJEBRtltQi2kC7fmMH/2aD3kNKhQ16PXTX3g3hrpCo JIpaTAbqB5/Pnx98q4/JqdgxJojORJcp/b+U8kzcdY2c7DisOzBMbz45eLSF7+b5 Dgy3TLnh9v2v5mfkd67SKSQTYO7YJEUO6LHBIp9VmW6brMIJCsBs9xiOhPi1D9iq 9UTCGKAjavCOnMT7So5HdzolqRIUZl4r7NlGtioQ5FZeMbmMxwJ9twGpL3yCTozJ UaaaFgnFjM2J2U2qAALgYJeWh4yBDeFvY+Bni0SvJlCrDi7RTUvPcMbO0Ec754Ho 0qprz7D5VckrW45N97OfAVUXRTG+ILubmh+l+l7UWFQLOzoI0mnvxX2XA8Cx8zM= =p5L1 -END PGP SIGNATURE-
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 7:49 AM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/04/11 20:57, H.J. Lu wrote: >> On Mon, Apr 4, 2011 at 7:51 PM, Jeff Law wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 04/04/11 16:20, H.J. Lu wrote: On Mon, Apr 4, 2011 at 2:58 PM, Steven Bosscher wrote: > > My proposal would be: A patch may be reverted immediately by anyone > with SVN write access if bootstrap is broken for more than 24 hours on > any primary target. With proper notification to everyone involved, > obviously. I agree. FWIW, I reported the breakage and identified the cause within 8 hours of the initial checkin. >>> A report 8 hrs after a checkin may fall outside working for some >>> developers, so they won't see it until the next work day. Obviously the >>> developer would be expected to address the problem ASAP, but let's not >>> get out of hand on reverting patches. >>> >> >> Patch was checked in at Fri Apr 1 17:46:17 2011. I reported the failure >> at 2011-04-01 18:49:28 and identified the range of causes. It is too bad >> to take 3 days to fix it. > Note the checking was Friday evening, it's entirely possible that the > offender has a life and didn't work over the weekend. > That is one major point. Many GCC developers may only have time to work on GCC on weekends. -- H.J.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 01:23, David Edelsohn wrote: > On Mon, Apr 4, 2011 at 10:30 PM, Jeff Law wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 04/04/11 19:14, Bernd Schmidt wrote: >>> Another danger is getting a mob effect as in PR48403 (which I've also >>> seen happen on other occasions) and getting the wrong set of patches >>> reverted by trigger-happy people. To be blunt, there are some people on >>> this list who tend to react panicky to bugs and skip proper analysis (as >>> in this case); I don't want to encourage such folks to revert stuff >>> willy-nilly. Sometimes you just need a bit of time and assistance from >>> testers who actually see the problem to understand it. >>> >>> If there's a change in policy I'd at least make allowances for weekends. >>> There's considerably less traffic on the mailing lists on Saturdays and >>> Sundays, which suggests few people will be inconvenienced if the tree is >>> broken during such a time. We also don't want everyone to only check >>> things in on Mondays because they worry they'll come back after a >>> weekend to find their stuff gone from the tree. >> I definitely think that if there is a policy change that an allowance be >> made for weekends/holidays and that if a patch has been identified and >> the offender has acknowledged the issue and is actively working on the >> problem give the offender time to resolve the issue. > > If a developer breaks bootstrap and cannot fix it immediately, the > patch should be reverted and the developer can fix the patch offline > and re-merge the patch. The focus of the policy should not be the > convenience of the developer who broke bootstrap on multiple targets. And what precisely does "immediately" mean in this context? 1 hour, 3 hours? If the breakage happens on a Friday evening, does the developer have until Monday morning to at least take a looksie? What if the problem exposes a heisenbug that is dependent on a variety of factors that happen to exist in the tree and on one tester's box (say stack layout due to environment size)? What does immediately mean when the developer isn't even aware his patch caused a problem for a week? Reversion shouldn't be how we start the process of dealing with breakage, it should be how we deal with it when the developer can't address the problem in a reasonable timeframe. Where reasonable is going to vary based on the specific circumstances. I hate breakages in the tree as much as the next guy and it absolutely frustrates the hell out of me. But I'd much rather give the developer a chance to see the bug and do some root cause analysis at a slight inconvenience to myself. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmy4qAAoJEBRtltQi2kC7vjsIAL2yFoRwp51Q+S4B8D121feF TIOMASNSyV6iaSaQAkLHBGW+DZS7sjwBHDnwHYxbiZNbs1BTNTaBnkpfRwhno7wH OJOKDSIFEf4cYo7Lm8BTCrqdWtbyc0kTIhoCNaEDRo1tWsGg7Pw0aUVS7tzHNadY P6vHCP0WIMEmSVtlTHKvS8Ae4UPBZ2FyD5bzXHBU/fuqaoPJZprWOsWl9I2Im+xy /SilV+6UYLThtY3Je4M8471Vu2TX0V+UcPCLTxUEBgwIARHEiDE/ehjfamkXTzFS byOgFhTGOosPltUkbSvcBEkcD8LnSI55+t8/sOsHv6LuaOOa2o18emPn3P7KQxY= =HcQ1 -END PGP SIGNATURE-
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 4:49 PM, Jeff Law wrote: >> Patch was checked in at Fri Apr 1 17:46:17 2011. I reported the failure >> at 2011-04-01 18:49:28 and identified the range of causes. It is too bad >> to take 3 days to fix it. > Note the checking was Friday evening, it's entirely possible that the > offender has a life and didn't work over the weekend. Hackers with a life?! :-) Ciao! Steven
Re: Give me advice on GSoC OpenMP
On Tue, Apr 5, 2011 at 4:37 PM, Jakub Jelinek wrote: > On Tue, Apr 05, 2011 at 03:45:26PM +0200, Antoniu Pop wrote: >> On Tue, Apr 5, 2011 at 3:01 PM, Sho Nakatani wrote: >> > From: Jakub Jelinek >> > Date: Tue, 5 Apr 2011 08:33:23 +0200 >> > Yes. Also, Lazy Task Creation has another good aspect. >> > Look at the pictures below. Both shows the call-tree of fibonacci(8). >> > One is compiled by gcc and the other is by icc. >> > >> > (GCC) >> > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-gcc.png >> > (ICC) >> > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-icc.png > > As your testcase doesn't have untied keywords, I doubt ICC uses such > scheduling > for it. > See also the paper Antoniu referenced, e.g. figure 7 in there. > > If you want to do something about task scheduling as a GSoC project, > you are certainly welcome, but starting with the idea that > you want to implement Lazy Task Creation is probably not a good idea, > you want to read a bunch of papers, download Mercurium project > with its runtime OpenMP library, read it, see what they actually implement > and how and if they have multiple strategies still implemented in there, > see how they perform on the various OpenMP task testcases (we have some > in libgomp testsuite, but the authors of Mercurium also have some testcases > (called BOTS)), then try to implement some changes into libgomp/ and see how > it performs on various testcases with various parameters. Indeed, the Lazy Task Creation scheme is 20 years old, which does not mean it isn't good, but it's very likely that much more has been done in that area. >> You may also want to make sure the scheduling policy it enforces >> cannot interfere with OpenMP semantics. For example, how would the >> lazy task creation behave if a worker steals a bottom-of-the-stack >> task that has a taskwait and the tasks bound to this synchronization >> are left in the other worker's dequeue? There can be deadlock issues >> or just plain performance issues that can arise. I can't see any >> obvious issues, but it's worth thinking about. > > Tied tasks have quite strict rules on what can be actually scheduled, > a new task to be scheduled must be descendant of all the tasks tied to current > thread that aren't waiting in a barrier. Yes, but I don't think Sho means to implement that for tied tasks. I agree that respecting the standard for tied tasks would preclude using this scheduling model. Antoniu
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 09:06, Steven Bosscher wrote: > On Tue, Apr 5, 2011 at 4:49 PM, Jeff Law wrote: >>> Patch was checked in at Fri Apr 1 17:46:17 2011. I reported the failure >>> at 2011-04-01 18:49:28 and identified the range of causes. It is too bad >>> to take 3 days to fix it. >> Note the checking was Friday evening, it's entirely possible that the >> offender has a life and didn't work over the weekend. > > Hackers with a life?! :-) We can never predict how things change :-) Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmzC2AAoJEBRtltQi2kC71m4H/3fn9UJQyWP1XF9RXLoP8ibw YN+z80bwr5yz9USm+QNSKtpoDh8p6OnMlnX8mcNf7ARj3qcRLp1u1Uuy/QHxASgH /3FBnLySS448+q6dc4nJ0lBjD3wUS0WZ72nS+w4KxO+2UPaWX+c7LIMtb/t/TGf6 QWaFjwcIMnWs74S11sqLkVdVKg34k2PQfZIwebB9yZkj7bVTv11W/qH8/HSjTU6W 7NtsL3nG8yy2wTYZRmaqlv6G9tcqgEncZOBu3eJtjT8+OVeoHf0GSQ6Htx0bueK9 6wWuwQLEUsRcFXtuG70JcvpscUhGRhqmSSezostMFsvMgvpRzWn9FQVwcSMgatk= =1mou -END PGP SIGNATURE-
Re: Give me advice on GSoC OpenMP
From: Jakub Jelinek Date: Tue, 5 Apr 2011 16:37:48 +0200 > On Tue, Apr 05, 2011 at 03:45:26PM +0200, Antoniu Pop wrote: >> On Tue, Apr 5, 2011 at 3:01 PM, Sho Nakatani wrote: >> > From: Jakub Jelinek >> > Date: Tue, 5 Apr 2011 08:33:23 +0200 >> > Yes. Also, Lazy Task Creation has another good aspect. >> > Look at the pictures below. Both shows the call-tree of fibonacci(8). >> > One is compiled by gcc and the other is by icc. >> > >> > (GCC) >> > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-gcc.png >> > (ICC) >> > https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-icc.png > > As your testcase doesn't have untied keywords, I doubt ICC uses such > scheduling > for it. > See also the paper Antoniu referenced, e.g. figure 7 in there. > > If you want to do something about task scheduling as a GSoC project, > you are certainly welcome, but starting with the idea that > you want to implement Lazy Task Creation is probably not a good idea, > you want to read a bunch of papers, download Mercurium project > with its runtime OpenMP library, read it, see what they actually implement > and how and if they have multiple strategies still implemented in there, > see how they perform on the various OpenMP task testcases (we have some > in libgomp testsuite, but the authors of Mercurium also have some testcases > (called BOTS)), then try to implement some changes into libgomp/ and see how > it performs on various testcases with various parameters. OK. I'll do it as soon as possible. Then, my current plan is: - Learn other implementations (as Antoniu said) - Learn Mercurium implementation - Implement the same/similar feature as Mercurium in libgomp/ , then evaluate it (This might be the first goal) - Implement Lazy Task Creation for `untied task' in libgomp/ , then evaluate it (If I could reach the first goal) Is this plan OK? Or do you have other better plans? >> You may also want to make sure the scheduling policy it enforces >> cannot interfere with OpenMP semantics. For example, how would the >> lazy task creation behave if a worker steals a bottom-of-the-stack >> task that has a taskwait and the tasks bound to this synchronization >> are left in the other worker's dequeue? There can be deadlock issues >> or just plain performance issues that can arise. I can't see any >> obvious issues, but it's worth thinking about. > > Tied tasks have quite strict rules on what can be actually scheduled, > a new task to be scheduled must be descendant of all the tasks tied to current > thread that aren't waiting in a barrier. > > Jakub -- Sho Nakatani
Re: Give me advice on GSoC OpenMP
On Wed, Apr 06, 2011 at 12:16:13AM +0900, Sho Nakatani wrote: > OK. I'll do it as soon as possible. > Then, my current plan is: > - Learn other implementations (as Antoniu said) > - Learn Mercurium implementation > - Implement the same/similar feature as Mercurium in libgomp/ , > then evaluate it > (This might be the first goal) > - Implement Lazy Task Creation for `untied task' in libgomp/ , > then evaluate it > (If I could reach the first goal) This would depend on implementing untied tasks, which is quite questionable thing and can be badly expensive too (while tied tasks can (and do currently) run on containing thread's stack, untied tasks need to have their own stacks and there needs to be a way to switch in between them, for which either you can use *context family of functions (deprecated, but could work at least on some targets), or come up with something target specific). >From Mercurium you probably don't need to study the actual C to C compiler, maybe just quickly what it generates for tasks, but primarily their runtime library. > Is this plan OK? Yeah (just that the last step depends on implementing untied tasks, you can certainly try to implement that (preferrably with minimal overhead for the default tied task model), but I guess that would take quite a lot of time to write and test it. Jakub
Re: Give me advice on GSoC OpenMP
From: Antoniu Pop Date: Tue, 5 Apr 2011 15:45:26 +0200 > On Tue, Apr 5, 2011 at 3:01 PM, Sho Nakatani wrote: >> From: Jakub Jelinek >> Date: Tue, 5 Apr 2011 08:33:23 +0200 >> >>> On Tue, Apr 05, 2011 at 11:05:01AM +0900, Sho Nakatani wrote: - When task A encounters "#pragma omp task" derective, worker creates a task and immediately execute it. Worker pushes A to the head of deque. >>> >>> Immediately starting a freshly created task on #pragma omp task is nice for >>> cache >>> locality, ... >> >> Yes. Also, Lazy Task Creation has another good aspect. >> Look at the pictures below. Both shows the call-tree of fibonacci(8). >> One is compiled by gcc and the other is by icc. >> >> (GCC) >> https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-gcc.png >> (ICC) >> https://github.com/laysakura/GCC-OpenMP-Speedup/raw/e5671e7f4175c3ac17c1543c93edf25dda2ae6ac/test/calltree/openmp-fibonacci-calltree-icc.png >> >> Each node with the same color represents the task which is processed on the >> same >> thread (or core). >> These pictures show that the program compiled by icc, which might use Lazy >> Task Creation, >> executes nodes in subtree on the same core, while that compiled by gcc >> doesn't. >> Of course, fib(8) is doesn't clearly show if Lazy Task Creation really has >> good effect >> for the programs that need sophisticated parallelization. But other >> researches like >> https://iwomp.zih.tu-dresden.de/downloads/runtime-olivier.pdf >> also point out it. >> >> My teacher and senior associates know good about Lazy Task Creation and I >> also learned it >> by some Japanese paper. >> My teacher recommended me a paper related to Lazy Task Creation (in English). >> Please google the query and take a look at it if you have a time. >> "Lazy Task Creation: A Technique for Increasing the Granularity of >> Parallel Programs" >> >> >>> Immediately starting a freshly created task on #pragma omp task is nice for >>> cache >>> locality, except it doesn't work at all for tied tasks which you can't move >>> to other >>> threads. For tied tasks (and GCC currently has all tasks tied) it >>> serializes >>> everything. >> >> Then, how about implementing `untied task' as a GSoC project? >> If it goes successful, I'll tackle better `tied task' also. >> What do you think about this idea? >> I'd like to write my proposal tomorrow :-) > > I think this could indeed be quite interesting, and a much needed > improvement to GCC's OpenMP runtime. The overall idea behind Lazy Task > Creation looks good. > However, I would recommend starting with bibliographical work. I'm > certain this solution could be an improvement over the current state, > but it would be nice to know how it compares to other techniques, and > also if there are slowdowns in less dynamic and unbalanced cases. > The work I'm aware of in this area is "Evaluation of OpenMP task > scheduling strategies" by Duran et al > (http://www.sarc-ip.org/files/null/Workshop/1234128788173__TSchedStrat-iwomp08.pdf). > It could be a reasonable starting point. > Thank you so much for the realistic idea. Making the libgomp implementation better is not an easy thing, so I'll learn a lot about other implementations. Learning things around parallel programming deeply surely helps my graduation thesis :-) > You may also want to make sure the scheduling policy it enforces > cannot interfere with OpenMP semantics. For example, how would the > lazy task creation behave if a worker steals a bottom-of-the-stack > task that has a taskwait and the tasks bound to this synchronization > are left in the other worker's dequeue? There can be deadlock issues > or just plain performance issues that can arise. I can't see any > obvious issues, but it's worth thinking about. > > I believe the GSoC idea for working on the libGOMP scheduler is great! > > Antoniu -- Sho Nakatani
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On 04/05/2011 04:49 PM, Jeff Law wrote: > On 04/04/11 20:57, H.J. Lu wrote: >> Patch was checked in at Fri Apr 1 17:46:17 2011. I reported the failure >> at 2011-04-01 18:49:28 and identified the range of causes. It is too bad >> to take 3 days to fix it. > Note the checking was Friday evening, it's entirely possible that the > offender has a life and didn't work over the weekend. The offender worked a number of hours Saturday to reproduce the problem and investigate its cause. When it became apparent in the very late evening that the fix would be more than a one-liner and would involve testing some nonstandard options on ppc, I posted a status update with an ETA. IMO that (or earlier) would have been a good moment for anyone who was unable to do development work on Sunday due to the breakage to ask for a revert, rather than overreact later _after_ the problem was fixed. My (incorrect) perspective at that point was still that I had successful bootstraps on two machines with three different installations of Linux, vs a failure on only one, and no one had asked for the patch to be reverted, so the problem was likely to be not too bad. The fact that other architectures than x86 were affected had also not been reported at the time. Bernd
Re: Give me advice on GSoC OpenMP
From: Jakub Jelinek Date: Tue, 5 Apr 2011 17:22:04 +0200 > On Wed, Apr 06, 2011 at 12:16:13AM +0900, Sho Nakatani wrote: >> OK. I'll do it as soon as possible. >> Then, my current plan is: >> - Learn other implementations (as Antoniu said) >> - Learn Mercurium implementation >> - Implement the same/similar feature as Mercurium in libgomp/ , >> then evaluate it >> (This might be the first goal) >> - Implement Lazy Task Creation for `untied task' in libgomp/ , >> then evaluate it >> (If I could reach the first goal) > > This would depend on implementing untied tasks, which is quite questionable > thing and can be badly expensive too (while tied tasks can (and do currently) > run on containing thread's stack, untied tasks need to have their own stacks > and there needs to be a way to switch in between them, for which either > you can use *context family of functions (deprecated, but could work > at least on some targets), or come up with something target specific). > > From Mercurium you probably don't need to study the actual C to C compiler, > maybe just quickly what it generates for tasks, but primarily their runtime > library. > >> Is this plan OK? > > Yeah (just that the last step depends on implementing untied tasks, > you can certainly try to implement that (preferrably with minimal > overhead for the default tied task model), but I guess that would take > quite a lot of time to write and test it. > > Jakub Thanks a lot for your kind advice. Then my latest plan is: - Learn other implementations (as Antoniu said) - Learn Mercurium implementation - Implement the same/similar feature as Mercurium in libgomp/ , then evaluate it (This is the goal for GSoC project) However, I currently know nothing about Mercurium. (Of course I'll read the documentation of Mercurium from now on) Does Mercurium implement both `tied task' and `untied task'? Should my goal be implementing both of them? -- Sho Nakatani
Re: Give me advice on GSoC OpenMP
On Wed, Apr 06, 2011 at 12:40:21AM +0900, Sho Nakatani wrote: > Thanks a lot for your kind advice. > Then my latest plan is: > - Learn other implementations (as Antoniu said) > - Learn Mercurium implementation > - Implement the same/similar feature as Mercurium in libgomp/ , > then evaluate it > (This is the goal for GSoC project) > > However, I currently know nothing about Mercurium. > (Of course I'll read the documentation of Mercurium from now on) > Does Mercurium implement both `tied task' and `untied task'? > Should my goal be implementing both of them? Given that the paper Antoniu referenced speaks about it being the testbed for the paper, I guess so. I think they implement untied tasks using some library they wrote, but all I did was download it and skim it for a couple of minutes. Anyway, I think more important is the first goal, improve scheduling of tied tasks, those are the default ones and probably most people will use just those. Only when you are done with that it would be IMHO a good idea to move to untied stuff. Jakub
Re: Give me advice on GSoC OpenMP
> Thanks a lot for your kind advice. > Then my latest plan is: > - Learn other implementations (as Antoniu said) > - Learn Mercurium implementation > - Implement the same/similar feature as Mercurium in libgomp/ , > then evaluate it > (This is the goal for GSoC project) > > However, I currently know nothing about Mercurium. > (Of course I'll read the documentation of Mercurium from now on) > Does Mercurium implement both `tied task' and `untied task'? As far as I know (I have not verified the source) they do. > Should my goal be implementing both of them? That would be great, though probably not an easy feat. Maybe just start with tied for now and see if you have enough time. Antoniu
Re: Give me advice on GSoC OpenMP
From: Jakub Jelinek Date: Tue, 5 Apr 2011 17:43:57 +0200 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Subject: Re: Give me advice on GSoC OpenMP > From: Jakub Jelinek > To: Sho Nakatani > Cc: gcc@gcc.gnu.org, antoniu@mines-paristech.fr > Date: Tue, 5 Apr 2011 17:43:57 +0200 > Reply-To: Jakub Jelinek > User-Agent: Mutt/1.5.21 (2010-09-15) > Received-SPF: pass (google.com: domain of ja...@redhat.com designates > 209.132.183.28 as permitted sender) client-ip=209.132.183.28; > > On Wed, Apr 06, 2011 at 12:40:21AM +0900, Sho Nakatani wrote: >> Thanks a lot for your kind advice. >> Then my latest plan is: >> - Learn other implementations (as Antoniu said) >> - Learn Mercurium implementation >> - Implement the same/similar feature as Mercurium in libgomp/ , >> then evaluate it >> (This is the goal for GSoC project) >> >> However, I currently know nothing about Mercurium. >> (Of course I'll read the documentation of Mercurium from now on) >> Does Mercurium implement both `tied task' and `untied task'? >> Should my goal be implementing both of them? > > Given that the paper Antoniu referenced speaks about it > being the testbed for the paper, I guess so. I think they > implement untied tasks using some library they wrote, > but all I did was download it and skim it for a couple of minutes. > > Anyway, I think more important is the first goal, improve scheduling > of tied tasks, those are the default ones and probably most people > will use just those. Only when you are done with that it would be IMHO OK. I've completely got my plan for GSoC! 1. Learn other implementations (as Antoniu said) 2. Learn Mercurium implementation (1. and 2. would be done concurrently ;-) ) 3. Implement the Mercurium `tied task' feature in libgomp/ , then evaluate it 4. Implement the Mercurium `untied task' feature in libgomp/ , then evaluate it (4. is optional) I'll write my proposal tomorrow (since it is 1:00 a.m. in Japan). I'll ask you check it. If you have a time, please examine it. Thanks, -- Sho Nakatani
Re: Give me advice on GSoC OpenMP
From: Antoniu Pop Date: Tue, 5 Apr 2011 17:45:18 +0200 >> Thanks a lot for your kind advice. >> Then my latest plan is: >> - Learn other implementations (as Antoniu said) >> - Learn Mercurium implementation >> - Implement the same/similar feature as Mercurium in libgomp/ , >> then evaluate it >> (This is the goal for GSoC project) >> >> However, I currently know nothing about Mercurium. >> (Of course I'll read the documentation of Mercurium from now on) >> Does Mercurium implement both `tied task' and `untied task'? > > As far as I know (I have not verified the source) they do. That's important information. If you remember the source, please tell me about it. >> Should my goal be implementing both of them? > > That would be great, though probably not an easy feat. Maybe just > start with tied for now and see if you have enough time. Yeah. Although it is difficult to implement both tied and untied task, I'll continue to try them after GSoC term finish. > Antoniu Thanks, -- Sho Nakatani
Re: Give me advice on GSoC OpenMP
>> >> As far as I know (I have not verified the source) they do. > > That's important information. > If you remember the source, please tell me about it. Sorry, I meant I didn't verify the "source code" :) Jakub is right though, the paper clearly presents performance results on tied vs. untied, so this confirms they have both. >>> Should my goal be implementing both of them? >> >> That would be great, though probably not an easy feat. Maybe just >> start with tied for now and see if you have enough time. > > Yeah. Although it is difficult to implement both tied and untied task, > I'll continue to try them after GSoC term finish. Great to hear that. I hope you get the GSoC! Antoniu
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 06:23, Steven Bosscher wrote: > On Tue, Apr 5, 2011 at 1:39 PM, Bernd Schmidt wrote: >> On 04/05/2011 08:26 AM, Steven Bosscher wrote: >>> I don't understand, really, why it's such a big deal to revert a patch >>> quickly if it broke something. >> >> To answer this as well, firstly a proposal that comes with a request to >> revert the wrong patch discredits itself. > > Agreed. Note that in this particular case (and in most cases I can > remember) the commit that broke things was identified correctly. This > is what HJ's autotester is really good at. It's reasonably good at identifying the breakage, but I have certainly had cases where the autotester got it wrong as well. The auto-tester is definitely a help. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNm0HRAAoJEBRtltQi2kC77JcH/A7UcoXsS5BeIHLhMEHnodVk +Itu9BGuWVR2toD0NUWohIOXpKbfVhTl1tgV+SLYifglzJ0akA8rF9b5KgAe3DML SRePYgoVar2LOz7khDOhZbiQBL+3ubGxr+/9QxRypFR25TuvoWncVUJd0DTsoBQd XnjGcDWhw6kSGToDzIop3GXaEz+3LpvLzjYA0kMH4tVuAYqHMrCy+QDtI9WKS8p0 syVdvhMKAYWOpIizQikeUFO4zizZDCtxkFPBkfZNGemYXfnU/eaRmTdcfAEeWrzw H854+jCzIljL0syBj2u1oOagN8w695Xf3m4QjEr/FK6Kif/ilvC8G7uqutA+Q9k= =aZ2P -END PGP SIGNATURE-
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, Apr 5, 2011 at 9:22 AM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/05/11 06:23, Steven Bosscher wrote: >> On Tue, Apr 5, 2011 at 1:39 PM, Bernd Schmidt >> wrote: >>> On 04/05/2011 08:26 AM, Steven Bosscher wrote: I don't understand, really, why it's such a big deal to revert a patch quickly if it broke something. >>> >>> To answer this as well, firstly a proposal that comes with a request to >>> revert the wrong patch discredits itself. >> >> Agreed. Note that in this particular case (and in most cases I can >> remember) the commit that broke things was identified correctly. This >> is what HJ's autotester is really good at. > It's reasonably good at identifying the breakage, but I have certainly > had cases where the autotester got it wrong as well. > I think what Steven proposed is for bootstrap failures on more than one primary platforms. I don't see any harm to unblock GCC development while offender can work on it off-trunk BTW, I would recommend git mirror to work on such bugs off-trunk It is so convenient. -- H.J.
Re: VIRTUAL_STACK_VARS_REGNUM vs VIRTUAL_STACK_DYNAMIC_REGNUM
Hari Sandanagobalane writes: > Can anyone familiar with backend explain to me when we use > VIRTUAL_STACK_VARS_REGNUM (or) VIRTUAL_STACK_DYNAMIC_REGNUM in gcc? > Rather, when does the compiler decide to allocate a variable to > stack_vars region and when to stack_dynamic? See calls to allocate_dynamic_stack_space. It's used for, e.g., allocate, variable sized local arrays, etc. > I encountered some trouble with virtual-stack-vars. Since it gets > translated to FRAME_POINTER_REGNUM and we don't actually have a > dedicated frame pointer register in picochip, i got a compiler ICE. I > have set ELIMINABLE_REGS to eliminate FRAME_POINTER in preference to > STACK_POINTER, but it doesn't work in this case (presumably > because FRAME_POINTER is used in a memory reference and elimination > does not work well with memory) gcc can not always eliminate the frame pointer. A frame pointer is required for functions that allocate stack space dynamically. You don't need to have a dedicated frame pointer register, but you do need to have a register which can serve as the frame pointer in a function which requires a frame pointer. > In the attached C code, at expand it saves the result from each call > to getPort function to the virtual_stack_vars region and then copies > it from there into virtual_stack_dynamic region. Why can it not copy > straight into virtual_stack_dynamic region? In the example, if i were > to write to the "int32_elements" instead of cmplx_elements, it does > work fine by writing it directly into virtual_stack_dynamic region. > > I have attached the compiler dumps from expand, sched and ira for reference. > > I tried this on GCC 4.6.0 release compiler. The port has had some > local changes for vector support, which i will submit into mainline > after a while. It looks like the port is requiring the local variables to have a specific alignment, but that the stack pointer is not guaranteed to be aligned. If you do expect the stack pointer to be aligned, make sure you express that in STACK_BOUNDARY and PREFERRED_STACK_BOUNDARY. If you do not expect the stack pointer to be aligned, but the local variables have to be aligned, then I don't see what else gcc can do. Ian
RE: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
> -Original Message- > From: Steven Bosscher [mailto:stevenb@gmail.com] > Sent: Tuesday, April 05, 2011 6:24 AM > To: Bernd Schmidt > Cc: Ian Lance Taylor; GCC Mailing List; David Edelsohn; Benjamin Kosnik; > H.J. Lu > Subject: Re: To Steering Committee: RFC for patch revert policy (PR48403, > bootstrap broken on many targets) > > It's just that the pace of > checkins/checkouts in GCC is so fast these days, that the 48hr policy > seems like a dinosaur to me :-) Using that logic then means that no human can, or should, keep pace with the amount of change happening and that, in addition to automatic testing of every patch, there should be automatic rollback of patches that break bootstrap of primary targets. Why put humans in the middle of this process.
[RFC] gfortran's coarray (library version): configure/build and the testsuite
Hello,
Fortran 2008 has a build in parallelization (Coarray [Fortran], CAF)
[1]. gfortran did the first steps to a communication-library version
[2]. The library will be based MPI.
There are two issues I like to discuss in this email:
a) configuring and building
b) Test-suite support
Let's start with (b) which is more important for me. The current scheme
is that the user somehow compiles the communication library (libcaf) [2]
and then builds and links doing something like:
mpif90 -fcoarray=lib fortran.f90 -lcaf_mpi
or alternatively
gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
-I/usr/lib64/mpi/gcc/openmpi/include -L/usr/lib64/mpi/gcc/openmpi/lib64
-lmpi
with some -I, -L -l are added. (Cf. "mpif90 -show" of
some MPI implementations.) The resulting program is then run using, e.g.,
mpiexec -n 3 ./a.out
Alternatively, it could be just "-lcaf_single" which is run like normal
("./a.out").
Thus, one needs some means to add link and compile options - and a means
to add an (optional) run command. Those one would probably pass via
environment variables.
One would then either only run the tests if the environment variable is
set - or if "libcaf_single.a" is installed by default (cf. below), one
could default to linking that version if no environment variable is set.
Then "make check-gfortran" could then always run the CAF library checks
- otherwise, only conditionally.
What do you think? Do you have comments how this should be done? I also
wouldn't mind if someone could help as I am not really comfortable with
the test-suite setup nor do I know Lisp well.
Regarding (a): As mentioned above, one could consider compiling, linking
and installing "libcaf_single" by default. libgfortran/caf/single.c is a
simple stub library which essentially does nothing; the only purpose is
to be able to (re)link -fcoarray=lib compile program without recompiling
and for testing and debugging purpose (e.g. for the testsuite?). If one
wants to seriously use a serial program: -fcoarray=single produces much
faster code.
Additionally, there is libgfortran/caf/mpi.c which is an MPI
implementation in a very early stage. (Currently, MPI v2 is required;
however, the plan is to move to an MPI v1 implementation - maybe using
optionally also MPI v2.)
Thus, the first question is: Should one build and install single.c
(libcaf_single.a) by default? (Might also relate to (a), namely how the
test suite is handled.)
And the second question is: Should one be able to configure and build
mpi.c (libcaf_mpi.a) by some means? I think users interested in could
also do the procedure of [2] - or let their admin do it. (For Linux
distributions one would run into the problem that they typically offer
several MPI implementations, e.g. Open MPI and MPICH2, which couldn't be
handled that way.)
(In any case, only static libraries should be created; the libraries
could then be installed in $PREFIX/$lib/gcc/$target/$version/, where
already libgcc.a etc. are located.)
Tobias
[1] http://gcc.gnu.org/wiki/Coarray
[2] http://gcc.gnu.org/wiki/CoarrayLib
PS: At some point there will be also a shared-memory version - maybe for
GCC 4.8.
PPS: Tiny example program - to be compiled with -fcoarray=single -- or
with -fcoarray=lib as described in [2]:
program coarray_example
print *, 'This is image ', this_image(), ' of ', num_images()
end program coarray_example
[Xtensa] Patch--Update email address
I have committed the attached patch which updates my email address in the MAINTAINERS file. Sterling 2011-04-05 Sterling Augustine * MAINTAINERS: Update my email address as Xtensa maintainer. gcc-maintainer.patch Description: Binary data
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
Diego Novillo writes: > On Tue, Apr 5, 2011 at 00:51, Ian Lance Taylor wrote: > >> I agree. >> >> At the summit in October there was a discussion about this. I was on >> the side of fast rollback for new failures. Would anybody care to >> present the opposite view with regard to a patch like this? Can we >> agree on fast rollback for bootstrap failures on x86/x86_64 GNU/Linux >> systems? > > I completely support this approach. I would agree with faster rollback *if* the person doing the revert *first* proved that the patch they're reverting actually caused the bug, and not just exposed some pre-existing bug elsewhere. And got someone else to agree that reverting is the right thing to do. As a maintainer of non-primary targets, I see lots of perfectly normal patches that allow a bug elsewhere to exert itself, and I think that's a completely different situation than a patch which introduces a bug.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On 04/05/2011 02:16 PM, DJ Delorie wrote: Diego Novillo writes: On Tue, Apr 5, 2011 at 00:51, Ian Lance Taylor wrote: I agree. At the summit in October there was a discussion about this. I was on the side of fast rollback for new failures. Would anybody care to present the opposite view with regard to a patch like this? Can we agree on fast rollback for bootstrap failures on x86/x86_64 GNU/Linux systems? I completely support this approach. I would agree with faster rollback *if* the person doing the revert *first* proved that the patch they're reverting actually caused the bug, and not just exposed some pre-existing bug elsewhere. And got someone else to agree that reverting is the right thing to do. What type of *proof* would you accept? o Bisecting the commit history until it doesn't fail any more? o A formal mathematical proof of some type? As a maintainer of non-primary targets, I see lots of perfectly normal patches that allow a bug elsewhere to exert itself, and I think that's a completely different situation than a patch which introduces a bug. You seem to suggest that there is a simple and reliable way to differentiate uncovering of latent bugs and introduction of new bugs. I don't think there is so the only practical thing to do is apply any rule we have to all build breakers. David Daney
gcc-4.4-20110405 is now available
Snapshot gcc-4.4-20110405 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110405/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 172006 You'll find: gcc-4.4-20110405.tar.bz2 Complete GCC (includes all of below) MD5=4e6f0093622509469a117b593055562c SHA1=c200fc4baa1e8e485226b115ff544074b8638a11 gcc-core-4.4-20110405.tar.bz2C front end and core compiler MD5=72951e253ebb35615a373563d2e0658c SHA1=5e7917773d83fb7a296bf654609311b7755e6afd gcc-ada-4.4-20110405.tar.bz2 Ada front end and runtime MD5=be3a288967e62a571144b0a91599d8de SHA1=41123445ec426c5e0c65d0e85cfa9a6f03386574 gcc-fortran-4.4-20110405.tar.bz2 Fortran front end and runtime MD5=c8cf77452db271d44a33221dbc25bf02 SHA1=e4a654e9431e6344d9525aac7d1bb9b60cf39f37 gcc-g++-4.4-20110405.tar.bz2 C++ front end and runtime MD5=bca9e00ea3ef79d5cbc967f76d5a3c0b SHA1=0825368107967c87a121cf4ab48e6ac71ac38029 gcc-go-4.4-20110405.tar.bz2 Go front end and runtime MD5=67d2e2e00db48741795d0c494b5f8609 SHA1=f51a822b18a54288d0ae9aaafff6921ab6ca1ba7 gcc-java-4.4-20110405.tar.bz2Java front end and runtime MD5=3623bd1c15bc06b72a826831f71e19e0 SHA1=2c31e42f7af491dbf5dc9958c017d08db317782b gcc-objc-4.4-20110405.tar.bz2Objective-C front end and runtime MD5=d3c199c4a2e946701c8cf689aad1cf0a SHA1=13f55cf6991ea6579e7bcb1597e8f5480e2da717 gcc-testsuite-4.4-20110405.tar.bz2 The GCC testsuite MD5=f7e59e2957e72b8f4e20a6a6b7700521 SHA1=a282a182eacf02f2098ae7dad6eca17e851c79a8 Diffs from 4.4-20110329 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
> What type of *proof* would you accept? > > o Bisecting the commit history until it doesn't fail any more? That isn't even *evidence* that the patch caused the bug, much less proof. It only shows that the patch resulted in some bug happening, but that bug might have been latent. If this is really what we want for an auto-revert trigger, then what we need is a commit hook that builds every patch and rejects any that cause problems. I suspect we really don't want that though. > o A formal mathematical proof of some type? "I think the bug is caused by X,Y,Z... anyone agree?" "Yeah, that looks right." If anyone thinks that you can mathematically prove *anything* about software, they're on crack. I see "proof" as "shown evidence that they understand what really happened, and others agree." I absolutely do NOT want anyone, other than global maintainers, to have carte blanc to stomp on some other developer's toes without a fantastic reason and reasonable surety that they're doing the right thing. > You seem to suggest that there is a simple and reliable way to > differentiate uncovering of latent bugs and introduction of new bugs. I > don't think there is so the only practical thing to do is apply any rule > we have to all build breakers. I don't agree that blindly applying any "you may revert" rule, without knowing what's going on, is a good idea. We *already* have a rule that applies to all build breakers - the 48 hour rule. We're talking about a new rule that shortens this time. If it's truly impossible to figure out why a bug suddenly starts happening, the old 48 hour rule is sufficient, and global maintainers can always override any policy anyway. Anything more drastic than that *should* require some barriers to "just doing it".
Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite
On Tue, 5 Apr 2011, Tobias Burnus wrote: > Thus, one needs some means to add link and compile options - and a means to > add an (optional) run command. Those one would probably pass via environment > variables. In general site.exp is a better way to pass this sort of information to the testsuite. (You might then make the makefile rules for site.exp only set the relevant variables there if the appropriate environment variables are set, but the testsuites themselves would use the information from site.exp.) -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite
Hello Tobias,
Here there are few comments from my college Lisandro Dalcin,
an external developer of PETSc, e.g. see
http://www.mcs.anl.gov/petsc/petsc-as/miscellaneous/index.html
Regards,
Jorge.
- Mensaje original -
> De: "Tobias Burnus"
> Para: "gfortran" , "GCC Mailing List" ,
> "Ralf Wildenhues"
> , "Rainer Orth"
> Enviados: Martes, 5 de Abril 2011 17:01:03
> Asunto: [RFC] gfortran's coarray (library version): configure/build and the
> testsuite
>
>
> Fortran 2008 has a build in parallelization (Coarray [Fortran], CAF)
> [1]. gfortran did the first steps to a communication-library version
> [2]. The library will be based MPI.
>
> There are two issues I like to discuss in this email:
>
> a) configuring and building
> b) Test-suite support
>
> Let's start with (b) which is more important for me.
>
> The current scheme is that the user somehow compiles
> the communication library (libcaf) [2] and then builds
> and links doing something like:
>
> mpif90 -fcoarray=lib fortran.f90 -lcaf_mpi
>
> or alternatively
>
> gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
> -I/usr/lib64/mpi/gcc/openmpi/include
> -L/usr/lib64/mpi/gcc/openmpi/lib64
> -lmpi
>
> with some -I, -L -l are added.
> (Cf. "mpif90 -show" of some MPI implementations.)
>
> The resulting program is then run using, e.g.,
>
> mpiexec -n 3 ./a.out
>
> Alternatively, it could be just "-lcaf_single"
> which is run like normal ("./a.out").
>
> Thus, one needs some means to add link and compile
> options - and a means to add an (optional) run
> command.
>
> Those one would probably pass via environment variables.
>
> One would then either only run the tests if the
> environment variable is set - or if "libcaf_single.a" is
> installed by default (cf. below), one could default to
> linking that version if no environment variable is
> set.
>
> Then "make check-gfortran" could then always run the
> CAF library checks - otherwise, only conditionally.
>
> What do you think?
>
> Do you have comments how this should be done?
>
> I also wouldn't mind if someone could help as I am not
> really comfortable with the test-suite setup nor do I
> know Lisp well.
>
> Regarding (a): As mentioned above, one could consider
> compiling, linking and installing "libcaf_single" by
> default. libgfortran/caf/single.c is a simple stub
> library which essentially does nothing; the only purpose
> is to be able to (re)link -fcoarray=lib compile program
> without recompiling and for testing and debugging
> purpose (e.g. for the testsuite?).
>
> If one wants to seriously use a serial program:
> -fcoarray=single produces much faster code.
COMMENT: Installing libcaf_single is definitely a good idea.
> Additionally, there is libgfortran/caf/mpi.c which is
> an MPI implementation in a very early stage.
COMMENT: BTW, I think you need to review your
implementation of _gfortran_caf_finalize() ...
You should check with MPI_Finalized(), and
call MPI_Finalize() ONLY if _gfortran_caf_init()
actually called MPI_Init(). These are just good-
citizen rules for libraries using MPI.
> (Currently, MPI v2 is required; however, the plan is to
> move to an MPI v1 implementation - maybe using
> optionally also MPI v2.)
>
> Thus, the first question is:
>
> Should one build and install single.c (libcaf_single.a)
> by default?
COMMENT: I think so.
> (Might also relate to (a), namely how the test suite
> is handled.)
>
> And the second question is:
>
> Should one be able to configure and build mpi.c
> (libcaf_mpi.a) by some means?
>
> I think users interested in could also do the procedure
> of [2] - or let their admin do it.
>
> (For Linux distributions one would run into the problem
> that they typically offer several MPI implementations,
> e.g. Open MPI and MPICH2, which couldn't be handled
> that way.)
COMMENT: But they have mechanisms in place to let sysadmins
(by using altenatives) or regular users (by using environment
modules) to switch MPI implementations.
Linux distros would ship two versions of the libcaf_mpi.a
and the alternatives/modules will let you make a choice.
> (In any case, only static libraries should be created;
> the libraries could then be installed
> in $PREFIX/$lib/gcc/$target/$version/, where
> already libgcc.a etc. are located.)
COMMENT: well, using shared libraries would certainly help
users to switch the underlying MPI implementation at runtime.
This is an feature should be considered.
> [1] http://gcc.gnu.org/wiki/Coarray
> [2] http://gcc.gnu.org/wiki/CoarrayLib
>
>
> PS: At some point there will be also a shared-memory version
> - maybe for GCC 4.8.
>
>
> PPS: Tiny example program - to be compiled
> with -fcoarray=single -- or
> with -fcoarray=lib as described in [2]:
>
> program coarray_example
> print *, 'This is image ', this_image(), ' of ', num_images()
> end program coarray_example
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colec
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/11 16:49, DJ Delorie wrote: >> What type of *proof* would you accept? >> >> o Bisecting the commit history until it doesn't fail any more? > > That isn't even *evidence* that the patch caused the bug, much less > proof. It only shows that the patch resulted in some bug happening, > but that bug might have been latent. Right. Often a bisect will catch the bug, but it's certainly not foolproof. > If this is really what we want for an auto-revert trigger, then what > we need is a commit hook that builds every patch and rejects any that > cause problems. I suspect we really don't want that though. People could certainly make an argument for this; if we had the infrastructure which included this as part of patch tracking & management, it'd be hard to argue against it. > > "I think the bug is caused by X,Y,Z... anyone agree?" "Yeah, that > looks right." Right. Though often once we get to the point of knowing that a bug is caused by X,Y,Z we have enough information to go ahead and resolve the issue, it's just a matter of going through the bootstrap and testing process to help avoid introducing new problems. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNm6YgAAoJEBRtltQi2kC79RkIAJrJJ9nVwe3wUAsMVsjTQq/B 7A2rDY7o1JZeo/f+51VF9ZAk8a6Uy+HzdNt0scJOwt56PT9ZghcFOcFYfB9hmth4 iOLOL1PoB6adZ1+76VsZq6BgZVQ7sXpUnyjQAZ99rtDMyyGPNpndTITFDCWbteMu YqY8NfYfn7hkuB7A26nNPkkw6sNRRMP+oUUsYnga1XQ+xBYZSNbflZzADAGWlAvR MTY/jBCxOzehnqI5Hus3k2kdjvlX0F6N2MYlFMPEsqJGJnkbIW14Y1mLWNPWSOmB vZ+7/SdelaMg55egg/RXUo9itSpOrpK79oqwNNKRJ5FR9hGYy5dFFE/h6A+Tb5k= =cYo3 -END PGP SIGNATURE-
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On Tue, 2011-04-05 at 09:44 -0400, Richard Kenner wrote: > > A reversion policy that's too trigger-happy can leave you unable to > > make forward progress on an important patch. At the very least you'd > > need to write in stone that a patch can be reinstalled if the > > reporter of the problem is unwilling to assist in debugging or > > testing candidate patches. > > Although I certainly agree that the tree shouldn't remain broken, I'm also > sympathetic to the need to be able to have an environment in which the > developer can debug the patch because it presumably didn't fail in their > environment if they commited it. The issue I see here is that people tend not to report what's needed: - base svn revision - configure line - CC, BOOT_CFLAGS and other common make/env variables - GCC version and triplet used to compile stage one I think the classic "patch tested on platform X" should mention the above information on patch submission email (with GCC testresult URL when available), and "bootstrap broken" PR too in the first message of the PR. (test_summary doesn't report the last two pieces.) C only trunk bootstrap is less than 10 minutes on gcc10 and gcc20 (1) thanks to AMD and Intel donations, but without the above information CPU power is of little use :). Sincerely, Laurent (1) http://gcc.gnu.org/wiki/CompileFarm
