gcc terms of use
Excuse me, unfortunately I didn't found anything about my questions. Tell me please next. When I build my software products via gcc can I use it with third party's proprietary software (not open source)? When I build my software products via gcc I must provide source code of my products in any case? Excuse me my English. It isn't my native language. Best regards. Vladimir.
Re: gcc terms of use
Hey, When I build my software products via gcc can I use it with third party's proprietary software (not open source)? Yes. When I build my software products via gcc I must provide source code of my products in any case? No. You don't need to publish _your_ source code in this case. There are some big (proprietary) software companies out there who use GCC. Generally, the open source thing relates to the sources of the compiler itself, but not to the sources which are built by GCC. Andi P.S. Please do not use gcc@gcc.gnu.org for such kind of questions. There's a specific mailing list gcc-h...@gcc.gnu.org which is the appropriate one.
[wiki] Added link to CGO 2011 GCC tutorial
Prof Uday Khedker presented a very nice tutorial on GCC development at this year's CGO: http://www.cse.iitb.ac.in/grc/index.php?page=gcc-tut I've added a link to the tutorial from the getting started wiki: http://gcc.gnu.org/wiki/GettingStarted Diego.
Announce: GNU MPFR 3.0.1 is released
GNU MPFR 3.0.1 ("boudin aux pommes", patch level 1) is now
available for download from the MPFR web site:
http://www.mpfr.org/mpfr-3.0.1/
from INRIAGForge:
https://gforge.inria.fr/projects/mpfr/
and from the GNU FTP site:
http://ftp.gnu.org/gnu/mpfr/
Thanks very much to those who sent us bug reports and/or tested
the release candidate.
The MD5's:
bfbecb2eacb6d48432ead5cfc3f7390a mpfr-3.0.1.tar.bz2
e9c191fc46a4f5741f8a0a11ab33b8bf mpfr-3.0.1.tar.gz
645882d9d179113a70af84d27086ed9f mpfr-3.0.1.tar.xz
035523ebf2e43dc0c233f02c04273a8a mpfr-3.0.1.zip
The SHA1's:
fbf402fc196724ae60ef01eb6ca8490b1ea4db69 mpfr-3.0.1.tar.bz2
caa0609934c0d2ffa29bd11bfa9c05fbade130eb mpfr-3.0.1.tar.gz
f9d540a89c6b3b5840dbe074e7bdcf9124e07ae0 mpfr-3.0.1.tar.xz
3b7548b0d315bf3872421c8b586391851c601cb4 mpfr-3.0.1.zip
The signatures:
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1.tar.xz.asc
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1.tar.gz.asc
http://www.mpfr.org/mpfr-3.0.1/mpfr-3.0.1.zip.asc
Changes from version 3.0.0 to version 3.0.1:
- Bug fixes (see or ChangeLog file).
Note: The mpfr_subnormalize implementation up to MPFR 3.0.0 did not change
the flags. In particular, it did not follow the generic rule concerning
the inexact flag (and no special behavior was specified). The case of the
underflow flag was more a lack of specification.
You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 3.0.1 web page.
Regards,
--
Vincent Lefèvre - Web:
DW_AT_GNU_odr_signature
Hi, I saw that dwarf2out.c (generate_type_signature) does not just calculate the complete type signature for use with DW_AT_signature, but also outputs a DW_AT_GNU_odr_signature. The comment says: /* First, compute a signature for just the type name (and its surrounding context, if any. This is stored in the type unit DIE for link-time ODR (one-definition rule) checking. */ I couldn't find where in the toolchain this link-time checking is done. Does anybody have any pointers? Thanks, Mark
IRA/reload make bulky code: why stack slots where GPR is fine?
With new versions of gcc from trunk (like last snapshot SVN 171894), I
observe very bad code from register allocator.
As a test case assume
bar.c:
int a (void);
int b (void)
{
return a()+1;
}
which, on avr, could be compiled as
b:
.L__stack_usage = 0
rcall a ; 6 *call_value_insn/2 [length = 1]
adiw r24,1 ; 13 *addhi3/2 [length = 1]
/* epilogue start */
ret ; 23 return [length = 1]
what actually happens is this:
b:
push r28 ; 27 *pushqi/1 [length = 1]
push r29 ; 28 *pushqi/1 [length = 1]
rcall . ; 32 *addhi3_sp_R_pc2[length = 1]
in r28,__SP_L__ ; 33 *movhi_sp/2 [length = 2]
in r29,__SP_H__
.L__stack_usage = 4
rcall a ; 6 *call_value_insn/2 [length = 1]
mov r18,r24 ; 25 *movhi/1[length = 2]
mov r19,r25
subi r18,lo8(-(1)) ; 8 *addhi3/4 [length = 2]
sbci r19,hi8(-(1))
std Y+2,r19 ; 26 *movhi/3[length = 2]
std Y+1,r18
ldd r24,Y+1 ; 22 *movqi/4[length = 1]
ldd r25,Y+2 ; 23 *movqi/4[length = 1]
/* epilogue start */
pop __tmp_reg__ ; 38 *addhi3_sp_R_pc2[length = 2]
pop __tmp_reg__
pop r29 ; 39 popqi [length = 1]
pop r28 ; 40 popqi [length = 1]
ret ; 41 return_from_epilogue[length = 1]
.size b, .-b
Just before .ira, in pass .asmcons, RTL looks like this:
(call_insn 6 2 7 2 (parallel [
(set (reg:HI 24 r24)
(call (mem:HI (symbol_ref:HI ("a") [flags 0x41]
) [0 a S2 A8])
(const_int 0 [0])))
(use (const_int 0 [0]))
]) bar.c:6 123 {*call_value_insn}
(nil)
(nil))
(insn 8 7 22 2 (set (reg:HI 46)
(plus:HI (reg:HI 24 r24)
(const_int 1 [0x1]))) bar.c:6 22 {*addhi3}
(nil))
(insn 22 8 23 2 (set (reg:QI 24 r24)
(subreg:QI (reg:HI 46) 0)) bar.c:7 4 {*movqi}
(nil))
(insn 23 22 16 2 (set (reg:QI 25 r25 [+1 ])
(subreg:QI (reg:HI 46) 1)) bar.c:7 4 {*movqi}
(expr_list:REG_DEAD (reg:HI 46)
(nil)))
(insn 16 23 0 2 (use (reg/i:HI 24 r24)) bar.c:7 -1
(nil))
reg:HI 46 gets allocated to a stack slot, which eventually causes the
bulky code. There are plenty of free registers. Why isn't anyone of
them used instead? Seems the problems are related to SUBREGs which are
not handled properly and always end up in mem.
(call_insn 6 2 7 2 (parallel [
(set (reg:HI 24 r24)
(call (mem:HI (symbol_ref:HI ("a") [flags 0x41]
) [0 a S2 A8])
(const_int 0 [0])))
(use (const_int 0 [0]))
]) bar.c:6 123 {*call_value_insn}
(nil)
(nil))
(insn 25 7 8 2 (set (reg:HI 18 r18)
(reg:HI 24 r24)) bar.c:6 10 {*movhi}
(nil))
(insn 8 25 26 2 (set (reg:HI 18 r18)
(plus:HI (reg:HI 18 r18)
(const_int 1 [0x1]))) bar.c:6 22 {*addhi3}
(nil))
(insn 26 8 22 2 (set (mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [3 %sfp+1 S2 A8])
(reg:HI 18 r18)) bar.c:6 10 {*movhi}
(nil))
(insn 22 26 23 2 (set (reg:QI 24 r24)
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [3 %sfp+1 S1 A8])) bar.c:7 4 {*movqi}
(nil))
(insn 23 22 16 2 (set (reg:QI 25 r25 [+1 ])
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 2 [0x2])) [3 %sfp+2 S1 A8])) bar.c:7 4 {*movqi}
(nil))
(insn 16 23 24 2 (use (reg/i:HI 24 r24)) bar.c:7 -1
(nil))
The recent changed in IRA cause other sorts of trouble as
http://gcc.gnu.org/PR48435
Because the SUBREGs always end up in mem, register conatraints in
linline-asm can never be satisfied.
Johann
== command line
avr-gcc bar.c -da -S -Os -dp
== configuration
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=some-prefix --enable-languages=c,c++ --disable-libssp
--disable-libada --disable-nls --disable-shared
Thread model: single
gcc version 4.7.0 20110404 (experimental) (GCC)
constraints for push byte on word-aligned stack
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.
I have a machine description that includes these two defines:
(define_insn "*pushqi_pre_mod"
[(set (mem:QI (pre_modify:HI (reg:HI 1)
(plus:HI (reg:HI 1) (const_int -2
(match_operand:QI 0 "general_operand" "rim"))]
""
"* return msp430_pushqi(insn, operands);"
[(set_attr "length" "2")])
(define_insn "*pushqi"
[(set (match_operand:QI 1 "push_operand" "=<")
(match_operand:QI 0 "general_operand" "rim"))]
""
"* return msp430_pushqi(insn, operands);"
[(set_attr "length" "2")])
I'd hoped to clean this up by removing the apparently redundant first
definition.
I have a test program which normally works fine, but if I comment out the
first define produces:
movqi.c: In function ‘pushqi_r’:
movqi.c:33:1: error: unable to generate reloads for:
(insn 6 3 7 2 movqi.c:33 (set (mem/i:QI (pre_modify:HI (reg/f:HI 1 r1)
(plus:HI (reg/f:HI 1 r1)
(const_int -2 [0xfffe]))) [0 S1 A8])
(reg:QI 15 r15 [ p ])) 13 {*pushqi} (expr_list:REG_DEAD
(reg:QI 15 r15 [ p ])
(nil)))
movqi.c:33:1: internal compiler error: in find_reloads, at reload.c:3821
Instrumentation shows that push_operand succeeds, but the '<' constraint
fails, as the mem operand with pre_modify does not pass that test (nor does
it pass 'g' or 'm'; only 'X').
I've discovered HAVE_PRE_MODIFY_DISP which, based on its one-sentence
description, appears to be relevant as I'm changing the stack pointer by 2
though the operand size is 1. But it seems to have no effect, nor does
HAVE_PRE_MODIFY_REG.
Is there a better alternative to make this work than either leaving the
extra instruction in, or replacing the "=<" constraint with "=X"? Does the
latter have consequences that I should expect to regret?
Peter
Re: constraints for push byte on word-aligned stack
On Apr 4, 2011, at 12:04 PM, Peter Bigot wrote: > 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. FWIW, you might look at the pdp11 target support, since what you describe is done by pdp11 also. It seems to do the necessary stuff in its definition of TARGET_LEGITIMATE_ADDRESS_P. paul
Re: IRA/reload make bulky code: why stack slots where GPR is fine?
2011/4/4 Georg-Johann Lay : > > avr-gcc bar.c -da -S -Os -dp > > == configuration > > Target: avr > Configured with: ../../gcc.gnu.org/trunk/configure --target=avr > --prefix=some-prefix --enable-languages=c,c++ --disable-libssp > --disable-libada --disable-nls --disable-shared > Thread model: single > gcc version 4.7.0 20110404 (experimental) (GCC) GCC 4.6 produces right code. b: /* prologue: function */ /* frame size = 0 */ /* stack size = 0 */ .L__stack_usage = 0 rcall a adiw r24,1 /* epilogue start */ ret Denis.
Re: Give me advice on GSoC OpenMP
On Sun, Apr 03, 2011 at 08:10:25PM +0200, Jakub Jelinek wrote:
> On Sun, Apr 03, 2011 at 07:27:12PM +0900, Sho Nakatani wrote:
> > Then, I'll compare the trees created by gcc and icc, and point out
> > that the implementation of OpenMP Task uses Lazy Task Creation while
> > gcc does not.
>
> Depends on what you mean by lazy task creation, gcc schedules
> tasks lazily if they aren't if (0), some data structure if created
> for them when encountering #pragma omp task directive, but I guess
> any implementation will do something like that.
>
> What your testcase shows is not whether tasks are created lazily or not, but
> how good/poor #pragma omp taskwait implementation is. And, for your testcase
> libgomp/task.c (GOMP_taskwait) definitely could be improved. Currently it
> only
> tries to schedule in children that will be awaited by the current tasks and if
> there are no such children, goes to sleep, waiting for them to complete.
> Scheduling in random unrelated tasks is problematic, because the unrelated
> task might take too long to complete and delay the taskwait for way too long
> (note, gcc doesn't have untied tasks, all tasks are tied once they are
> scheduled
> onto some particular tasks - setcontext/swapcontext is quite fragile thing to
> do).
> But it is true it could very well schedule tasks that are taskwaited by tasks
> taskwaited by current task, and transitively further. Plus, be able to
> temporarily
> awake such a sleeping thread if there are tasks it can transitively taskwait
> for, as if those don't complete, the current taskwait won't return.
Just FYI, I've tried to implement something like that as a quick hack,
but it unfortunately slowed things down, at least on the attached fib testcase
with arguments 40 25. Guess partly the problem is that after a task waiting
in taskwait_sem is awaken it now needs to take task_lock lock to unqueue itself
from the new in_taskwait_list, and partly because the search for grand-grand
children
etc. is more expensive, the FIFO isn't a good data structure for that.
Jakub
--- libgomp/team.c.jj 2011-04-04 18:14:58.0 +0200
+++ libgomp/team.c 2011-04-04 20:00:45.0 +0200
@@ -166,6 +166,7 @@ gomp_new_team (unsigned nthreads)
gomp_mutex_init (&team->task_lock);
team->task_queue = NULL;
+ team->in_taskwait_list = NULL;
team->task_count = 0;
team->task_running_count = 0;
--- libgomp/libgomp.h.jj2011-04-04 18:19:46.0 +0200
+++ libgomp/libgomp.h 2011-04-04 20:00:45.0 +0200
@@ -311,6 +311,7 @@ struct gomp_team
gomp_mutex_t task_lock;
struct gomp_task *task_queue;
+ struct gomp_task *in_taskwait_list;
int task_count;
int task_running_count;
--- libgomp/task.c.jj 2009-04-14 16:33:07.0 +0200
+++ libgomp/task.c 2011-04-04 20:02:18.0 +0200
@@ -176,6 +176,26 @@ GOMP_task (void (*fn) (void *), void *da
gomp_team_barrier_set_task_pending (&team->barrier);
do_wake = team->task_running_count + !parent->in_tied_task
< team->nthreads;
+ if (!do_wake && team->in_taskwait_list)
+ {
+ struct gomp_task *t = team->in_taskwait_list;
+ do
+ {
+ struct gomp_task *p = parent;
+ int i;
+
+ for (i = 0; i < 10 && p; i++, p = p->parent)
+ if (p == t || p->kind == GOMP_TASK_IMPLICIT)
+ break;
+ if (p == t)
+ {
+ gomp_sem_post (&t->taskwait_sem);
+ break;
+ }
+ t = t->next_queue;
+ }
+ while (t != team->in_taskwait_list);
+ }
gomp_mutex_unlock (&team->task_lock);
if (do_wake)
gomp_team_barrier_wake (&team->barrier, 1);
@@ -301,10 +321,35 @@ GOMP_taskwait (void)
}
return;
}
- if (task->children->kind == GOMP_TASK_WAITING)
+ child_task = task->children;
+ if (child_task->kind != GOMP_TASK_WAITING && team->task_queue)
+ {
+ /* Try harder, look for grandchildren etc. */
+ for (child_task = team->task_queue;;
+ child_task = child_task->next_queue)
+ {
+ if (child_task->kind == GOMP_TASK_WAITING)
+ {
+ struct gomp_task *p = child_task->parent;
+ int i;
+
+ for (i = 0; i < 10 && p; i++, p = p->parent)
+ if (p == task || p->kind == GOMP_TASK_IMPLICIT)
+ break;
+ if (p == task)
+ break;
+ }
+ if (child_task->next_queue == team->task_queue)
+ {
+ child_task = task->children;
+ break;
+ }
+ }
+ }
+ if (child_task->kind == GOMP_TASK_WAITING)
{
- child_task = task->children;
- task->children = child_task->next_child;
+ if (child_task->parent->children == chil
Macera Seni Bekliyor
sfegwergregvrgevev erfvrefv vreftrvrvrvrd
[RFC] Creating builtin functions on demand
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? 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. 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. -- 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: Second GCC 4.6.0 release candidate is now available
On Sat, Mar 26, 2011 at 4:16 AM, Ramana Radhakrishnan wrote: > Hi Michael, > > Thanks for running these. I spent some time this morning looking > through the results, they largely look ok though I don't have much > perspective on the > the objc/ obj-c++ failures. > > These failures here > > For v7-a , A9 and Neon - these failures below: > >> Running target unix >> FAIL: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer (test >> for excess errors) >> UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer >> compilation failed to produce executable >> FAIL: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer >> -funroll-loops (test for excess errors) >> UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer >> -funroll-loops compilation failed to produce executable >> FAIL: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer >> -funroll-all-loops -finline-functions (test for excess errors) >> UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer >> -funroll-all-loops -finline-functions compilation failed to produce >> executable >> FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (test for excess errors) >> UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -g compilation failed >> to produce executable >> FAIL: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer (test for >> excess errors) >> UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer >> compilation failed to produce executable >> FAIL: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer -funroll-loops >> (test for excess errors) >> UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer >> -funroll-loops compilation failed to produce executable >> FAIL: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer >> -funroll-all-loops -finline-functions (test for excess errors) >> UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer >> -funroll-all-loops -finline-functions compilation failed to produce >> executable >> FAIL: gfortran.dg/func_assign_3.f90 -O3 -g (test for excess errors) >> UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -g compilation failed to >> produce executable > are caused by a broken assembler. All these tests appear to pass > fine in a cross environment on my machine. I've updated to binutils 2.21.51 which should fix the fault. I'm re-running the Cortex-A9 build against the 4.6.0 release now. > From v5t. > >> FAIL: gcc.dg/c90-intconst-1.c (internal compiler error) >> FAIL: gcc.dg/c90-intconst-1.c (test for excess errors) I re-ran this against the 4.6.0 release and these fails went away. Good. http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00319.html -- Michael
Internal compiler error in targhooks.c: default_secondary_reload (ARM/Thumb)
I'm getting an internal compiler error on the following test program:
void func(int a, int b, int c, int d, int e, int f, int g, short int h)
{
assert(a < 100);
assert(b < 100);
assert(c < 100);
assert(d < 100);
assert(e < 100);
assert(f < 100);
assert(g < 100);
assert((-1000 < h) && (h < 0));
}
Command line and output:
$ arm-none-eabi-gcc -mthumb -O2 -c -o test.o test.c
test.c: In function 'func':
test.c:11:1: internal compiler error: in default_secondary_reload, at
targhooks.c:769
Please submit a full bug report,
with preprocessed source if appropriate.
See
Re: Internal compiler error in targhooks.c: default_secondary_reload (ARM/Thumb)
On 04/04/2011 02:34 PM, Matt Fischer wrote:
I'm getting an internal compiler error on the following test program:
void func(int a, int b, int c, int d, int e, int f, int g, short int h)
{
assert(a< 100);
assert(b< 100);
assert(c< 100);
assert(d< 100);
assert(e< 100);
assert(f< 100);
assert(g< 100);
assert((-1000< h)&& (h< 0));
}
Command line and output:
$ arm-none-eabi-gcc -mthumb -O2 -c -o test.o test.c
test.c: In function 'func':
test.c:11:1: internal compiler error: in default_secondary_reload, at
targhooks.c:769
Please submit a full bug report,
with preprocessed source if appropriate.
See
To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
Hello, Revisions r171843, and r171845 broke bootstrap on many platforms, see PR48403. The commit of r171942 was supposed to fix this problem, but there are multiple reports that the problem is _not_ fixed for some configurations. This means that bootstrap has now been broken for three days on x86_64 and i686 targets, and a few others. I would actually been in favor of reverting these commits _now_. This is what has happened most of the recent times when bootstrap was broken by a patch. But GCC policy is to allow for 48 hours before reverting a patch, if "two people with write privileges to the affected area of the compiler determine that the best course of action is to revert the patch", whatever that means exactly. And even then, reverting is not allowed unless "the original poster or any other party [indicates] that a fix will be forthcoming in the very near future". In the PR audit trail, I've proposed to revert the patch, and HJ and Benjamin are also in favor of that. In Benjamin's works: Bootstrap has been broken for much too long, on all the common devel arches. Since we have write privileges, I consider the 48hr clock running... I would like to see the policy changed: Reverting patches should be done much faster than 48 hours after everyone is fed up with waiting :-) In these times of high network bandwidth, automated testers, and bootstrap times that make it possible to bisect to revisions that introduced a regression, 48+ hours is simply too long. Most of the time this happens courtesy of the developer who introduced this bug (see Vlad's recent IRA patch), but not in this case for whatever reason. 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. Thoughts? Ciao! Steven
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
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. -- H.J.
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
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? Ian
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On 04/04/2011 11:58 PM, Steven Bosscher wrote: > In the PR audit trail, I've proposed to revert the patch, and HJ and > Benjamin are also in favor of that. In Benjamin's works: Bootstrap has > been broken for much too long, on all the common devel arches. Which is not actually true, see the second-to-last message in that bug: "But x86/Linux, x86-64/Linux, x86-64/Darwin, x86/Solaris and SPARC/Solaris now bootstrap fine for me so there is some progress." What's still broken is --disable-checking bootstrap on i686-linux. This reproduces for me with both with a tree checked out at revision 171823, which is the one before my checkins, and a current tree with my patches reverted. There's a tendency for people to pile on an existing bugzilla report rather than properly investigate what's actually causing their problems. What's left are failures on mips64-linux and ia64, which I'm investigating now. I don't think anyone has done a proper analysis for what caused them either, although I guess my prune_ready_list patch is a major suspect. Clearly this is unfortunate, but I don't think these two are common devel arches either, as claimed by Steven. Bernd
Re: DW_AT_GNU_odr_signature
> I saw that dwarf2out.c (generate_type_signature) does not just calculate > the complete type signature for use with DW_AT_signature, but also > outputs a DW_AT_GNU_odr_signature. The comment says: > > /* First, compute a signature for just the type name (and its > surrounding context, if any. This is stored in the type unit DIE > for link-time ODR (one-definition rule) checking. */ > > I couldn't find where in the toolchain this link-time checking is done. > Does anybody have any pointers? It's not yet implemented. I plan to implement this checking in gold (as a supplement to the existing --detect-odr-violations flag, which is based on line number table information) at some point, but it's a low priority. -cary
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
On 04/05/2011 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? 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. A while ago ARM was broken for what seemed like a long time; didn't stop me from testing ARM patches. 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. Bernd
cc
cc Try something new http://bit.ly/fJFCOJ i defiantly received benefits as soon as i began doing it its my pleasure to be able to share it success with you seriously everyday used to be the same and now i can't wait to see whats next you'll truly have all the time in the world to expand your horizons
Re: Give me advice on GSoC OpenMP
Hi. Sorry for being late. > Depends on what you mean by lazy task creation, gcc schedules > tasks lazily if they aren't if (0), some data structure if created > for them when encountering #pragma omp task directive, but I guess > any implementation will do something like that. I mean the following implementation by Lazy Task Generation: - 1 CPU core has 1 worker - 1 worker has 1 deque (LIFO) - 1 deque has some tasks - What worker does are: - Execute tasks from the head of deque - Steel a task from the tail of deque in another core - When task A encounters "#pragma omp task" derective, worker creates a task and immediately execute it. Worker pushes A to the head of deque. (Here occurs context switch) This is important point because A can move to other deques. (*) - Steel a task from a deque in another core when the deque on the core is empty My associate sinior has already made a library which realizes this scheduling algorithm above. (It is called `MassiveThreads' but the paper related to its work is written in Japanese.) MassiveThreads has proved this algorithm makes things like OpenMP Task speedy. Taking this implementation, - Nested `task' derectives can be processed naturally - Given that task A is a member of deque D and task A1 is created in D when task A encounters `task' derective. (See (*)) A1 runs soon after it is created. So although A will execute some functions which takes too long to finish, this work can be done after A is stolen into another deque than D Anyway, I'd like to read some materials refered to when current libgomp `task' is implemented (to read the code smoothly). Do you know any of that? > What your testcase shows is not whether tasks are created lazily or not, but > how good/poor #pragma omp taskwait implementation is. And, for your testcase > libgomp/task.c (GOMP_taskwait) definitely could be improved. Currently it > only > tries to schedule in children that will be awaited by the current tasks and if > there are no such children, goes to sleep, waiting for them to complete. > Scheduling in random unrelated tasks is problematic, because the unrelated > task might take too long to complete and delay the taskwait for way too long > (note, gcc doesn't have untied tasks, all tasks are tied once they are > scheduled > onto some particular tasks - setcontext/swapcontext is quite fragile thing to > do). > But it is true it could very well schedule tasks that are taskwaited by tasks > taskwaited by current task, and transitively further. Plus, be able to > temporarily > awake such a sleeping thread if there are tasks it can transitively taskwait > for, as if those don't complete, the current taskwait won't return. > > Jakub -- 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/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. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmn6tAAoJEBRtltQi2kC79OsIAJNEWxRmlCwrumS7cUkCQlDE J8vq/KOj38O1pzSEpqjGWMGHlykCw5s9HnxZl8aX7XRtnp4CqpM7/dG2Gw69WOHn 6HGgu+f7e8XegsiSDxZXT3H5c+obGVR6LaZFOY3I35UuMfp08FPH7F3of5Lgm7dA UHH63gBvZ+bYl7DKQ8q1FY8He8qBKpwvYAzFKiK2oUGxye1bIaXh7FXnWc7QVKyN w7MTsnIcG/Beaqv5U5SxNs2SK6zDsJuQbdWDR0C0oFDFQHAyC7h73boHdjnkuyHb g0w08QuDM2TWy6zMaz4rsBi39D6Q0+efZTPjdh0sDqvVaoTrcN/voIlW29d7MK0= =kcu3 -END PGP SIGNATURE-
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 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. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmoO5AAoJEBRtltQi2kC7a0AIAIBRNbIvHFpgjPDbrgfa9tWt ysBLwj+h5ThnihHHOs/mR6JUvhH2VIP2FOVQLvW5qWGdlCLPFS38wg+mxFuwjhkk v46BKj6RZ+jsANN3XmcQBQDkUPyWK2WRkCLrDxkVfWMLMqiPuHuU+kSwg6/wG0y1 cCWYepDdjigfKmvfkl/U/i4szJM9ERwn9xp09O1cHx9oHNl1yGYGMRrerKt1hWUc Gi1A0m8C7plqNjWUh2bWQdPLiBheNllbrhw0+LQAeVLmPb/e6Sq5MwL+iQDrF6Qh RRmZc5Cu4HmhBV/6ungbNn/sIO8ev1E7q8OL3xVjgcsxYOQYg31zOoZUjlZ7PQc= =Jz94 -END PGP SIGNATURE-
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
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. -- H.J.
Re: Give me advice on GSoC OpenMP
From: Jakub Jelinek Date: Mon, 4 Apr 2011 20:15:38 +0200 > On Sun, Apr 03, 2011 at 08:10:25PM +0200, Jakub Jelinek wrote: >> On Sun, Apr 03, 2011 at 07:27:12PM +0900, Sho Nakatani wrote: >> > Then, I'll compare the trees created by gcc and icc, and point out >> > that the implementation of OpenMP Task uses Lazy Task Creation while >> > gcc does not. >> >> Depends on what you mean by lazy task creation, gcc schedules >> tasks lazily if they aren't if (0), some data structure if created >> for them when encountering #pragma omp task directive, but I guess >> any implementation will do something like that. >> >> What your testcase shows is not whether tasks are created lazily or not, but >> how good/poor #pragma omp taskwait implementation is. And, for your testcase >> libgomp/task.c (GOMP_taskwait) definitely could be improved. Currently it >> only >> tries to schedule in children that will be awaited by the current tasks and >> if >> there are no such children, goes to sleep, waiting for them to complete. >> Scheduling in random unrelated tasks is problematic, because the unrelated >> task might take too long to complete and delay the taskwait for way too long >> (note, gcc doesn't have untied tasks, all tasks are tied once they are >> scheduled >> onto some particular tasks - setcontext/swapcontext is quite fragile thing >> to do). >> But it is true it could very well schedule tasks that are taskwaited by tasks >> taskwaited by current task, and transitively further. Plus, be able to >> temporarily >> awake such a sleeping thread if there are tasks it can transitively taskwait >> for, as if those don't complete, the current taskwait won't return. > > Just FYI, I've tried to implement something like that as a quick hack, > but it unfortunately slowed things down, at least on the attached fib testcase > with arguments 40 25. Guess partly the problem is that after a task waiting > in taskwait_sem is awaken it now needs to take task_lock lock to unqueue > itself > from the new in_taskwait_list, and partly because the search for grand-grand > children > etc. is more expensive, the FIFO isn't a good data structure for that. > > Jakub Thanks a lot for your work. I'll read through it to help understand the concept of current GOMP implementation. I posted a new email a few hours ago in which I wrote what is the concept of `Lazy Task Creation' is. Do you have any comment on that? My current concern is that in order to implement Lazy Task Creation, a task should pause and resume its execution. So it's neccessary to implement context switch, which `MassiveThreads' does. Is it OK to write small assembly codes for each CPU architecture in libgomp? (I guess it is theoretically possible if some changes are added in Makefile) -- Sho Nakatani
Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)
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. That's a point you completely ignore. And other people than you also do not find that easier. There are auto-testers for performance and regression hunting and they simply stop working if bootstrap breaks. Also, scripts to bisect to a regression have a higher risk of running into a broken tree if bootstrap is broken over a longer period of time. That's an effect that may be felt for months/years. There were ~80 checkins on the trunk since r171843, most of them non-trivial. If one of those introduced a regression it is now more difficult to automatically identify which patch introduced it. I don't understand, really, why it's such a big deal to revert a patch quickly if it broke something. Yes, it should be done with care. But not depending on weekends and holidays. For some people the weekend is the only time they can work on GCC (hi!) and autotesters don't care if it's weekend or not :-) 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. Ciao! Steven
Re: Give me advice on GSoC OpenMP
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, 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. Jakub
