Re: How to avoid constant propagation into functions?
On Wed, Dec 7, 2016 at 7:04 PM, Alexander Monakov wrote: > On Wed, 7 Dec 2016, Richard Biener wrote: >> >Agreed, that's what I've been using in the past for glibc test cases. >> > >> >If that doesn't work, we'll need something else. Separate compilation >> >of test cases just to thwart compiler optimizations is a significant >> >burden, and will stop working once we have LTO anyway. >> > >> >What about making the function definitions weak? Would that be more >> >reliable? >> >> Adding attribute((used)) should do the trick. It introduces unknown callers >> and thus without cloning disables IPA. > > Hm, depending on the case I think this may be not enough: it thwarts IPA on > the > callee side, but still allows the compiler to optimize the caller: for > example, > deduce that callee is pure/const (in which case optimizations in the caller > may > cause it to be called fewer times than intended or never at all), apply > IPA-RA, or > (perhaps in future) deduce that the callee always returns non-NULL and > optimize > the caller accordingly. I think attribute-weak works to suppress IPA on the > caller side, but that is not a good solution because it also has an effect on > linking semantics, may be not available on non-ELF platforms, etc. Right, 'used' thwarts IPA on the callee side only. noclone and noinline are attributes affecting the caller side but we indeed miss attributes for the properties you mention above. I suppose adding a catch-all attribute for caller side effects (like we have 'used' for the callee side) would be a good idea. Richard. > > Alexander
Re: GCC Subversion tree conflicts
On 8 December 2016 at 22:05, Ethin Probst wrote: > As I do not know how to fix these other than to resolve them, I have > done so, You haven't resolved anything, all you've done is *tell* svn that you resolved them, without actually doing so. The files still have conflicts in, and all you've done is tell svn to ignore those conflicts. > and recommend that you run svn up after resolving these > conflicts. I'm not specifically sure in what way these tree conflicts > conflict within the SVN tree or how they have occurred. I am currently > investigating if it was only on my machine that it happened or if it > happens on all machines. I shall examine my SVN tree and notify you > guys if anything comes up. I'm just notifying you in case one of you > can fix the conflict before I discover the reason. I have no idea how > this will affect the GCC compilation process. I'm about to find out > though. Cheers, and wish me 'good luck', as I've figured out that GCC > compilations on the latest SVN build tend to crash the compiler (or > cause internal errors) when compiling the source code at random > points! (Bug, anyone?) These are conflicts between local changes in your copy of the code and the repository, there's nothing wrong with the repo. You can discard all the local changes and get a clean tree by running "svn revert -R ." at the top level of the source tree. As for the crashes, nobody else is seeing that (such bugs get reported and fixed very quickly). You might have faulty hardware, or the changes in your copy of the code (that caused the conflicts) could be causing the crashes.
Re: How to avoid constant propagation into functions?
On Fri, 9 Dec 2016, Richard Biener wrote: > Right, 'used' thwarts IPA on the callee side only. noclone and noinline are > attributes affecting the caller side but we indeed miss attributes for the > properties you mention above. I suppose adding a catch-all attribute for > caller side effects (like we have 'used' for the callee side) would be a good > idea. For general uses, i.e. for testcases that ought to be portable across different compilers, I believe making a call through a volatile pointer already places a sufficient compiler barrier to prevent both caller- and callee-side analysis. That is, where you have int foo(int); foo(arg); you could transform it to int foo(int); int (* volatile vpfoo)(int) = foo; vpfoo(arg); While this also has an effect of forcing the call to be indirect, I think usually that should be acceptable. But for uses in the gcc testsuite, I believe an attribute is still needed. Alexander
Re: BITS_PER_UNIT issue in port....
On 12/08/2016 01:37 PM, Steve Silva wrote: Hi, I was not sure where to look but I thought I would try this. I am in the middle of porting GCC 6.2 to an internal processor we are experimenting with. I have about 2 months into it and I have made some decent progress. The biggest issue I have right now is that our processor does not use 8 bit bytes but 16 bit bytes. When I try and set BITS_PER_UNIT to 16, GCC will not compile because some of its internal structures become too big for the host platform. Our processor only needs to support QI (16 bits) and HI (32 bits) modes; we don't really need anything SI or bigger. I really don't want to hack on the GCC source code unless I am forced to, I would prefer to stay in the machine dependent realm. Also, we are only using the "C" front end. So I have the following questions: 1. Is it possible to set BITS_PER_UNIT to 16 at all? If so, How? I thought we had targets that did this in the past. In theory it should be possible, but it's certainly not something that's done with any regularity or something that is tested. It is highly likely that you'll run into various assumptions throughout GCC that BITS_PER_UNIT is 8. 2. Is there a minimum number of registers GCC has to have to work correctly? What is that minimum? It depends on the structure of your register file. If (for example) you have address and data registers, you'll likely need at least 4 address registers (stack pointer, frame pointer, 2 for the compiler to use in code generation). You'll likely need 2-4 data registers. If you have general purpose registers, then ~6 ought to work (frame pointer, stack pointer, 4 for code generation. To some degree this will depend on things like your ABI, whether or not you have registers that have specialized uses, etc. Folks have done ports on more constrained targets. If you have zero page addressing, you could use zero-page memory locations as an extended register file. Or you could look at the rl78 port which defines a set of virtual registers, then packs those down to the even more limited processor registers. jeff
Re: strange test failures
On 12/08/2016 05:32 PM, Jeff Law wrote:
On 12/08/2016 04:47 PM, Martin Sebor wrote:
I'm seeing failures in a few C tests that I'm not sure what to make
out of. The tests fail due to undefined symbols while linking even
though they're not meant to link. Among these are a number (but not
all) of the gcc.dg/divmod-[1-6]{-simode}.c tests.
FAIL: gcc.dg/divmod-1.c (test for excess errors)
The log shows that they are being built without the -S option:
spawn -ignore SIGHUP /opt/notnfs/msebor/build/gcc-78622/gcc/xgcc
-B/opt/notnfs/msebor/build/gcc-78622/gcc/
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.dg/divmod-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-fdump-tree-widening_mul-details -lm -o ./divmod-1.exe
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
...
When I run make check-c I get these same failures in different tests.
In successful builds the logs show that the tests are only assembled
(i.e., compiled with -S), never linked.
I can reproduce this on two different x86_64 machines but so far
only with my patches to GCC (the middle end but none of these tests
or the GCC .exp files). Is it possible that somehow my changes cause
this? (The removal of the -S option.) Am I missing something about
how GCC tests are run?
IIRC the default for a dg test is to compile, but not assemble or run.
The log shows that it's trying to go through the link step.
Thanks
Martin
PS I also see other strange errors like
RROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/execute.exp.
ERROR: unmatched open brace in list
ERROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp.
ERROR: torture-init: torture_without_loops is not empty as expected
This all sounds like you've got a mucked up testsuite/lib directory or
something like that. I'd start by verifying the contents of your
testsuite/lib directory.
I did a testrun on Dec 7 on the trunk and didn't see any of these problems.
I've confirmed by recreating the tree and re-running bootstrap
and the C tests (make check-c) that it's the patch that's causing
it. I just don't know yet how it's possible.
Martin
Java language not being included as a possible language in --enable-languages argument to configure?
I'm trying to run the GCC configure script with: [configure input] ~/gcc/configure --disable-nls --enable-gold=yes --enable-libquadmath --enable-libquadmath-support --enable-libada --enable-libssp --enable-libcxx --enable-liboffloadmic=target --enable-bootstrap --enable-lto --enable-static-libjava --enable-languages=ada,c,c++,fortran,go,java,jit,objc,obj-c++ --enable-objc-gc --enable-vtable-verify --enable-host-shared --quiet [end configure input] But configure returns: [configure output] configure: WARNING: using in-tree isl, disabling version check configure: error: The following requested languages could not be built: java Supported languages are: c,ada,c,c++,fortran,go,jit,lto,objc,obj-c++ [end configure output] (I don't know why 'c' is in there twice, but it is.) Running configure without --quiet returns: [configure output] checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libcilkrts support... yes checking for liboffloadmic support... yes checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... yes checking for libmpx support... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check configure: error: The following requested languages could not be built: java Supported languages are: c,ada,c,c++,fortran,go,jit,lto,objc,obj-c++ [end configure output] Anyone have any ideas? Libjava is in there and everything. Do I need to have gcj installed prior to building gcj like I need GNAT? -- Signed, Ethin D. Probst
Re: Java language not being included as a possible language in --enable-languages argument to configure?
On Fri, Dec 9, 2016 at 6:53 PM, Ethin Probst wrote: > I'm trying to run the GCC configure script with: > [configure input] > ~/gcc/configure --disable-nls --enable-gold=yes --enable-libquadmath > --enable-libquadmath-support --enable-libada --enable-libssp > --enable-libcxx --enable-liboffloadmic=target --enable-bootstrap > --enable-lto --enable-static-libjava > --enable-languages=ada,c,c++,fortran,go,java,jit,objc,obj-c++ > --enable-objc-gc --enable-vtable-verify --enable-host-shared --quiet > [end configure input] > But configure returns: > [configure output] > configure: WARNING: using in-tree isl, disabling version check > configure: error: > The following requested languages could not be built: java > Supported languages are: c,ada,c,c++,fortran,go,jit,lto,objc,obj-c++ > [end configure output] > (I don't know why 'c' is in there twice, but it is.) > Running configure without --quiet returns: > [configure output] > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... x86_64-pc-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking whether ln works... yes > checking whether ln -s works... yes > checking for a sed that does not truncate output... /bin/sed > checking for gawk... gawk > checking for libatomic support... yes > checking for libcilkrts support... yes > checking for liboffloadmic support... yes > checking for libitm support... yes > checking for libsanitizer support... yes > checking for libvtv support... yes > checking for libmpx support... yes > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking whether g++ accepts -static-libstdc++ -static-libgcc... yes > checking for gnatbind... gnatbind > checking for gnatmake... gnatmake > checking whether compiler driver understands Ada... yes > checking how to compare bootstrapped objects... cmp > --ignore-initial=16 $$f1 $$f2 > checking for objdir... .libs > configure: WARNING: using in-tree isl, disabling version check > configure: error: > The following requested languages could not be built: java > Supported languages are: c,ada,c,c++,fortran,go,jit,lto,objc,obj-c++ > [end configure output] > Anyone have any ideas? Libjava is in there and everything. Do I need > to have gcj installed prior to building gcj like I need GNAT? What version of GCC? Is this trunk? If so java was removed a few months ago. Thanks, Andrew > > -- > Signed, > Ethin D. Probst
