See: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg02723.html
The failure is caused by this (from
../x86_64-unknown-linux-gnu/libgcc/config.log):
configure:3246: checking for suffix of object files
configure:3268: /home/toon/compilers/obj-t/./gcc/xgcc
-B/home/toon/compilers/obj
-t/./gcc/ -
Alpha EV6 and newer can execute four instructions per cycle if correctly
scheduled. The architecture has two clusters {0, 1}, each with its own
register file. In each cluster, there are two slots {upper, lower}. Some
instructions only execute from either upper or lower slots.
Register values produ
Snapshot gcc-4.4-20110524 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110524/
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
On Tue, May 24, 2011 at 09:09, Alexey Kravets wrote:
> There are two places in graphite-opencl where we use strcmp technique.
> The first one is the detection of privatizable variables
> (opencl_private_var_name_p) and it can be eliminated by marking all zero
> dimensional arrays as private (see p
I was reviewing the status update of GCC4.6.1 released on the
gcc.gnu.org website on 20110426. The update states that GCC4.6.1
will be released sometime in late May. Does anyone know the exact date of the
release?
We are working on a Fortran code that needs a gfortran fix that was
committed to th
On 05/19/2011 06:52 PM, Sebastian Pop wrote:
I could loop at the internal name
of the variable, and check if it starts with graphite_IV.
I think this is a *very* bad idea, and unfortunately the graphite-opencl
code uses this strcmp technique to detect reductions, and that's why
the graphite-ope
This merge brings google/main rev 174086 into google/gcc-4_6.
Validated on x86_64.
Diego.
On 23/05/11 19:35, Richard Sandiford wrote:
> According to:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47110
>
> mips-openbsd does not build in 4.6. I haven't seen any activity
> on this port for years. Would anyone object to its deprecation?
I'm going to forward this to openbsd. Ple
