RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
Hi Maciej, Thanks for the update. I've read through the whole proposal again and it looks good. I'd like to discuss legacy objects a bit more though... Maciej Rozycki writes: > 3.4 Relocatable Object Generation > > Tools that produce relocatable objects such as the assembler shall > always produce a SHT_MIPS_ABIFLAGS section according to the IEEE Std 754 > compliance mode selected. In the absence of any explicit user > instructions the `strict' mode shall be assumed. No new `legacy' > objects shall be produced. Is it necessary to say that no new legacy objects can be created? I think there is value in still being able to generate legacy objects because of the fact that strict executables leave no room for override at runtime. Apart from the fact that strict cannot be disabled there is otherwise no difference between legacy and strict compliance modes. I believe the strict option is really intended for conscious use so that programmers who know they need it, can use it. Ordinary users still get the casual safety they need as legacy objects are just as good as strict until overridden. If we lose the ability to override then in some environments we will accumulate lots of needlessly strict executables just because of a tools upgrade whereas the old tools would have generated executables that were as safe but also could be overridden by kernel options. Allowing legacy objects to be generated may also allow the linkage rules to be tightened. I.e. Forcing a relaxed mode at link time could simply fail if confronted by a strict object instead only allowing legacy objects to be relaxed. A default build of GCC and binutils would therefore still generate legacy objects until someone consciously updated the configure options or used command line options. Thanks, Matthew
Re: Machine constraints list
On 05/08/2016 03:27 PM, David Wohlferd wrote: Looking at the v6 release criteria (https://gcc.gnu.org/gcc-6/criteria.html) there are about a dozen supported platforms. Looking at the Machine Constraints docs (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there are 34 architectures listed. That's a lot of entries to scroll thru. If these architectures aren't supported anymore, is it time to drop some of these from this page? I don't believe that the listing of Primary or Secondary Platforms should be considered an exhaustive list of the supported architectures. As a first pass, maybe something like this: ... > Drop ... MicroBlaze—config/microblaze/constraints.md MicroBlaze should continue to be supported. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
my student enjoyed your page
Hello, My name is Jessica Lowe, I am a middle school teacher in Colorado. I have been working with a student of mine who is interested in learning more about computer coding and programming. I was doing some research and finding some sources for him, and I found your page https://gcc.gnu.org/readings.html to be very helpful and informative, and wanted to thank you. I also came across this article http://ithare.com/a-beginners-guide-to-programming-languages/ about programming for beginners, and I thought it was a great starting point for Jason, my student, or anyone who is interested in learning more about computer programming and coding. I thought it would be great to add to your resources so others could have access to it. Thanks again for all of the great information, Myself and Jason both really appreciate it. It definitely has put him in the right direction in advancing towards a potential career in this field. Have a great day and please let me know if you are able to add the article, I would love to show Jason and know we were able to contribute something! Best Wishes Jessica Lowe jess...@mrslowe.com
Successful bootstrap and install of gcc (GCC) 6.1.0 on armv5tel-unknown-linux-gnueabi
Hi, Here's a report of a successful build and install of GCC: $ gcc-6.1.0/config.guess armv5tel-unknown-linux-gnueabi $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/mnt/gcctest/newcompiler/libexec/gcc/arm-unknown-linux-gnueabi/6.1.0/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: ../gcc-6.1.0/configure --with-arch=armv4t --with-float=soft --disable-nls --prefix=/mnt/gcctest/newcompiler --enable-languages=c,c++ --host=arm-unknown-linux-gnueabi --build=arm-unknown-linux-gnueabi --target=arm-unknown-linux-gnueabi --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 6.1.0 (GCC) -- Build environment -- host: openrd-client distro: los.git rootfs=71e48 native=71e48 kernel: Linux 4.6.0-rc5-mvebu-los_71e48 binutils: GNU binutils 2.26.20160125 make: GNU Make 4.1 libc: GNU C Library (GNU libc) stable release version 2.23 zlib: 1.2.8 mpfr: 3.1.3 gmp: 6 -- Time consumed -- configure: real0m 29.17s user0m 19.98s sys 0m 1.70s bootstrap: real33h 31m 03s user32h 13m 26s sys 32m 6.62s install:real3m 47.36s user2m 30.66s sys 0m 20.19s -- Hardware details --- MemTotal: 513148 kB processor : 0 model name : Feroceon 88FR131 rev 1 (v5l) BogoMIPS: 1196.85 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: Marvell Kirkwood (Flattened Device Tree) Revision: Serial : A.
Re: (R5900) Implementing Vector Support
On 05/15/2016 03:43 AM, Woon yung Liu wrote: testv.c:70:2: note: ==> examining statement: _5 = (int) _4; You need to implement the vec_unpack* patterns. But how can I tell what operations are required by autovectorization, that are currently not supported? Well, the dumps you're looking at are the start. But it also requires that you look through tree-vect-stmts.c. My port is still missing the instructions for initializing vectors, and inserting/setting and extracting values from vectors. They aren't implemented yet because I haven't figured out how to implement them; the documentation describes them as simple operations, but yet the implementations within mips.c do a lot more things! Efficient vector initialization requires that we detect some common cases. We do that before the fully general mips_expand_vi_general. r~
Re: (R5900) Implementing Vector Support
On 05/14/2016 03:21 AM, Woon yung Liu wrote: The current constraints allow GCC to access the 64-bit LO+HI register pair as a single 128-bit register, so I am cheating by using both the x and wr (new constraint for LO1+HI1) constraints. That doesn't seem right. The x constrant is for the hi/lo pair, whatever size it is. You should be able to use that just fine with a 256 bit mode. r~
ARM gold unknown option.
Hi All , We are migrating to the gold linker and see the below issue bash-4.1$ /auto/compiler-migration/bin/armeb-linux-gnueabi-ld.gold --be8 /auto/compiler-migration/bin/armeb-linux-gnueabi-ld.gold: --be8: unknown option Any help ,will be appreciated . Thank you ~Umesh
