Re: combination of read/write and earlyclobber constraint modifier
On Wed, 2 Jul 2014, Tom de Vries wrote: On 02-07-14 08:23, Marc Glisse wrote: I think it could have used (match_dup 0) instead of operand 1, if there had been only the first alternative. And then the constraint would have been +&. isn't that explicitly listed as unsupported here ( https://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html#index-match_005fdup-3244 ): ... Note that match_dup should not be used to tell the compiler that a particular register is being used for two operands (example: add that adds one register to another; the second register is both an input operand and the output operand). Use a matching constraint (see Simple Constraints) for those. match_dup is for the cases where one operand is used in two places in the template, such as an instruction that computes both a quotient and a remainder, where the opcode takes two input operands but the RTL template has to refer to each of those twice; once for the quotient pattern and once for the remainder pattern. ... ? Well, looking for instance at x86_shrd... Ok, I didn't know it wasn't supported (though I did suggest using match_operand and "0" at some point). Still, the meaning of +&, in inline asm for instance, seems relatively clear, no? -- Marc Glisse
Re: combination of read/write and earlyclobber constraint modifier
On 02-07-14 09:02, Marc Glisse wrote: Still, the meaning of +&, in inline asm for instance, seems relatively clear, no? I can't find any testsuite examples using this construct. Furthermore, I'd expect the same semantics and restrictions for constraints in rtl templates and inline asm. So I'm not sure what you mean. Thanks, - Tom
Re: combination of read/write and earlyclobber constraint modifier
On Wed, 2 Jul 2014, Tom de Vries wrote: On 02-07-14 09:02, Marc Glisse wrote: Still, the meaning of +&, in inline asm for instance, seems relatively clear, no? I can't find any testsuite examples using this construct. Furthermore, I'd expect the same semantics and restrictions for constraints in rtl templates and inline asm. So I'm not sure what you mean. Coming back to your original question: An earlyclobber operand is defined as 'modified before the instruction is finished using the input operands'. AFAIU that would indeed exclude the possibility that the earlyclobber operand is an input/output operand it self, but perhaps I misunderstand. So my question is: is the combination of '&' and '+' supported ? If so, what is the exact semantics ? If not, should we warn or give an error ? An earlyclobber operand X prevents *other* input operands from using the same register, but that does not include X itself (if it is using +) or operands explicitly using a matching constraint for X. At least that's how I understand it. -- Marc Glisse
[ANN] CppCon 2014 program available
The CppCon 2014 Program is now available with talk titles, abstracts, and speakers: http://cppcon.org/conference-program/ The program contains over 100 one-hour sessions by over 70 speakers including plenary sessions by Scott Meyers and Herb Sutter, as well as the keynotes by C++ creator Bjarne Stroustrup on Keeping Simple Things Simple and Mark Maimone on using C++ on Mars: Incorporating C++ into Mars Rover Flight Software. We have also extended the Early Bird deadline to July 9 so you have a week to study the program and still get the Early Bird rate. Hope to see you in Bellevue! Boris
Re: combination of read/write and earlyclobber constraint modifier
On 02-07-14 11:36, Marc Glisse wrote: (did you drop the lists on purpose?) That was a glitch, sorry. [ Adds list back ] Thanks, - Tom On Wed, 2 Jul 2014, Tom de Vries wrote: An earlyclobber operand X prevents *other* input operands from using the same register, but that does not include X itself (if it is using +) or operands explicitly using a matching constraint for X. At least that's how I understand it. Right, that's another interpretation, which would require a clarification in the documentation Sure, improving the doc is always good. I'm fine with either forbidding &= (as proposed here: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00094.html ) or clarifying the semantics in the documentation. + is essentially a shortcut for = with a matching constraint in the input operand, so I don't think it is the right level to forbid anything.
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On Tue, Jul 01, 2014 at 10:40:06AM +0200, Matthias Klose wrote: > on some linux architectures there are some symbols missing in libstdc++.so.6 > built from the 4.9 branch. I didn't notice before due to a packaging bug. > affected are ARM32, HPPA, SPARC. > > - ARM32 (build log [1], both soft and hard float) are missing > __aeabi_atexit@CXXABI_ARM_1.3.3 > __aeabi_vec_* > >Can these be ignored? > > - HPPA (build log [2]), is missing all the future_base symbols and >exception_ptr13exception symbols, current_exception and >rethrow_exception. > > - SPARC (build log [3]) configured for sparc64-linux-gnu is missing >symbols in the 32bit multilib build, although these are present >in a sparc-linux-gnu build. Missing are same ones as in the HPPA >build, long double 128 related symbols, numeric_limits, and some >math symbols. > >Looks like more than one issue is involved, I remember that the >math symbols were already dropped in earlier versions for other >architectures. The build is configured -with-long-double-128. > I think that for sparc long double issue, the problem is that -with-long-double-128 doesn't work as -mlong-double-64 is forced when -m32 is used. I sent a patch a few months ago [1], but it has some side effect and I never came to a better version. Any help on how to do that properly is welcome, and I can build test some patches if needed. [1] https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: combination of read/write and earlyclobber constraint modifier
On 2 July 2014 08:02, Marc Glisse wrote: > On Wed, 2 Jul 2014, Tom de Vries wrote: > >> On 02-07-14 08:23, Marc Glisse wrote: >>> >>> I think it could have used (match_dup 0) instead of operand 1, if there >>> had been only the first alternative. And then the constraint would have been >>> +&. >> >> >> isn't that explicitly listed as unsupported here ( >> https://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html#index-match_005fdup-3244 >> ): >> ... >> Note that match_dup should not be used to tell the compiler that a >> particular register is being used for two operands (example: add that adds >> one register to another; the second register is both an input operand and >> the output operand). Use a matching constraint (see Simple Constraints) for >> those. match_dup is for the cases where one operand is used in two places in >> the template, such as an instruction that computes both a quotient and a >> remainder, where the opcode takes two input operands but the RTL template >> has to refer to each of those twice; once for the quotient pattern and once >> for the remainder pattern. Note that this uses 'should', not must. That's a shorthand that, in general, you shouldn't do that, although there can be special circumstances where it is valid. The distinction between multiple operands vs. single operands that appears multiple times in the RTL is not even something that makes sense in the framework that the register allocators operate in. Although you'd be well-advised not to use match_dup in your add pattern, because reload needs to generate adds in some circumstances, and it has specific requirements there. The long explanation is that the matching constraint allows the register allocators / reload to fix up the operands to match, so if you want the pattern to be used to implement this operation, and you don't mind some reg-reg moves to be used if that's what it takes, you should use a matching constraint. If, on the other hand, you have a pattern of marginal utiliy, that is not worth the trouble of doing extra reg-reg copies to utilize, a match_dup is better. Such patterns are not all that likely to be recognized by simple matching/combining, but you can generate then in expanders/splitters/peephole2s.
Re: combination of read/write and earlyclobber constraint modifier
On 2014-07-01, 3:27 PM, Tom de Vries wrote: Vladimir, There are a few patterns which use both the read/write constraint modifier (+) and the earlyclobber constraint modifier (&): So my question is: is the combination of '&' and '+' supported ? If so, what is the exact semantics ? If not, should we warn or give an error ? 1. yes, it is a valid combination for LRA. 2. With the point of view satisfying insn constraints, there is no difference with =&, but as operand with +& is treated as input/output and one with =& only as output, it might results in different reload insns when the insn constraints are not satisfied. Although it is hard for me to say exactly what the difference could be as it is too complicated. Also using +& instead of &= might result in different reg costs and different results in IRA (global RA) and even in register-pressure sensitive insn scheduler, and in loop invariant motion. 3. So it is hard for me to say about usefulness of such construction with LRA point of view or should we give a warn or an error. Probably there is small usefulness of +& as it is very hard to describe what the difference in comparison with '=&' will be for GCC developer or user.
Re: combination of read/write and earlyclobber constraint modifier
On 07/01/14 13:58, Marc Glisse wrote: I don't think we can define any reasonable semantics for &+. My recommendation would be for this to be considered a hard error. Uh? The doc explicitly says "An input operand can be tied to an earlyclobber operand" and goes on to explain why that is useful. It avoids using the same register for other input when they are identical. Nothing like making a statement on the internet to bring out folks more "in the know" to refute what was said :-) Reviewing that paragraph, it does sound vaguely familiar. So the backend developer explicitly ties the input to an earlyclobbered output and the other inputs are marked as conflicting. I guess I can see how that is helpful, though I wonder how often it is helpful in practice. Regardless, I stand corrected :-) jeff
Re: combination of read/write and earlyclobber constraint modifier
On 07/02/14 00:23, Marc Glisse wrote: On Tue, 1 Jul 2014, Tom de Vries wrote: On 01-07-14 21:58, Marc Glisse wrote: So my question is: is the combination of '&' and '+' supported ? If so, what is the exact semantics ? If not, should we warn or give an error ? I don't think we can define any reasonable semantics for &+. My recommendation would be for this to be considered a hard error. Uh? The doc explicitly says "An input operand can be tied to an earlyclobber operand" and goes on to explain why that is useful. It avoids using the same register for other input when they are identical. Hi Marc, That part of the doc refers to the mulsi3 insn for ARM as example: ... ;; Use `&' and then `0' to prevent the operands 0 and 1 being the same (define_insn "*arm_mulsi3" [(set (match_operand:SI 0 "s_register_operand" "=&r,&r") (mult:SI (match_operand:SI 2 "s_register_operand" "r,r") (match_operand:SI 1 "s_register_operand" "%0,r")))] "TARGET_32BIT && !arm_arch6" "mul%?\\t%0, %2, %1" [(set_attr "type" "mul") (set_attr "predicable" "yes")] ) ... Note that there's no combination of & and + here. I think it could have used (match_dup 0) instead of operand 1, if there had been only the first alternative. And then the constraint would have been +&. Note carefully that match_dup requires the exact same operand or the insn will not be recognized. A matching constraint allows different pseudos and relies upon the register allocator to assign the different pseudos to the same hard register. (by the way, in the same aarch64-simd.md file, I noticed some define_expand with constraints, that looks strange) It sometimes happens when a define_insn is converted into a define_expand -- folks just forget to remove the pointless constraints. jeff
New French mirror
Hi, I have set up a French gcc mirror. It is located in Roubaix, France. It is reachable through http, ftp and rsync: http://mirror.bbln.nl/gcc ftp://mirror.bbln.nl/gcc rsync://mirror.bbln.nl/gcc This mirror is provided by BBLN. Could you add it to the mirrorlist? If you have any questions please let me know! Best regards, Tim Semeijn BBLN
Identify IEE
I’ve recently added IEEE support for the Fortran front-end and library. As part
of that, the front-end should be able to determine which of the available
floating-point types are IEEE-conforming [1]. Right now, I’ve taken a
conservative approach and only considered the target’s float_type_node and
double_type_node as IEEE modes, but I’d like to improve that (for example, to
include long double and binary128 modes on x86).
How can I determine, from a “struct real_format”, whether it is an IEEE format
or not? I’ve looked through gcc/real.{h,c} but could find no clear solution. If
there is none, would it be okay to add a new bool field to the structure, named
“ieee” or “ieee_format”, to discriminate?
Thanks,
FX
[1] The Fortran standard defines such as types as having an "IEC 60559:1989
floating-point format”. Decimal formats are out, as they are unsupported in
gfortran, so I guess this definition covers binary16 to binary128, as well as
extended and extendable precision formats.
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1-Jul-14, at 4:40 AM, Matthias Klose wrote: Looks like more than one issue is involved, I remember that the math symbols were already dropped in earlier versions for other architectures. The build is configured -with-long-double-128. Long double is 64 bits on hppa-linux. Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 01/07/14 20:58, John David Anglin wrote: On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: On 1 July 2014 09:40, Matthias Klose wrote: - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and exception_ptr implementations rely on usable atomics. ARM and HPPA use kernel assisted libraries for atomic support. Not exactly lock free, but possibly good enough... Currently, c-cppbuiltin.c doesn't provide proper defines for this support. We currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. We then need to do the same on ARM especially for older architectures that don't have these sync patterns. Ramana Thanks, Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 01/07/14 09:40, Matthias Klose wrote: on some linux architectures there are some symbols missing in libstdc++.so.6 built from the 4.9 branch. I didn't notice before due to a packaging bug. affected are ARM32, HPPA, SPARC. - ARM32 (build log [1], both soft and hard float) are missing __aeabi_atexit@CXXABI_ARM_1.3.3 __aeabi_vec_* Can these be ignored? __aeabi_atexit is the function to be used instead of __cxa_atexit for the arm-none-linux-gnueabi(hf) targets as well as arm-none-eabi. Grokking around libstdc++-v3 I would have expected config/os/gnu-linux/arm-eabi-extra.ver to have added these symbols in and I'm not sure what's going on here. So prima-facie this is a bug. I wonder if something's broken in the handling of port_specific_symbol_files for arm. regards Ramana - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. - SPARC (build log [3]) configured for sparc64-linux-gnu is missing symbols in the 32bit multilib build, although these are present in a sparc-linux-gnu build. Missing are same ones as in the HPPA build, long double 128 related symbols, numeric_limits, and some math symbols. Looks like more than one issue is involved, I remember that the math symbols were already dropped in earlier versions for other architectures. The build is configured -with-long-double-128. Matthias [1] https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9&arch=armhf&ver=4.9.0-8&stamp=1403809654 [2] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=hppa&ver=4.9.0-9&stamp=1404018503 [3] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sparc64&ver=4.9.0-9&stamp=1404033854
gcc-4.9-20140702 is now available
Snapshot gcc-4.9-20140702 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140702/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 212247 You'll find: gcc-4.9-20140702.tar.bz2 Complete GCC MD5=87d4354676a0bf7fa3210800c5bee2aa SHA1=d986aad7a6ff3ecf909de84c9673e3407714343b Diffs from 4.9-20140625 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Fw: Results for 4.8.3 (GCC) testsuite on i686-pc-linux-gnu
Dear GCC Team, As there are no test results listed for GCC 4.8.3 in GCC buildstats/testresults page, I am re-sending the test results as below: Regards, Raghunath Lolur. On Tuesday, 1 July 2014 1:41 AM, Raghu L wrote: Dear GCC Team, I would like to inform a successful native bootstrap build of GCC 4.8.3 toolchain on i686-pc-linux-gnu. The build is performed using combined tree sources of GCC 4.8.3 and binutils-2.24 as described at http[colon][//]raghunathlolur[dot]wordpress[dot]com/2014/06/30/combined-tree-build-of-gcc-binutils-and-libraries/ The build environment and more info on the built GCC toolchain is as below: $ ../combined/config.guess i686-pc-linux-gnu $ /usr/local/gcc-4-8-3/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4-8-3/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4-8-3/libexec/gcc/i686-pc-linux-gnu/4.8.3/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../combined/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/usr/local/gcc-4-8-3 --disable-nls --disable-werror --disable-multilib --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-threads=posix --enable-checking=release --enable-libstdcxx-time --enable-languages=c,c++ Thread model: posix gcc version 4.8.3 (GCC) My Linux distribution info: Ubuntu 12.04.3 LTS Version of the Linux Kernel : $ uname -a Linux linux 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux Version of glibc on my system: $ dpkg -l libc6 Name Version Description ==-==- libc6 2.15-0ubuntu10 Embedded GNU C Library: Shared libraries Run Testsuites : === $ make -j 2 -k check The Test results are as below: LAST_UPDATED: Obtained from SVN: tags/gcc_4_8_3_release revision 210800 Native configuration is i686-pc-linux-gnu === binutils tests === Running target unix === binutils Summary === # of expected passes 94 # of unsupported tests 3 === gas tests === Running target unix === gas Summary === # of expected passes 412 === gcc tests === Running target unix === gcc Summary === # of expected passes 94669 # of expected failures 262 # of unsupported tests 1103 /home/user1/localbuild-gcc-4-8-3/build/gcc/xgcc version 4.8.3 (GCC) === g++ tests === Running target unix FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_HugeMallocTest Ident((char*)malloc(size))[-1] = 0 output pattern test, should match is located 1 bytes to the left of 2726297600-byte === g++ Summary === # of expected passes 53789 # of unexpected failures 1 # of expected failures 292 # of unsupported tests 672 /home/user1/localbuild-gcc-4-8-3/build/gcc/testsuite/g++/../../xg++ version 4.8.3 (GCC) === libatomic tests === Running target unix === libatomic Summary === # of expected passes 44 # of unsupported tests 5 === libgomp tests === Running target unix === libgomp Summary === # of expected passes 1366 === libitm tests === Running target unix === libitm Summary === # of expected passes 26 # of expected failures 3 # of unsupported tests 1 === libmudflap tests === Running target unix FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test === libmudflap Summary === # of expected passes 1433 # of unexpected failures 3 === libstdc++ tests === Running target unix === libstdc++ Summary === # of expected passes 8687 # of expected failures 45 # of unsupported tests 522 === ld tests === Running target unix === ld Summary === # of expected passes 924 # of expected failures 4 # of untested testcases 1 Compiler version: 4.8.3 (GCC) Platform: i686-pc-linux-gnu configure flags: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/usr/local/gcc-4-8-3 --disable-nls --disable-werror --disable-multilib --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-threads=posix --enable-checking=release --enable-libstdcxx-time --enable-languages=c,c++ EOF Best Regards, Raghunath Lolur.
