Thomas,
In ran into this bootstrap failure with branch gomp-4_0-branch:
...
src/gcc-gomp-4_0-branch/gcc/omp-low.c:2897:1: error: 'omp_context*
enclosing_target_ctx(omp_context*)' defined but not used [-Werror=unused-function]
enclosing_target_ctx (omp_context *ctx)
^
cc1plus: all warnings bei
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.03.2015 18:30, schrieb Rainer Emrich:
> Am 25.03.2015 17:22, schrieb Kai Tietz:
>> Hmm, this seems to be something I haven't noticed until now. It might
>> be new ... I see that cp-tree.h is part of gtfiles in config-lang.in. So
>> the warning
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.03.2015 17:22, schrieb Kai Tietz:
> Hmm, this seems to be something I haven't noticed until now. It might be
> new ... I see that cp-tree.h is part of gtfiles in config-lang.in. So the
> warning about being not tagged for that language is weir
Hmm, this seems to be something I haven't noticed until now. It might
be new ...
I see that cp-tree.h is part of gtfiles in config-lang.in. So the
warning about being not tagged for that language is weird. Issue
might be not directly within gcc.
Instead it might be a make issue.
You could ask on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is on x86_64-w64-mingw32.
build/gengtype.exe \
-S
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc -I
gtyp-input.list -w tmp-gtype.state
gtyp-input.list:101: file
../../../../../../../opt/devel/gnu/src/gc
On Sun, Jan 19, 2014 at 07:39:12PM +0100, Winfried Magerl wrote:
> Hi,
>
> since "trunk revision 206525" I'm unable to bootstrap
> gcc with '-O3' as optimisation. No problem until
> revision 2065250.
>
> From the diff-output it looks like this entry from
> ChangeLog is the only candidate:
>
> --
High,
since "trunk revision 206525" I'm unable to bootstrap
gcc with '-O3' as optimisation. No problem until
revision 2065250.
>From the diff-output it looks like this entry from
ChangeLog is the only candidate:
---
diff -urN -x.svn gcc-head-206520/LAST_UPDATED gcc-head-206525/LA
On Tue, Nov 12, 2013 at 11:52 AM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote:
>> On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>>
>> > > Unfortunately, we are not able to keep up with the old kernels.
>> > > Two possible ways to go:
>> > > - disable li
On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote:
> On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>
> > > Unfortunately, we are not able to keep up with the old kernels.
> > > Two possible ways to go:
> > > - disable libsanitizer on older kernels
> > > - someone needs to work wit
[text-only]
On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>> Unfortunately, we are not able to keep up with the old kernels.
>> Two possible ways to go:
>> - disable libsanitizer on older kernels
>> - someone needs to work with us in upstream repository (llvm) to keep the
>> code old-kernel-comp
> Unfortunately, we are not able to keep up with the old kernels.
> Two possible ways to go:
> - disable libsanitizer on older kernels
> - someone needs to work with us in upstream repository (llvm) to keep the
> code old-kernel-compatible
(It appears to be not only kernel, but binutils.)
I th
[resending text-only]
On Sun, Nov 10, 2013 at 8:51 AM, Konstantin Serebryany
wrote:
> Unfortunately, we are not able to keep up with the old kernels.
> Two possible ways to go:
> - disable libsanitizer on older kernels
> - someone needs to work with us in upstream repository (llvm) to keep th
> In principle, you could try --disable-libsanitizer
> --disable-target-libsanitizer but I am not sure whether that works, a
> fortnight ago, Janne remarked at #gcc that it didn't seem to work – maybe you
> have more luck.
>
> Your Linux 2.6.18 is already quite old (September 2007) thus I would
FX wrote:
I’m building with binutils 2.17.50.0.6, which is a bit old but I cannot find
any mention of needing later binutils on the installation notes.
Is bootstrap broken, or am I missing something?
Second build, this time with trunk binutils. Still fails in libsanitizer at
stage1, this
> I’m building with binutils 2.17.50.0.6, which is a bit old but I cannot find
> any mention of needing later binutils on the installation notes.
> Is bootstrap broken, or am I missing something?
Second build, this time with trunk binutils. Still fails in libsanitizer at
stage1, this
he installation notes.
Is bootstrap broken, or am I missing something?
FX
On Fri, Nov 8, 2013 at 5:49 AM, Peter Bergner wrote:
> On Fri, 2013-11-08 at 00:03 +0100, Steven Bosscher wrote:
>> powerpc64-linux bootstrap is broken by the libsanitizer merge:
>
> I already reported the failures here:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00312.html
>
> It seems
On Fri, 2013-11-08 at 00:03 +0100, Steven Bosscher wrote:
> powerpc64-linux bootstrap is broken by the libsanitizer merge:
I already reported the failures here:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00312.html
It seems others have reported it breaks bootstrap for them as
well on other
Hello,
powerpc64-linux bootstrap is broken by the libsanitizer merge:
In file included from
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:21:0:
/usr/include/asm/stat.h:31:2: error: 'ino_t' does not name a type
ino_t st_ino;
^
/usr/include/asm/stat.h:34:2:
On Fri, Sep 6, 2013 at 7:40 AM, Jan Hubicka wrote:
>> On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote:
>> > > > .. looks like this is target/58269, which therefore affects
>> > > > x86_64-linux too.
>> > >
>> > > Now this reproduces to me, too. apppy_args expansion is trying to
>> >
> On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote:
> > > > .. looks like this is target/58269, which therefore affects
> > > > x86_64-linux too.
> > >
> > > Now this reproduces to me, too. apppy_args expansion is trying to
> > > preserve AVX
> > > register in V8SF mode when AVX is di
On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote:
> > > .. looks like this is target/58269, which therefore affects
> > > x86_64-linux too.
> >
> > Now this reproduces to me, too. apppy_args expansion is trying to preserve
> > AVX
> > register in V8SF mode when AVX is disabled. This
> > .. looks like this is target/58269, which therefore affects
> > x86_64-linux too.
>
> Now this reproduces to me, too. apppy_args expansion is trying to preserve
> AVX
> register in V8SF mode when AVX is disabled. This leads to move expander to
> not
> allow moving it and we end up infinite
> .. looks like this is target/58269, which therefore affects
> x86_64-linux too.
Now this reproduces to me, too. apppy_args expansion is trying to preserve AVX
register in V8SF mode when AVX is disabled. This leads to move expander to not
allow moving it and we end up infinitely recursing tryin
Hi,
On 09/06/2013 01:46 PM, Peter Bergner wrote:
On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote:
. on x86_64-linux, this commit broke the build of that file:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
CC-ing Peter.
Can you try the patch that HJ suggested?
http://gcc.gnu.
On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote:
> . on x86_64-linux, this commit broke the build of that file:
>
> http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
>
> CC-ing Peter.
Can you try the patch that HJ suggested?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139#c9
Peter
. on x86_64-linux, this commit broke the build of that file:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
CC-ing Peter.
Thanks,
Paolo.
.. looks like this is target/58269, which therefore affects
x86_64-linux too.
Paolo.
Hi
today the bootstrap is broken, some sort of infinite recursion. A quick
make gives the below.
Thanks,
Paolo.
/
libtool: compile: /home/paolo/Gcc/svn-dirs/trunk-build/./gcc/xgcc
-B/home/paolo/Gcc/svn-dirs/trunk-build/./gcc/
-B/home/paolo/Gcc/svn-dirs/trunk-install/x8
Like this. Tested on powerpc-linux and installed as obvious.
Andreas.
* include/Makefile.am (${host_builddir}/c++config.h): Replace
[] by [].
* include/Makefile.in: Regenerate.
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 44200ee
On Tue, Dec 4, 2012 at 5:22 PM, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152
>
> I think if you had changed to it would have a
> better chance to survive broken editors.
I only put back what was there before. To be hones
Steven Bosscher writes:
> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152
I think if you had changed to it would have a
better chance to survive broken editors.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D
Steven Bosscher writes:
> Looks like someone used a broken editor replacing tabs with spaces:
Rather the other way round.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different.
On Tue, Dec 4, 2012 at 4:47 PM, Steven Bosscher wrote:
> On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
>> Hello,
>>
>> Someone broke bootstrap on powerpc64-linux between r194084 and
>> r194141. Anyone else seeing this?
>>
>> Ciao!
>> Steven
>
> Looks like someone used a broken editor repla
On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
> Hello,
>
> Someone broke bootstrap on powerpc64-linux between r194084 and
> r194141. Anyone else seeing this?
>
> Ciao!
> Steven
Looks like someone used a broken editor replacing tabs with spaces:
2012-12-03 Benjamin Kosnik
* i
Hello,
Someone broke bootstrap on powerpc64-linux between r194084 and
r194141. Anyone else seeing this?
Ciao!
Steven
../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:338:8:
error: 'void
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intItEES3_S3_S3_RSt8ios
On Tue, Oct 30, 2012 at 2:04 PM, Eric Botcazou wrote:
>> Right, there's no explicit dependencies for seh_init.o at all, although
>> this is not something new. Has something changed recently in the way
>> e.g. system.h or similar are generated/handled that would explain this
>> change in behavior?
> Right, there's no explicit dependencies for seh_init.o at all, although
> this is not something new. Has something changed recently in the way
> e.g. system.h or similar are generated/handled that would explain this
> change in behavior?
No changes as far as I know, but maybe Diego got a brand n
On Tue, Oct 30, 2012 at 12:45 PM, Arnaud Charlet wrote:
> Diego, can you confirm that it's indeed seh_init.o which is failing?
Yes. The error was given on seh_init.c:48
Thanks. Diego.
> I cannot reproduce, but this might come from missing dependencies in Make-
> lang.in for the affected files.
Right, there's no explicit dependencies for seh_init.o at all, although
this is not something new. Has something changed recently in the way
e.g. system.h or similar are generated/handled
> I'll have a look.
I cannot reproduce, but this might come from missing dependencies in Make-
lang.in for the affected files.
--
Eric Botcazou
On Tue, Oct 30, 2012 at 11:44 AM, Arnaud Charlet wrote:
> I'll have a look.
Thanks!
> On IRC, Richi says that this is a parallel make issue. Re-starting
> make works around the issue.
>
> For now, I'm forced to disable Ada bootstraps. Could someone in ada
> land take a look at this?
I'll have a look.
Arno
I'm getting the following while trying to bootstrap a clean trunk at rev 192986:
cd ada/bldtools/einfo; gnatmake -q xeinfo ; ./xeinfo einfo.h )
In file included from gcc/clean/trunk/gcc/ada/seh_init.c:48:0:
gcc/clean/trunk/gcc/system.h:499:34: error: declaration of C function
'const char* strsigna
Committed in r192788.
Thanks,
Sharad
Sharad
On Wed, Oct 24, 2012 at 4:02 PM, Sharad Singhai wrote:
> I thought Steven was going to do that. If not, I can apply it.
>
> Thanks,
> Sharad
> Sharad
>
>
> On Wed, Oct 24, 2012 at 4:00 PM, David Edelsohn wrote:
>> Is someone going to apply this patch
I thought Steven was going to do that. If not, I can apply it.
Thanks,
Sharad
Sharad
On Wed, Oct 24, 2012 at 4:00 PM, David Edelsohn wrote:
> Is someone going to apply this patch?
>
> Thanks, David
>
> On Wed, Oct 24, 2012 at 5:18 PM, Sharad Singhai wrote:
>> On Wed, Oct 24, 2012 at 2:13 PM, S
Is someone going to apply this patch?
Thanks, David
On Wed, Oct 24, 2012 at 5:18 PM, Sharad Singhai wrote:
> On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher
> wrote:
>> Hello,
>>
>> ../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
>> rs6000_density_test(rs6000_cost_data*)':
>> ../../
On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher wrote:
> Hello,
>
> ../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
> rs6000_density_test(rs6000_cost_data*)':
> ../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
> was not declared in this scope
>
> This is due to:
>
>
Hello,
../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
rs6000_density_test(rs6000_cost_data*)':
../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
was not declared in this scope
This is due to:
2012-10-24 Sharad Singhai
* dumpfile.c (dump_enabled_p): Make
On 23.09.12 18:24, Richard Guenther wrote:
On Sat, Sep 22, 2012 at 9:40 AM, Andreast Tobler
wrote:
Hi all,
while testing some patches fro Michael M, I noticed that disable-checking
seems broken on trunk. I saw this on x86_64-freebsd and powerpc64-freebsd.
Is this issue already known?
If not,
On Sat, Sep 22, 2012 at 9:40 AM, Andreast Tobler
wrote:
> Hi all,
>
> while testing some patches fro Michael M, I noticed that disable-checking
> seems broken on trunk. I saw this on x86_64-freebsd and powerpc64-freebsd.
>
> Is this issue already known?
> If not, usual bug report with preprocessed
Hi all,
while testing some patches fro Michael M, I noticed that
disable-checking seems broken on trunk. I saw this on x86_64-freebsd and
powerpc64-freebsd.
Is this issue already known?
If not, usual bug report with preprocessed source?
TIA;
Andreas
Here the details:
-
/export/devel/ne
On Tue, 4 Sep 2012, Steven Bosscher wrote:
> Also, on at least powerpc64-unknown-linux-gnu (a primary platform) and
> sparc64-unknown-linux-gnu and probably others (PR54453). The breakage
> is caused by drepper's patches at r190783 and r190787. The breakage
> on powerpc64 is now almost a week old
Hello,
Bootstrap is currently broken on x86 targets with binutils 2.20 (from
2009) and older (PR54419) because the rdrand instruction is emitted
but that instruction is only supported in binutils 2.21 and later.
This means bootstrap is broken on almost all x86_64 machines in the
compile farm for e
On Wed, Apr 6, 2011 at 7:48 AM, Richard Earnshaw wrote:
>
> On Tue, 2011-04-05 at 08:26 +0200, 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
On Wed, Apr 6, 2011 at 7:45 AM, Richard Earnshaw wrote:
>
> On Tue, 2011-04-05 at 08:58 -0600, Jeff Law wrote:
>> 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
On Tue, 2011-04-05 at 08:26 +0200, 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
On Tue, 2011-04-05 at 08:58 -0600, Jeff Law wrote:
> 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?
I don't think developers should be comm
On Wed, Apr 6, 2011 at 1:30 AM, Jeff Law wrote:
> -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 pat
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 la
-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
> 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 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
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
r 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
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
-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 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,
-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
>>>
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
-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 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/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:
-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
> 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
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/
-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
> 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.
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
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
-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 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
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 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 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: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 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 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 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 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, 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
> 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 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
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 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 aut
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 acce
-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 prima
-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 p
1 - 100 of 346 matches
Mail list logo
