haifa-sched.c:
2302/* Let the target filter the search space. */
2303for (i = 1; i < ready->n_ready; i++)
2304 if (!ready_try[i])
2305{
2306 insn = ready_element (ready, i);
2307
2308 gcc_assert (INSN_CODE (insn) >= 0
Peter Bergner wrote:
On Thu, 2008-09-04 at 20:28 -0400, David Edelsohn wrote:
On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Meanwhile I am going to submit your second patch with an added
comment. The patch permits gcc to generate the same quality code as
b
On Thu, 2008-09-04 at 20:28 -0400, David Edelsohn wrote:
> On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> > Meanwhile I am going to submit your second patch with an added
> > comment. The patch permits gcc to generate the same quality code as
> > before your first pa
On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Meanwhile I am going to submit your second patch with an added
> comment. The patch permits gcc to generate the same quality code as
> before your first patch.
Why?
As Richard said before:
"... it changes
the heuristi
Richard Sandiford wrote:
Richard Sandiford <[EMAIL PROTECTED]> writes:
Vladimir Makarov <[EMAIL PROTECTED]> writes:
Richard Sandiford wrote:
But as I said to HJ, I'm happy to apply the DF patch in isolation,
as long as we accept that the benefit of fixing a correctness
regressio
> Plugins features. This addresses Richard Stallman's concerns, so he
> no
> longer objects to a Plugins feature.
That is GREAT news!!!
> We, the GCC community, are waiting for the advocates of Plugins to
> reach
> a consensus on a single plugins architecture and implement it. When
> are the
>
Snapshot gcc-4.3-20080904 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080904/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, Sep 05, 2008 at 08:11:34AM +1000, Brendon Costa wrote:
> Every now and then I poke my head into this list to see if there is any
> more progress on the GCC Plugin branch issue. In particular I don't want
> to give up on this feature as it will be enormously useful for my open
> source proje
Hi all,
Every now and then I poke my head into this list to see if there is any
more progress on the GCC Plugin branch issue. In particular I don't want
to give up on this feature as it will be enormously useful for my open
source project EDoc++.
In the past, we have had a lot of discussion about
[ see parents for my build problems ]
On Thu, Sep 04, 2008 at 02:00:11PM -0700, Ian Lance Taylor wrote:
> These days autoconf likes to dump a whole bunch of cruft at the end of
> config.log. You have to look above all the cruft, which is usually
> most of the file, to find the actual failing test
Joe Buck <[EMAIL PROTECTED]> writes:
> But ia64-unknown-linux-gnu/libgcc/config.log doesn't have any useful
> details. It has
>
> CC='/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc
> -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/
> -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/
> -B
On Thu, Sep 04, 2008 at 11:12:59AM -0700, Joe Buck wrote:
> > I also found an ia64 box running Red Hat Advanced Workstation 2.1.
> > Yes, I know, really old, but I can't change it. I tried a build...
> > but the bootstrap died.
On Thu, Sep 04, 2008 at 11:37:47AM -0700, Joe Buck wrote:
> I think
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Vladimir Makarov <[EMAIL PROTECTED]> writes:
>> Richard Sandiford wrote:
>>> But as I said to HJ, I'm happy to apply the DF patch in isolation,
>>> as long as we accept that the benefit of fixing a correctness
>>> regression outweighs the potential pe
On Thu, Sep 04, 2008 at 11:12:59AM -0700, Joe Buck wrote:
> I also found an ia64 box running Red Hat Advanced Workstation 2.1.
> Yes, I know, really old, but I can't change it. I tried a build...
> but the bootstrap died.
I think the issue was that the --with-gmp and --with-mpfr directories
weren
I located a couple of old machines to try, so I have two more successful
build reports, and one failure (though don't worry about the failure yet).
First one (includes C, C++, ObjC, Fortran, and Java)
i686-pc-linux-gnu on a RHEL 3 system.
boot compiler: gcc 3.3.6 (FSF release)
kernel: 2.4.21-32.E
"M R Swami Reddy" <[EMAIL PROTECTED]> writes:
> I am trying to build the gcc tools on cygwin host. But the build
> failed with below errors:
>
> $ gcc -I../../../trunk/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
> -Wstr
> ict-prototypes -Wmissing-prototypes -Wold-style-definition
> -
Hello,
In our GCC porting (gcc 4.3.1), I am facing a problem with
built-in-setjmp test, which failed from -O2. After spending quite some
time on it, I figured out what happens, but not sure what is the best
way to fix it. The problem is with __builtin_setjmp_receiver.
In built-in-setjmp.c.132r.ex
On Thu, 2008-09-04 at 13:59, Dennis Clarke wrote:
> >
> > On Thu, 2008-09-04 at 13:44, Dennis Clarke wrote:
> >> > Hi.
> >> >
> >> > My last successful build was from yesterday morning. After the
> large
> >> > libstdc++ patch by Chris Fairles landed the builds have failed
> with
> >> the
> >> > f
>
> On Thu, 2008-09-04 at 13:44, Dennis Clarke wrote:
>> > Hi.
>> >
>> > My last successful build was from yesterday morning. After the large
>> > libstdc++ patch by Chris Fairles landed the builds have failed with
>> the
>> > following error:
>> >
>> > In file included from
>> > /export/home/arth
On Thu, 2008-09-04 at 13:44, Dennis Clarke wrote:
> > Hi.
> >
> > My last successful build was from yesterday morning. After the large
> > libstdc++ patch by Chris Fairles landed the builds have failed with
> the
> > following error:
> >
> > In file included from
> > /export/home/arth/gnu/gcc.git/
> Hi.
>
> My last successful build was from yesterday morning. After the large
> libstdc++ patch by Chris Fairles landed the builds have failed with the
> following error:
>
> In file included from
> /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
> /export/home/arth/gnu/gcc-0904/i386-
On Thu, 2008-09-04 at 13:41, Chris Fairles wrote:
> On Thu, Sep 4, 2008 at 9:30 AM, Art Haas <[EMAIL PROTECTED]>
> wrote:
> > Hi.
> >
> > My last successful build was from yesterday morning. After the large
> > libstdc++ patch by Chris Fairles landed the builds have failed with
> the
> > following
On Thu, Sep 04, 2008 at 09:04:30AM -0400, David Edelsohn wrote:
> That is unfortunate, but it is a long-term, known problem with PSIM. Someone
> maintaining PSIM needs to update it.
Also unfortunately, there is no one maintaining PSIM. It's shipped
with GDB, but I consider that only a convenienc
On Thu, Sep 4, 2008 at 9:41 AM, Chris Fairles <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 4, 2008 at 9:30 AM, Art Haas <[EMAIL PROTECTED]> wrote:
>> Hi.
>>
>> My last successful build was from yesterday morning. After the large
>> libstdc++ patch by Chris Fairles landed the builds have failed with the
On Thu, Sep 4, 2008 at 9:30 AM, Art Haas <[EMAIL PROTECTED]> wrote:
> Hi.
>
> My last successful build was from yesterday morning. After the large
> libstdc++ patch by Chris Fairles landed the builds have failed with the
> following error:
>
> In file included from
> /export/home/arth/gnu/gcc.git/l
On Thu, Sep 4, 2008 at 5:29 AM, Rainer Emrich <[EMAIL PROTECTED]> wrote:
> recently I see this failures:
>
> Running target unix/-m32
> FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer execution test
> FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-loops
> execution test
Hi.
My last successful build was from yesterday morning. After the large
libstdc++ patch by Chris Fairles landed the builds have failed with the
following error:
In file included from
/export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
/export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/li
David Edelsohn wrote:
On Thu, Sep 4, 2008 at 8:31 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Another related issue is that psim in gdb does not currently
support the lwsync instruction so any code generated using it
would fail there. Since this is used as the test platform for
the embedded
On Thu, Sep 4, 2008 at 8:31 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
> Another related issue is that psim in gdb does not currently
> support the lwsync instruction so any code generated using it
> would fail there. Since this is used as the test platform for
> the embedded gcc targets (at lea
David Daney wrote:
On Wed, Sep 3, 2008 at 6:09 PM, David Edelsohn <[EMAIL PROTECTED]> wrote:
On Wed, Sep 3, 2008 at 6:53 PM, Anton Blanchard <[EMAIL PROTECTED]> wrote:
The only thing lwsync wont order is a store followed by a load. Since
the lwsync will always be paired with a store (th
recently I see this failures:
Running target unix/-m32
FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer execution test
FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finlin
Hello,
I am trying to build the gcc tools on cygwin host. But the build failed with
below errors:
$ gcc -I../../../trunk/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings -Wstr
ict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-att
ribute -Wcast-qual -pedantic -Wn
Duncan Sands wrote:
Building gcc from svn today I see the following:
prj-nmsc.adb: In function ‘Prj.Nmsc.Check_Naming_Schemes’:
prj-nmsc.adb:3272: warning: ‘Casing’ may be used uninitialized in this
function
...
g-socket.adb: In function ‘GNAT.SOCKETS.SEND_SOCKET’:
g-socket.adb:1786
David Edelsohn wrote:
> On Wed, Sep 3, 2008 at 6:53 PM, Anton Blanchard <[EMAIL PROTECTED]> wrote:
>> The only thing lwsync wont order is a store followed by a load. Since
>> the lwsync will always be paired with a store (the stwcx), we will order
>> all accesses before it and provide a release bar
34 matches
Mail list logo
