v 17 22:11:21 2016 +
Enable AVX512_4FMAPS and AVX512_4VNNIW instructions
This requires additional patch for register allocator from Vladimir
Makarov.
Anyone else seeing this?
Thanks.
Art Haas
cal/bin/ld --enable-libstdcxx-pch=no
Thread model: posix
gcc version 4.9.0 20140305 (experimental) [master revision
1a3ae6f:67f9942:8ecf2b4ab9881c344ac9ee5d1692343397923977] (GCC)
$
Thanks in advance for any help resolving this, and my thanks to everyone
working on GCC.
Art Haas
ith-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no
--with-cpu=ultrasparc3 --with-tune=ultrasparc3
Thread model: posix
gcc version 4.7.0 20110906 (experimental) [master revision
bdc818b:c562c54:dfb98d7502700782f4a1a4e04357e46fd90784fe] (GCC)
Thanks to everyone working on GCC.
Art Haas
st successful
build, so I'm guessing the issue is Solaris specific. Anyone else who
builds on this platform seeing similar problems?
Art Haas
_file_name */
Thanks, as always, to everyone working on GCC.
Art Haas
ome/arth/local/bin/as --with-gnu-ld
--with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no
--with-cpu=ultrasparc3 --with-tune=ultrasparc3
Thread model: posix
gcc version 4.6.0 20101123 (experimental) [master revision
66b86a7:d759d44:e71ec76db59f8a20d013503e7192680f92872796] (GCC)
Art Haas
ted in other
subdirectories below 'amd64', but in those file subsquent lines indicate
a test regarding cross-compiling.
The build this morning on the sparc-sun-solaris2.10 machine worked without
problems.
My thanks to everyone working on GCC.
Art Haas
patch to
the 'gmon-sol2.c' file made it here. Today's builds worked without
any problem.
I'd be glad to test any patch(es) that may help identify and resolve
the problem I'm seeing.
As always, thanks to all the GCC developers.
Art Haas
:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.6.0/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: /export/home/arth/src/gcc.git/configure
--prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls
--with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local
--with-mpc=/export/home/arth/local --enable-checking=release --enable-threads
--with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld
--with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no
--with-cpu=ultrasparc3 --with-tune=ultrasparc3
Thread model: posix
gcc version 4.6.0 20101007 (experimental) (GCC)
Thanks.
Art Haas
local/bin/as --with-gnu-ld
--with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no
--with-cpu=ultrasparc3 --with-tune=ultrasparc3
Thread model: posix
gcc version 4.6.0 20100923 (experimental) (GCC)
$
Thanks.
Art Haas
port/home/arth/local
--with-mpc=/export/home/arth/local --enable-checking=release --enable-threads
--with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld
--with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no
--with-cpu=ultrasparc3 --with-tune=ultrasparc3
Thread model: posix
gcc version 4.6.0 20100907 (experimental) (GCC)
Art Haas
print_operand_address, and print_operand_punct_valid_p fields.
{ ... snip ... }
My builds from yesterday morning both completed without problems.
Art Haas
,objc,fortran
--disable-nls --with-gmp=/export/home/arth/local
--with-mpfr=/export/home/arth/local --enable-checking=release
--enable-threads=posix --with-gnu-as --with-as=/export/home/arth/local/bin/as
--with-gnu-ld --with-ld=/export/home/arth/local/bin/ld
--enable-libstdcxx-pch=no --enable-objc-gc --build=i386-pc-solaris2.10
Thread model: posix
gcc version 4.6.0 20100525 (experimental) (GCC)
Thanks.
Art Haas
configure:3251: error: in
`/export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/amd64/libgcc':
configure:3254: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
My builds on a sparc-sun-solaris2.10 from yesterday worked fine - on
this machine GCC does _not_ use the '--disable-multilib' configuration
switch. This mornings build has just started.
My thanks to everyone working on GCC.
Art Haas
1:
warning: control reaches end of non-void function
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In
function 'casin':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1598:1:
warning: control reaches end of non-void function
/export/home/arth
dwarf2out.c:2753
Please submit a full bug report, with preprocessed source if appropriate.
Anyone else seeing failures like this?
Art Haas
http://gcc.gnu.org/ml/gcc/2008-09/msg00106.html
Art Haas
"no baseline to compare against"?
>
> Did you need to test this on Solaris 10 FCS ( build 74L2a ) or did you
> mean something else?
>
>
> Dennis Clarke
Maybe he meant he didn't have an earlier build to test against, I'm not
sure. Without the patch, though, my builds were failing. BTW, I'm
building the i386-pc-solaris2.10 binary on an 11/06 Solaris 10 release,
and the sparc-sun-solaris2.10 build is on the 11/06 Solaris 10 release
as well.
Art Haas
.
>
> Dennis
I'm building the GCC trunk, and I've locally applied the patches by
Rainer Orth to fix an issue my builds stumbled over back in July.
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01981.html
Since I'm posting to the mailing list, let me 'ping' this patch.
Art Haas
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 land
/libstdc++-v3/include/mutex:
In constructor 'std::once_flag::once_flag()':
/export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
make[4]: *** [mutex.lo] Error 1
Art Haas
r: request for
implicit
conversion from 'void *' to 'caddr_t' not permitted in C++
make[3]: *** [ggc-common.o] Error 1
The build also failed on my sparc-sun-solaris2.10 system.
The mmap()/munmap() calls in these functions are the cause of the
problem.
Art Haas
On Thu, 2008-05-22 at 21:12, Kai Tietz wrote:
> Art,
>
> 2008/5/22 Art Haas <[EMAIL PROTECTED]>:
> >
> > On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
> >> Ok, fixed on gcc trunk revision 135776.
> >
> > The patch fixed the warning error, but the
ror:
'return_in_memory_32' defined but not used
/export/home/arth/gnu/gcc.git/gcc/config/i386/i386.c:4892: error:
'return_in_memory_ms_64' defined but not used
make[3]: *** [i386.o] Error 1
make[3]: *** Waiting for unfinished jobs
{ ... snip end of log ... }
Art Haas
In file included from ./tm.h:18,
from /export/home/arth/gnu/gcc.git/gcc/gensupport.c:24:
/export/home/arth/gnu/gcc.git/gcc/config/i386/sysv4.h:28:1: error: this
is the location of the previous definition
make[3]: *** [build/gensupport.o] Error 1
make[3]: *** Waiting for unfinished jobs
{ ... snip ...}
Art Haas
e
current code.
Anyone else seeing this failure?
--
Art Haas
Software Developer
ImpactWeather, Inc.
http://www.impactweather.com
Your Weather Department
e (latent?) bug somewhere ...
Art Haas
x27;gcc -v' output above. I get the tree via the mercurial-repo mirror
and my last pull was an hour or so ago, with 'hg tip' saying the latest
patch was from Paul Thomas on the 'gfortran.dg/char_length_10.f90' file.
Art Haas
/export/home/arth/gnu/gcc-0807/./gcc/crtbegin.o
ld: fatal: relocations remain against allocatable but non-writable sections
[ ... snip end of log ... ]
Art Haas
objdir-0216'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/usr/src/gcc_svn/objdir-0216'
make: *** [bootstrap-lean] Error 2
$
A temporary workaround is to build with '--disable-werror'.
Art Haas
--
Man once surrendering his reason, has no remaining guard agai
essfully. The Athlon box has 1G of physical
memory, where the rawhide machine has 256M with 1G swap and my Debian
box has 128M with 100M swap. My most recent build attempt was last
night on the Debian box, and the failure above comes from that build.
Anyone else seeing similar failures? Any ideas
ce to `vec_gc_p_reserve'
collect2: ld returned 1 exit status
make[3]: *** [build/genconstants] Error 1
make[3]: Leaving directory `/usr/src/gcc_svn/objdir-0513/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/src/gcc_svn/objdir-0513'
make[1]: *** [stage1-b
;s patchset that revamped
the build to use BASE-VER, DATESTAMP, and DEV-PHASE files is likely to
have made this (unanticipated?) change.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of ever
33 matches
Mail list logo
