Successful bootstrap and install of gcc (GCC) 6.2.0 on hppa2.0-unknown-linux-gnu
Hi, Here's a report of a successful build and install of GCC: $ gcc-6.2.0/config.guess hppa2.0-unknown-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/hppa-unknown-linux-gnu/6.2.0/lto-wrapper Target: hppa-unknown-linux-gnu Configured with: ../gcc-6.2.0/configure --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=hppa-unknown-linux-gnu --build=hppa-unknown-linux-gnu --target=hppa-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 6.2.0 (GCC) -- Build environment -- host: hp-c3700 distro: los.git rootfs=ff90d27 native=ff90d27 kernel: Linux 4.8.0-rc6-los_ff90d27 binutils: GNU binutils 2.27 make: GNU Make 4.1 libc: GNU C Library (GNU libc) stable release version 2.24 zlib: mpfr: 3.1.3 gmp: 6 -- Time consumed -- configure: real0m 29.10s user0m 11.35s sys 0m 8.79s bootstrap: real20h 37m 11s user19h 23m 13s sys 1h 0m 25s install:real1m 35.50s user0m 28.22s sys 0m 39.01s -- Hardware details --- MemTotal: 2070828 kB processor : 0 cpu family : PA-RISC 2.0 cpu : PA8700 (PCX-W2) cpu MHz : 750.00 capabilities: os32 os64 iopdir_fdc nva_supported (0x07) model : 9000/785/C3700 model name : Allegro W2 hversion: 0x5dc0 sversion: 0x0481 I-cache : 768 KB D-cache : 1536 KB (WB, direct mapped) ITLB entries: 240 DTLB entries: 240 - shared with ITLB bogomips: 1495.85 software id : 2004755634 A.
gcc-7-20160918 is now available
Snapshot gcc-7-20160918 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20160918/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 240221 You'll find: gcc-7-20160918.tar.bz2 Complete GCC MD5=80448be53a89b9c3b5efad3c01f7bc38 SHA1=4fdc18d91c9502647bafa11fc1adb09272cd9618 Diffs from 7-20160911 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Unable to access fields of a record type in some cases
Hello, We want to fetch fields of a record type from the formal arguments of a function. For a RECORD_TYPE, we fetch the fields using TYPE_FIELDS. In the program 471.omnetpp (from the SPEC CPU2006 benchmark suite), we encountered a case where we were not able to access the fields. Below is the dump of the same record type showing different output in different functions. We are not able to access fields of the record type for the first case. Can you tell us the reason for different type nodes? Also can you suggest an approach to solve our problem. --- Pointer declared as "struct cMessage *" is a parameter in one function. Below is the dump of node "struct cMessage *". align 8 symtab 0 alias set -1 canonical type 0x2b8faa800690 context pointer_to_this chain 0x2b8fad7b3730 cMessage>> unsigned DI size bitsizetype> constant 64> unit size 0x2b8faa6d2000 sizetype> constant 8> align 64 symtab 0 alias set -1 canonical type 0x2b8faa800e70 pointer_to_this > Another pointer also declared as "struct cMessage *" is a parameter in second function. Below is the dump of node "struct cMessage *". type needs-constructing BLK size unit size align 64 symtab 0 alias set -1 canonical type 0x2b8faa834c78 fields 0x2b8faa819150 cObject> ignored BLK file omnet_include/cmessage.h line 84 col 15 size unit size align 64 offset_align 128 offset bit offset context chain swati_test>> context pointer_to_this reference_to_this chain cMessage>> public unsigned DI size bitsizetype> constant 64> unit size 0x2b8faa6d2000 sizetype> constant 8> align 64 symtab 0 alias set -1 canonical type 0x2b8faa800e70 pointer_to_this > --- Thank you. Regards, Swati
