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
>> rev
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 rol
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 fi
> 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
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 off
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
> th
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 involve
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
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
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 repro
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
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
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
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.
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.
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
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_ROUNDI
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
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
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
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
-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 wor
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 wel
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 yo
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
> 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.
-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
>>> th
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 execu
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/
> 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" co
-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 r
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 o
-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:
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, A
-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
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
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
-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
>>>
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 a
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
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" der
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,
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 sa
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
>
> 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 k
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
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
>>
>>
>> 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
-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 somet
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
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_d
> -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 (PR
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
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
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 th
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 w
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
> 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 re
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
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" ,
> "R
-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 th
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
62 matches
Mail list logo
