On Thu, Jan 19, 2006 at 08:49:34PM -0500, David Edelsohn wrote:
> > Jakub Jelinek writes:
>
> Jakub> * config/rs6000/rs6000.md (UNSPEC_LWSYNC, UNSPEC_ISYNC,
> Jakub> UNSPEC_SYNC_OP, UNSPEC_ATOMIC, UNSPEC_CMPXCHG, UNSPEC_XCHG): Rename
> Jakub> to...
> Jakub> (UNSPECV_LWSYNC, UNSPECV_ISYNC, UNSP
Daniel Berlin wrote:
On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mainline fails to bootstrap for me (revision 110017)
on i686-pc-linux-gnu.
Configured as:
$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,jav
On 1/20/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> > On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> > > ... the real
> > > solution is to transfer the information that the stack space sharing
> > > knows into some
The tree is still broken for me. Daniel, did you commit your patch?
Andreas
--
Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
pgprQ6b4mKkqS.p
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> Daniel Berlin wrote:
>> The attached fixes *that*, but this just causes a crash deeper in trying to
>> free some chains.
> [...]
> Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed accord
(I've sent this first to gcc-patches accidently :(
> Kenny thought it would be nice, rather than pass the actual bb info to free
> to the freeing function, to instead pass some random bitmap.
>
>
> The attached fixes *that*, but this just causes a crash deeper in trying to
> free some chains.
>
Andreas Jaeger wrote:
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the
Andreas Jaeger wrote:
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the
Hello Ioannis;
Ioannis E. Venetis wrote:
> > Would __builtin_stack_size (F) retrieve information about F's stack frame
> > only, or would it also recursively account for every other function that
> > F may call ?
> >
> > Implementing the former is probably possible, though I'm not sure
> > exactl
Hi,
Sometimes I have got a bus error at libstdc++ with gcc
3.4.2
in SUN.
I have used a multithread 64 bits application that
loads dynamicly ( as a application's plugin ) a couple
of dinamic libraries. That application and all your
dynamic libraries have a strong use of C++ Standard
Librarie.
On Fri, 2006-01-20 at 12:34 +0100, Andreas Jaeger wrote:
> The tree is still broken for me. Daniel, did you commit your patch?
No, because i realized last night that you will just hit the rest of the
problem during bootstrap, without fail.
>
> Andreas
Hello,
> >>>The attached fixes *that*, but this just causes a crash deeper in trying
> >>>to free some chains.
> >>>
> >>[...]
> >>Sorry for the problems and thanks for looking into them.
> >>
> >
> >Ken, please reread the email. The issue is *not* fixed according to
> >Daniel, there's
> Jakub Jelinek writes:
Jakub> Not sure why sched allows that, because insn 42 clearly operates on
volatile
Jakub> memory. Do you think that's a bug in sched that it should be honoring
Jakub> /v and not moving insns accross it, or that something is broken with the
Jakub> ppc* patterns?
Zdenek Dvorak wrote:
Hello,
The attached fixes *that*, but this just causes a crash deeper in trying
to free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed according to
Daniel
Geoff Keating wrote:
On 19/01/2006, at 9:08 AM, Peter O'Gorman wrote:
Eric Botcazou wrote:
|>Yes the workaround is to add -fexceptions or -shared-libgcc to the
|>command line when linking libgnat but I don't know if that is the
correct
|>fix or some hacking to config/darwin.h is needed.
|
|
> LIBGNAT=../rts/libgnat.a
> GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
> +TOOL_CC=$(CC) -static-libgcc
I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.
Otherwise the tools part is generally fine with me (passing -static-libgcc
to build
On Fri, 2006-01-20 at 16:06 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > >>>The attached fixes *that*, but this just causes a crash deeper in trying
> > >>>to free some chains.
> > >>>
> > >>[...]
> > >>Sorry for the problems and thanks for looking into them.
> > >>
> > >
> > >Ken, please
On Fri, Jan 20, 2006 at 10:10:23AM -0500, David Edelsohn wrote:
> > Jakub Jelinek writes:
>
> Jakub> Not sure why sched allows that, because insn 42 clearly operates on
> volatile
> Jakub> memory. Do you think that's a bug in sched that it should be honoring
> Jakub> /v and not moving insns
On Fri, 20 Jan 2006, Kenneth Zadeck wrote:
> I would like permission to revert Zdenek's patch for a few days. There
> is nothing wrong with zdenek's patch, pe se, but it excercises a part of
> df that should work but does not.
I'm going to make an executive decision on this one, to restore boot
Hello,
> > > >>>The attached fixes *that*, but this just causes a crash deeper in
> > > >>>trying
> > > >>>to free some chains.
> > > >>>
> > > >>[...]
> > > >>Sorry for the problems and thanks for looking into them.
> > > >>
> > > >
> > > >Ken, please reread the email. The issue is *
Hello,
> On Fri, 20 Jan 2006, Kenneth Zadeck wrote:
> > I would like permission to revert Zdenek's patch for a few days. There
> > is nothing wrong with zdenek's patch, pe se, but it excercises a part of
> > df that should work but does not.
>
>
> I'm going to make an executive decision on this
[...]
| > > Btw.: of course it may happen that some patch sometimes breaks
| > > bootstrap, it happened to everyone of us. But, with your patch, not
| > > even libgcc builds. This means that you did not even try to build gcc
| > > before commiting your patch.
| >
| > This is simply not true.
|
> So he updated his tree, saw changes in the middle-end and committed
> his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
only to discover that something again changed in-between, and so on?
--
Eric Botcazou
Eric Botcazou <[EMAIL PROTECTED]> writes:
| > So he updated his tree, saw changes in the middle-end and committed
| > his without testing.
|
| So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
| only to discover that something again changed in-between, and so on?
I do
Hello,
> > So he updated his tree, saw changes in the middle-end and committed
> > his without testing.
>
> So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
> only to discover that something again changed in-between, and so on?
while the testing procedures for gcc re
Eric Botcazou wrote:
So he updated his tree, saw changes in the middle-end and committed
his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
only to discover that something again changed in-between, and so on?
This is exactly what I did,
> I don't know whether it would take him hours, since the tree does not
> even bootstrap, but most certainly Zdenek's statement was accurate and
> our commit procedure wasn't observed.
I'm not sure the commit procedure requires you to retest in that case.
--
Eric Botcazou
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
> I propose the following workaround instead, that also restores
> bootstrap. It changes the way loop-iv uses df to more conservative one,
> that does not seem to cause problems.
That's what I like to see... options. Yes, this is OK for mainline,
please
Hello,
> Eric Botcazou wrote:
> >>So he updated his tree, saw changes in the middle-end and committed
> >>his without testing.
> >>
> >
> >So Kenny would have had to lauch a new bootstrap, wait for a couple of
> >hours only to discover that something again changed in-between, and so on?
> >
>
Richard Guenther wrote:
> A patch was also posted based on ideas in the audit trail. It's third
> incarnation at
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> would need a review.
This patch uses "type_i == type_j" which is usually a mistake; are we
sure we don't need the usual typ
On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> Richard Guenther wrote:
> > A patch was also posted based on ideas in the audit trail. It's third
> > incarnation at
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> > would need a review.
>
> This patch uses "type_i == type_j" w
On 1/20/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > A patch was also posted based on ideas in the audit trail. It's third
> > incarnation at
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> > would need a review.
>
> This patch uses "type_i == type_j"
Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
>
>>Richard Guenther wrote:
>>
>>>A patch was also posted based on ideas in the audit trail. It's third
>>>incarnation at
>>>http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
>>>would need a review.
>>
>>This pat
On Friday 20 January 2006 18:34, Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> > Richard Guenther wrote:
> > > A patch was also posted based on ideas in the audit trail. It's third
> > > incarnation at
> > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
Richard Guenther wrote:
>>patch needs a paragraph-long comment explaining what the problem is and
>>how this approach solves it.
>
> Ok, I'll try to come up with an explanation.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Friday 20 January 2006 18:38, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> >>Richard Guenther wrote:
> >>>A patch was also posted based on ideas in the audit trail. It's third
> >>>incarnation at
> >>>http://gcc.gnu.org/ml/gcc-patches
"Anatoly Sokolov" <[EMAIL PROTECTED]> writes:
> Hello.
>
> I am the member of the project 'avr-libc' (AVR C Runtime Library). As
> a result of this work there were patches with additions of support of
> new Atmel devices in gcc the toolchain. I have a desire to add them in
> official GCC sources,
On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> FWIW, I don't believe this is a "fix", but rather a solid work-around
> for the problem. I'm still trusting rth's superior compiler brain and
> GCC knowledge to ultimately be ingredients in a real fix ;-)
I don't think it's quite
Richard Henderson wrote:
On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote:
In team.c solaris fails due to the fact that alloca is defined in
alloca.h iso stdlib.h ...
Er, *not* defined did you mean? This should probably be fixed
with a #define to __builtin_alloca in libgomp.h or
On 1/20/06, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> > FWIW, I don't believe this is a "fix", but rather a solid work-around
> > for the problem. I'm still trusting rth's superior compiler brain and
> > GCC knowledge to ultim
Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
>
>>FWIW, I don't believe this is a "fix", but rather a solid work-around
>>for the problem. I'm still trusting rth's superior compiler brain and
>>GCC knowledge to ultimately be ingredients in a real fix
Andreas Tobler wrote:
Richard Henderson wrote:
On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote:
In team.c solaris fails due to the fact that alloca is defined in
alloca.h iso stdlib.h ...
Er, *not* defined did you mean? This should probably be fixed
with a #define to __builtin
On Thu, Jan 19, 2006 at 09:56:54PM -0500, DJ Delorie wrote:
> Nobody has said anything about this for the last two weeks. Can we
> remove this restriction now?
Have you done any testing on common platforms to see what
happens when you change this?
r~
> Have you done any testing on common platforms to see what happens
> when you change this?
It's been in my x86-64 builds for the last few months. That's the
"gcc" that gets used for everything else. Are there other platforms
that are likely to have one-bit insv patterns? (of course, that's th
On Fri, Jan 20, 2006 at 10:18:18PM +0100, Andreas Tobler wrote:
> or with double guard:
>
> #ifdef HAVE_GETLOADAVG
> #ifdef HAVE_SYS_LOADAVG_H
> # include sys/loadavg.h
> #endif
> #endif
This, I guess.
> >Sounds like a typo in the specs for the platform.
>
> Hm, in gcc.c I find a hardcoded -pth
On Fri, Jan 20, 2006 at 04:44:04PM -0500, DJ Delorie wrote:
> It's been in my x86-64 builds for the last few months. That's the
> "gcc" that gets used for everything else. Are there other platforms
> that are likely to have one-bit insv patterns? (of course, that's the
> question nobody answered
Richard Henderson wrote:
On Fri, Jan 20, 2006 at 10:18:18PM +0100, Andreas Tobler wrote:
or with double guard:
#ifdef HAVE_GETLOADAVG
#ifdef HAVE_SYS_LOADAVG_H
# include sys/loadavg.h
#endif
#endif
This, I guess.
Ok. Thanks.
Sounds like a typo in the specs for the platform.
Hm, in gcc.c
On Fri, Jan 20, 2006 at 03:42:57AM -0500, Jakub Jelinek wrote:
> The mem in the sync insn has alias set 0 and no attributes
> except MEM_VOLATLE_P. The reason why sched1 decided to move it anyway
> is that it proved that the MEMs are different:
Ah yes. I'd meant to go back and add a bit or tag t
> m68k and ia64 spring to mind. Both have set-one-bit-in-register
> type instructions. But the point isn't that x86-64 continues to
> build, but that it's still using the right patterns.
If you could suggest a proper testing strategy, I'm willing to test
it.
On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
> I guess a secondary question is: is the workaround sufficiently useful
> in many of the problematic cases and sufficiently non-harmful in other
> cases as to merit inclusion, given that we don't have a better solution?
I replied with
Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
>
>>I guess a secondary question is: is the workaround sufficiently useful
>>in many of the problematic cases and sufficiently non-harmful in other
>>cases as to merit inclusion, given that we don't have a be
> Hm, then sol2.h and sol26.h build the minority where we have pthread_s_.
> Don't know the history yet.
That doesn't seem to be a Sun-ism.
--
Eric Botcazou
On Fri, Jan 20, 2006 at 04:56:38PM -0500, DJ Delorie wrote:
> If you could suggest a proper testing strategy, I'm willing to test it.
Write a small test that is supposed to use one of the set-bit
insns. Verify that it does before and after the patch.
r~
Snapshot gcc-4.1-20060120 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060120/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Arnaud Charlet wrote:
LIBGNAT=../rts/libgnat.a
GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
+TOOL_CC=$(CC) -static-libgcc
I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.
I thought so too, and indeed tried it this way at first, but got
Hi All,
I found following code snippet in file, trunk/gcc/loop-unroll.c
1814 /* Locate in EXPR the expression corresponding to the location recorded
1815in IVTS, and return a pointer to the RTX for this location. */
1816
1817 static rtx *
1818 get_ivts_expr (rtx expr, struct i
I noticed today that there were three projects which were merged into
the mainline within a 24 hour period yesterday.
Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit
Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo
So I a
On Thu, Jan 19, 2006 at 06:44:28PM -0800, Mark Mitchell wrote:
> Joe Buck wrote:
>
> > So the answer is that, after consulting with some of the affected people
> > (which is why you got mail, Mike) the SC told RMS that it would be
> > changed. If it hasn't been done yet, then it's a release block
This fixes the problems that became apparent from zdeneks patch.
Bootstrapped and regression tested against the version with zdenek's
original code (since this directly tickled the failure and bootstrapped
(and in the process of regression testing) against the current mainline.
Both on i686-pc
On Sun, 15 Jan 2006 10:40:19 -0600, Perry Smith wrote:
> From Andreas's reply, it may not. In AIX, they want the message to
>come out in the user's native language so they print out the
>translated message (that comes from a separate file).
It's the same with gettext. You have a file contain
Joe Buck wrote:
> It is PR 25892.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> Bootstrapped and regression tested against the version with zdenek's
> original code (since this directly tickled the failure and
> bootstrapped (and in the process of regression testing) against the
> current mainline. Both on i686-pc-linux-gnu.
>
> K
Eric Fisher <[EMAIL PROTECTED]> writes:
> I guess that the macro NGARDS is relevant to the guard digit. But I
> still failed to have a clear conception about what it means. Others
> are easy to know by IEEE 754 and "What Every Computer Scientist Should
> Know about Floating-Point Arithmetic". Exce
Steven Bosscher <[EMAIL PROTECTED]> writes:
> The proposed work-around is to avoid confusing RTL alias analysis by
> simply not presenting it with situations where two references to the
> same memory can have different alias sets.
To recapitulate.
RTL alias analysis assumes that you can reorder
64 matches
Mail list logo
