Re: resurrecting automatic dependencies
Tom> There may be more missing dependencies. Please try out this branch if Tom> you would. You can report bugs to me, just send the build log. I tried -j33 on a bigger machine and found a problem with Go. The dependency patch uses the language Makefile conventions to add some order-only dependencies to ensure that generated files are made early enough (this code is actually already in gcc, but it has some latent bugs). In particular it uses the $(lang)_OBJS variable (via ALL_HOST_OBJS). However, Go does not set go_OBJS, so a sufficiently large -j setting will cause a build failure, as a Go file is compiled before a generated header. Fixing this is simple enough in go/Make-lang.in; but this also has the side effect of defining IN_GCC_FRONT_END for the various Go compilations: $(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += -DIN_GCC_FRONTEND)) ... which causes build failures for go-backend.c (uses rtl.h) and go-lang.c (uses except.h), since with this defined, certain headers are prohibited. A short term solution is to keep Go using explicit dependencies. For a long term solution ... well, I'm CCing Ian. The except.h doesn't seem to be needed. At least, I removed the include and go-lang.c still compiled. The go-backend.c problem looks harder, though. Thoughts? Tom
if_then_else usage in attribute computation
Hi, Recently I found a weird behavior in attribute computation when if_then_else is used. It may be easily demonstrated on i386 jump instruction. It's original length attribute definition is following: (set (attr "length") (if_then_else (and (ge (minus (match_dup 0) (pc)) (const_int -126)) (lt (minus (match_dup 0) (pc)) (const_int 128))) (const_int 2) (const_int 5))) I change it keeping the same resulting values: (set (attr "length") (if_then_else (and (ge (minus (match_dup 0) (pc)) (const_int -126)) (lt (minus (match_dup 0) (pc)) (const_int 128))) (plus (const_int 2) (const_int 0)) (plus (const_int 5) (const_int 0 After that change I see in assembler: jmp .L2 # 412 jump[length = 2147483647] It also causes fails in make check because some optimizations work in a different way when size changes. I tried to debug it and found that insn_current_length function always return correct values when called for jump insn. Seems problem always occurs when 'if_then_else' or 'cond' is combined with 'plus'. Is such combination supposed to work? Thanks, Ilya
Strange optimization in GCC 4.7.2
Hi,
Simple code:
void somehowuse(unsigned value);
void
foo( unsigned value,
unsigned bytemask,
unsigned psw,
unsigned y)
{
unsigned x;
psw = (psw & ~(1 << 10)) | (((value >> 9) & 1) << 10);
x = (y & ~(1 << 7)) | (((value >> 9) & 1) << 7);
somehowuse(x);
somehowuse(psw);
}
Compile to assembler with gcc-4.7.2:
$ gcc -O1 -fomit-frame-pointer -S test.c -fdump-tree-all-lineno-details
Look at test.c.003t.original
unsigned int x;
psw = psw & 4294966271 | (value >> 9 & 1) << 10;
x = y & 4294967167 | (value >> 9) << 7 & 255; <- WAT?
somehowuse (x);
somehowuse (psw);
}
I can not understand origins of 255 bitmask here. Maybe someone can
explain? Why psw is ok and x is so spoiled?
---
With best regards, Konstantin
Re: Strange optimization in GCC 4.7.2
Konstantin Vladimirov wrote: [...] > x = (y & ~(1 << 7)) | (((value >> 9) & 1) << 7); [...] > x = y & 4294967167 | (value >> 9) << 7 & 255; <- WAT? ((value >> 9) & 1) << 7 == ((value >> 9) << 7) & (1 << 7) == ((value >> 9) << 7) & 0x80 == ((value >> 9) << 7) & 0xff ...I think. That last step is probably being done because anding with 0xff is really cheap on x86 (you just pick the appropriate subreg --- al instead of eax, for example). -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "USER'S MANUAL VERSION 1.0: The information presented in this │ publication has been carefully for reliability." --- anonymous │ computer hardware manual signature.asc Description: OpenPGP digital signature
Re: Strange optimization in GCC 4.7.2
Hi, But this is awfully wrong. In the general case (value >> 2) & 0xff != (value >> 2) & 0x80 Take value to be 0x3ff for example. Then 0xff != 0x80 itself. This leads to wrong result. --- With best regards, Konstantin On Tue, Jul 23, 2013 at 4:57 PM, David Given wrote: > Konstantin Vladimirov wrote: > [...] >> x = (y & ~(1 << 7)) | (((value >> 9) & 1) << 7); > [...] >> x = y & 4294967167 | (value >> 9) << 7 & 255; <- WAT? > > >((value >> 9) & 1) << 7 > == ((value >> 9) << 7) & (1 << 7) > == ((value >> 9) << 7) & 0x80 > == ((value >> 9) << 7) & 0xff > > ...I think. > > That last step is probably being done because anding with 0xff is really > cheap on x86 (you just pick the appropriate subreg --- al instead of > eax, for example). > > -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ > │ "USER'S MANUAL VERSION 1.0: The information presented in this > │ publication has been carefully for reliability." --- anonymous > │ computer hardware manual >
Re: Strange optimization in GCC 4.7.2
Hi, Disregard my previous message, I got your idea =) When we are shifting right then left, then all bits except 7th will be 0 and andmask may be any, while it contains 0x80. Yes everything is ok here, thanks --- With best regards, Konstantin On Tue, Jul 23, 2013 at 5:05 PM, Konstantin Vladimirov wrote: > Hi, > > But this is awfully wrong. In the general case (value >> 2) & 0xff != > (value >> 2) & 0x80 > > Take value to be 0x3ff for example. Then 0xff != 0x80 itself. This > leads to wrong result. > > --- > With best regards, Konstantin > > On Tue, Jul 23, 2013 at 4:57 PM, David Given wrote: >> Konstantin Vladimirov wrote: >> [...] >>> x = (y & ~(1 << 7)) | (((value >> 9) & 1) << 7); >> [...] >>> x = y & 4294967167 | (value >> 9) << 7 & 255; <- WAT? >> >> >>((value >> 9) & 1) << 7 >> == ((value >> 9) << 7) & (1 << 7) >> == ((value >> 9) << 7) & 0x80 >> == ((value >> 9) << 7) & 0xff >> >> ...I think. >> >> That last step is probably being done because anding with 0xff is really >> cheap on x86 (you just pick the appropriate subreg --- al instead of >> eax, for example). >> >> -- >> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ >> │ "USER'S MANUAL VERSION 1.0: The information presented in this >> │ publication has been carefully for reliability." --- anonymous >> │ computer hardware manual >>
Re: atomic support for LEON3 platform
在 2013-7-23，上午5:54，Eric Botcazou 写道： >> Recently i am working on the atomic support for RTEMS. Our basic idea is to >> integrate the C11 atomic API into RTEMS. we have integrated the >> stdatomic.h into newlib which is used by RTEMS. And when we test the >> atomic ops on LEON3 platform (an important platform for RTEMS to test and >> verify SMP support) it posted that there is no defined functions like >> "__atomic_fetch_add_xx". And this is because of SPARC V7-V8 lacks of >> compare and swap instruction., GCC also does not support those build in >> ops. But for LEON3 it is a special case, it has its own casa instruction >> to support compare_and_swap function. So i wonder whether gcc can consider >> support LEON3 build in atomic ops. > > Sure, patches to that effect are welcome. This will need to be coordinated > with binutils because the assembler will very likely reject the instructions > if it is passed -Av8 as is currently done for LEON/LEON3. As a matter of > fact, > I just installed a patch to add basic LEON3 support on the trunk so almost > everything is already there as far as the compiler is concerned. > Hi Eric, do you mean that you already have a patch to solve this issue which is just not merged to mainline? If yes could you send me your patch and tell me to how enable this feature? Thank you! > -- > Eric Botcazou
Re: Help forging a function_decl
Hi, On Mon, Jul 22, 2013 at 03:17:08PM -0300, Rodolfo Guilherme Wottrich wrote: > Hello, > > Thanks! I had solved the problem some days ago, and it was actually > related to your answer. > First, I hadn't used push_struct_function() to allocate storage for my > new function. > Second, I wasn't calling finish_function() after setting my tree, so > it would not be further compiled (just like your suggestion, since > cgraph_add_new_function is called inside it). As I was inside the > scope of main(), I also needed to save the function context with > push_function_context(), call finish_function() and then pop the > context back. > Third, the flag DECL_EXTERNAL for my function was being set, so even > though my tree was going to be further compiled, the definition for my > function_decl was to be found outside file scope. But you do call cgraph_add_new_function on it as well, right? If not, how is its symbol table node (also called and serving as the call graph node) created? (And BTW, you are hacking on trunk, right? Older versions can be quite a bit different here.) > > Now the problem is solved, but I still face an odd behavior: sometimes > my function is output, sometimes not. Basically 50% of the times I > compile my code, my function is simply not output. What do you mean by "50% of the time?" That you get different results even when you do not change your compiler? That should not happen and means you invoke undefined behavior, most likely depending on some uninitialized stuff (assuming your HW is OK) so you are probably not clearing some allocated structure or something. (Do you know why DECL_EXTERNAL was set? That looks weird). Anyway, my best guess is that your function is removed by symtab_remove_unreachable_nodes in ipa.c. (And now I also see that analyze_functions in cgraphunit.c is also doing its own unreachable node removal, but hopefully runs early enough this should not be your problem.) If your function is static and is not called or referenced from anywhere else, gcc will try to get rid of it. Try setting DECL_PRESERVE_P of your decl (or calling cgraph_mark_force_output_node on its call graph node which is cleaner but should be equivalent for debugging, I suppose). If that helps, this is most likely your problem. > And when I try to > debug gcc with gdb, it always fails. What do you mean? That your function is not output or that you cannot use gdb at all? On Mon, Jul 22, 2013 at 10:27:51PM -0300, Rodolfo Guilherme Wottrich wrote: > I run gcc with -fdump-tree-all-raw and found out that all dumps until > filename.c.013t.cfg are fine, but every time it fails, my function > disappears from filename.c.016t.ompexp onwards. Remembering: I want it > to happen every time there's a #pragma omp parallel in the source, so > I put my implementation right after the end of > c_parser_omp_parallel(), in file c-parser.c. Add -fdump-ipa-all switch and look whether the function appears there. Especially the cgraph dump can usually tell you that a function was removed as unreachable. Grep all dumps for "Reclaiming functions:" and see whether your function is listed. > > Again, thank you for the help. > No worries. And good luck, Martin
Re: atomic support for LEON3 platform
> Hi Eric, do you mean that you already have a patch to solve this issue > which is just not merged to mainline? If yes could you send me your patch > and tell me to how enable this feature? Thank you! No, I only installed a patch on the trunk that adds the basic infrastructure for a LEON3 variant of the compiler (we only had a LEON variant before). The underlying architecture is still a strict V8 so it won't generate 'cas', but it will not be difficult to instruct it to do so once binutils support is there. -- Eric Botcazou
Re: atomic support for LEON3 platform
在 2013-7-23，下午11:31，Eric Botcazou 写道： >> Hi Eric, do you mean that you already have a patch to solve this issue >> which is just not merged to mainline? If yes could you send me your patch >> and tell me to how enable this feature? Thank you! > > No, I only installed a patch on the trunk that adds the basic infrastructure > for a LEON3 variant of the compiler (we only had a LEON variant before). The > underlying architecture is still a strict V8 so it won't generate 'cas', but > it > will not be difficult to instruct it to do so once binutils support is there. > ok, because i am not familiar with compiler implementation. So if you can give me some references i will appreciate you very much. And by the way is there any plan to support this feature in the mainline? Best Regards WeiY > > -- > Eric Botcazou
Re: resurrecting automatic dependencies
On Tue, Jul 23, 2013 at 12:06 AM, Tom Tromey wrote: > > ... which causes build failures for go-backend.c (uses rtl.h) and > go-lang.c (uses except.h), since with this defined, certain headers are > prohibited. > > > A short term solution is to keep Go using explicit dependencies. > > For a long term solution ... well, I'm CCing Ian. > > The except.h doesn't seem to be needed. At least, I removed the include > and go-lang.c still compiled. The go-backend.c problem looks harder, > though. Thoughts? I committed a patch to remove the #include of "except.h" from go-lang.c, so that one is handled. And it turns out that the #include of "rtl.h" in go-backend.c is also no longer necessary, so I removed that one too. So you should be good to go for Go. Ian
Re: Git mirror changes
Jason Merrill a écrit: > I'd like to make some changes to the GCC git-svn mirror. > Specifically, I want to move all the SVN branches from remotes/ into > heads/ and split the subdirectory branches (redhat, google, etc) into > the individual branches. > > Should I leave the SVN branches as they are in remotes/ as well, for > backward compatibility with existing users? FWIW, I'd go ahead and remove the SVN branches from remotes/* because it'll limit confusion (incurred by the apparent duplication of bits) in the future. Furthermore, tt's easy for current users to adapt and consume the bits they want from heads/ anyway. > Do we want to limit creation of non-personal branches via git? What do you mean by "limit" here, in practice? I'd say just documenting that people should favor creating personal branches would be a good start. It's can be very handy for a group of people willing to hack together on a feature to be able to setup a (non-personal) branch into which each member of the group can commit. So limit you are talking about above should be at least flexible enough to enable that, I guess. -- Dodji
RE: Help with using multilib for Cilk Library
> -Original Message- > From: H.J. Lu [mailto:hjl.to...@gmail.com] > Sent: Monday, July 22, 2013 5:08 PM > To: Iyer, Balaji V > Cc: Ian Lance Taylor; gcc@gcc.gnu.org > Subject: Re: Help with using multilib for Cilk Library > > On Mon, Jul 22, 2013 at 9:27 AM, Iyer, Balaji V > wrote: > > > > > >> -Original Message- > >> From: H.J. Lu [mailto:hjl.to...@gmail.com] > >> Sent: Friday, July 19, 2013 6:56 PM > >> To: Iyer, Balaji V > >> Cc: Ian Lance Taylor; gcc@gcc.gnu.org > >> Subject: Re: Help with using multilib for Cilk Library > >> > >> On Fri, Jul 19, 2013 at 3:53 PM, Iyer, Balaji V > >> wrote: > >> > > >> > > >> >> -Original Message- > >> >> From: Ian Lance Taylor [mailto:i...@google.com] > >> >> Sent: Friday, July 19, 2013 6:26 PM > >> >> To: Iyer, Balaji V > >> >> Cc: gcc@gcc.gnu.org > >> >> Subject: Re: Help with using multilib for Cilk Library > >> >> > >> >> On Fri, Jul 19, 2013 at 11:22 AM, Iyer, Balaji V > >> >> > >> wrote: > >> >> > Hello Everyone, > >> >> > I am trying to use Multilib on Cilk Library. I looked at > >> >> > this website > >> >> (http://www.airs.com/ian/configure/configure_8.html) and used > >> >> libsanitizer and libgo as samples to model after. It is currently > >> >> failing with the following error > >> >> message: > >> >> > > >> >> > libtool: link: /export/users/my-files/b-gcc-multilib/./gcc/xg++ > >> >> > - > >> >> B/export/users/my-files/b-gcc-multilib/./gcc/ -nostdinc++ > >> >> -nostdinc++ > >> >> - > >> >> I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32 > >> >> /li > >> >> bstdc++- v3/include/x86_64-unknown-linux-gnu > >> >> -I/export/users/my-files/b-gcc- > >> >> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include - > >> >> I/export/users/my-files/gcc/libstdc++-v3/libsupc++ > >> >> -I/export/users/my- files/gcc/libstdc++-v3/include/backward > >> >> -I/export/users/my-files/gcc/libstdc++- > >> >> v3/testsuite/util > >> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux- > >> >> gnu/32/libstdc++-v3/src > >> >> -L/export/users/my-files/b-gcc-multilib/x86_64- > >> >> unknown-linux-gnu/32/libstdc++-v3/src/.libs > >> >> -B/export/users/my-files/install- > >> >> gcc-multilib/x86_64-unknown-linux-gnu/bin/ > >> >> -B/export/users/my-files/install- > >> >> gcc-multilib/x86_64-unknown-linux-gnu/lib/ -isystem > >> >> /export/users/my- > >> >> files/install-gcc-multilib/x86_64-unknown-linux-gnu/include > >> >> -isystem > >> >> /export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-g > >> >> nu/ > >> >> sys- include -m32 -shared -nostdlib /usr/lib/../lib/crti.o > >> >> /export/users/my-files/b- gcc-multilib/./gcc/32/crtbeginS.o > >> >> .libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk- for.o > >> >> .libs/cilk-abi-vla.o .libs/cilk-abi-vla-internal.o > >> >> .libs/cilk_api.o .libs/cilk_fiber.o .libs/cilk_fiber-unix.o > >> >> .libs/cilk_malloc.o .libs/c_reducers.o .libs/except-gcc.o > >> >> .libs/frame_malloc.o .libs/full_frame.o .libs/global_state.o > >> >> .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o > >> >> .libs/os_mutex-unix.o .libs/os-unix.o .libs/pedigrees.o > >> >> .libs/record-replay.o .libs/reducer_impl.o > >> .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o > >> .libs/stats.o > >> >> .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o > >> >> -Wl,-rpath - > >> >> Wl,/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/ > >> >> lib > >> >> stdc++- v3/src/.libs -Wl,-rpath > >> >> -Wl,/export/users/my-files/install-gcc-multilib/lib/../lib64 > >> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/l > >> >> ibs > >> >> tdc++- v3/src/.libs > >> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux- > >> >> gnu/libstdc++-v3/src -lpthread -ldl > >> >> -L/export/users/my-files/b-gcc- > >> >> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src > >> >> -L/export/users/my- > >> >> files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/ > >> >> .li > >> >> bs - > >> >> L/export/users/my-files/b-gcc-multilib/./gcc/32 -L/lib/../lib > >> >> -L/usr/lib/../lib - L/export/users/my-files/b-gcc-multilib/./gcc > >> >> /export/users/my-files/b-gcc- > >> >> multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++ > >> >> .so -lm -lc > >> - lgcc_s /export/users/my-files/b-gcc-multilib/./gcc/32/crtendS.o > >> >> /usr/lib/../lib/crtn.o -m32 -m32 -Wl,-soname -Wl,libcilkrts.so.5 -o > >> >> .libs/libcilkrts.so.5.0.3511 > >> >> > /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/l > >> >> > ibs > >> >> > tdc > >> >> > ++-v3/src/.libs/libstdc++.so: could not read symbols: File in > >> >> > ++wrong > >> >> > format > >> >> > collect2: error: ld returned 1 exit status > >> >> > make[4]: *** [libcilkrts.la] Error 1 > >> >> > make[4]: Leaving directory > >> >> > `/export/users/my-files/b-gcc-multilib/x86_64- > >> >> unknown-linux-gnu/32/libcilkrts' > >> >> > make[3]: *** [multi-do] Error 1 > >> >> > make[3]: Leaving dire
Re: resurrecting automatic dependencies
> "Ian" == Ian Lance Taylor writes: Ian> So you should be good to go for Go. Thanks. I confirmed it works here. I've merged this and pushed the needed go/Make-lang.in change to my branch and built with a large -j on gcc110 with success. Tom
Re: dejagnu multilib options and dg-{add|additional-}options
On 07/22/2013 02:59 AM, Vidya Praveen wrote:
> Hello,
>
> There are 42 test files (25 under gcc.dg) that specifies
>
> { dg-add-options bind_pic_locally }
>
> in the regression testsuite. The procedure add_options_for_bind_pic_locally
> from lib/target-supports.exp adds -fPIE or -fpie when -fPIC or -fpic is passed
> respectively. But this is added before the dejagnu multilib options are added.
> So when -fPIC is passed as a multilib option, -fPIE will be unset by -fPIC
> (see gcc/common.opt). This should have been the behaviour since the patch
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01026.html that brings all -fPIC
> & -fPIE variants in a Negative loop, was applied.
>
> I tried fixing this in dejagnu/target.exp by adding the multilib options
> before
> the other options:
>
> default_target_compile:
>
> < append add_flags " [board_info $dest multilib_flags]"
> ---
>> set add_flags " [board_info $dest multilib_flags] $add_flags"
>
> and ran regressions for x86_64-unknown-linux-gnu before and after the change.
> The only difference in the results after the change was 24 new PASSes which
> are from the testcases which either use bind_pic_locally or that use -fno-pic.
>
> (Interestingly, there are many test files that bind_pic_locally pass without
> any issue before and after the change.)
>
> I tend to think that the options added from the test files should always win.
> Please correct me if I'm wrong. If I'm right, is dejagnu/target.exp is the
> best place to fix this and the way it tried to fix? Any better suggestions?
>
> Though this case is to do with -fPIC, I'm sure there are other options which
> when they come as multilib options might have same issue with the some of the
> options added by the test files or the default options.
>
> Regards
> VP
Ideally we would ask for that change in DejaGnu, but relying on such a
change would require everyone testing GCC to upgrade to a version of
DejaGnu with that fix, and I don't think we're ready to do that.
Tests that add options that might override or conflict with multilib
flags should check for those flags first and skip the test if they are
used. For examples, see tests in gcc.target/arm that use dg-skip-if.
Janis
Re: mach pass deleting instructions?
David Given wrote: [...] > When I actually try to build stuff, however, the branch gets emitted but > then silently deleted during the mach pass. Solved: turned out to be old code in the TARGET_MACHINE_DEPENDENT_REORG, dating from the port I was basing my backend on, which was mangling my code. I disabled the target hook and it all works now. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "USER'S MANUAL VERSION 1.0: The information presented in this │ publication has been carefully for reliability." --- anonymous │ computer hardware manual signature.asc Description: OpenPGP digital signature
Re: Help with using multilib for Cilk Library
On Tue, Jul 23, 2013 at 9:33 AM, Iyer, Balaji V wrote: >> Here is a patch: >> >> 1. Add target dependency on C++ for parallel build. >> 2. Remove hardcoded -O3 -fpic. libtool takes care of it. >> 3. Work around MAKEFLAGS for multilib build. >> > > Hi H.J., > Thank you! This patch got rid of all the errors for me. When I do > make install, it is installing both the 32 bit one and 64 bit one in > $INSTALL_DIR/lib. How can I make the 32 bit one write to $INSTALL_DIR/lib and > the 64-bit one write to $INSTALL_DIR/lib64? > Try this: # Target list. -lib_LTLIBRARIES = libcilkrts.la +toolexeclib_LTLIBRARIES = libcilkrts.la on libcilkrts/Makefile.am. -- H.J.
Re: atomic support for LEON3 platform
> ok, because i am not familiar with compiler implementation. So if you can > give me some references i will appreciate you very much. And by the way is > there any plan to support this feature in the mainline? OK, let's go ahead and implement the feature. We first need the binutils side, because a 'cas' is currently rejected by the assembler: eric@hermes:~/leon-elf> gcc/xgcc -Bgcc -c cas.adb -mcpu=leon3 /tmp/ccOuqOpo.s: Assembler messages: /tmp/ccOuqOpo.s:24: Error: Architecture mismatch on "cas". /tmp/ccOuqOpo.s:24: (Requires v9|v9a|v9b; requested architecture is v8.) /tmp/ccOuqOpo.s:47: Error: Architecture mismatch on "cas". /tmp/ccOuqOpo.s:47: (Requires v9|v9a|v9b; requested architecture is v8.) David, how do you want to handle this on the binutils side? The compiler currently passes -Av8 for LEON3 and I don't think that we want to pass -Av9 instead, so we would need something in between. -- Eric Botcazou
Re: New GCC port/retarget
On Tue, Jul 23, 2013 at 9:58 AM, Hendrik Greving wrote: > If I set use_gcc_stdint=wrap, does tm.h suppose to include > config/glibc-stdint.h? > Please reply to the mailing list, not just to me. Thanks. > If you are using glibc, you shoud add glibc-stdint.h to tm_file in > gcc/config.gcc; see many existing examples. If you aren't using > glibc, you may still want to do that, but you should make sure it is > correct for your target. Or you may need to define the same macros > that glibc-stdint.h defines, only with the values appropriate for your > target. I am copy'ing the email I accidently sent to Ian privately, so the answer will get properly archived in the mailing list. May I ask 2 follow-ups: 1. The new compiler doesn't seem to find /usr/include/stdint.h when compiling a sample test-case. The old one (old GCC version that had same target) did. I supposed this is related. Is this expected? 2. It is still a little unclear what use_gcc_stdint is for. I understand that GCC apparently need some stdint definitions. That's why I (can-) include glibc-stdint.h in tm.h by adding it in config.gcc. What role plays use_gcc_stdint then? On Mon, Jul 22, 2013 at 9:39 PM, Ian Lance Taylor wrote: > On Mon, Jul 22, 2013 at 8:28 PM, Hendrik Greving > wrote: >> After porting/re-targeting a very old backend (own target) to GCC >> 4.8.1, I am getting this when compiling: >> >> Fixing headers into /path/to/objdir/gcc/include-fixed for >> moon-unknown-none target >> No forbidden identifiers defined by this target >> echo timestamp > stmp-fixinc >> make[2]: *** No rule to make target >> `../../../../src/tools/fsf_4_8_1/gcc/ginclude/stdint.h', needed by >> `stmp-int-hdrs'. Stop. >> make[2]: Leaving directory `/path/to/objdir/gcc' >> make[1]: *** [all-gcc] Error 2 >> make[1]: Leaving directory `/path/to/objdir' >> make: *** [all] Error 2 >> >> Anybody knows what that is? > > Set use_gcc_stdint in gcc/config.gcc. Make sure your tm.h file > defines INT8_TYPE and friends one way or another. Look at > config/glibc-stdint.h. > > Ian
Re: New GCC port/retarget
On Tue, Jul 23, 2013 at 10:23 AM, Hendrik Greving wrote: > On Tue, Jul 23, 2013 at 9:58 AM, Hendrik Greving > wrote: >> If I set use_gcc_stdint=wrap, does tm.h suppose to include >> config/glibc-stdint.h? > >> Please reply to the mailing list, not just to me. Thanks. > >> If you are using glibc, you shoud add glibc-stdint.h to tm_file in >> gcc/config.gcc; see many existing examples. If you aren't using >> glibc, you may still want to do that, but you should make sure it is >> correct for your target. Or you may need to define the same macros >> that glibc-stdint.h defines, only with the values appropriate for your >> target. > > I am copy'ing the email I accidently sent to Ian privately, so the > answer will get properly archived in the mailing list. > > May I ask 2 follow-ups: > > 1. The new compiler doesn't seem to find /usr/include/stdint.h when > compiling a sample test-case. The old one (old GCC version that had > same target) did. I supposed this is related. Is this expected? Sorry, I don't know what is going on there. > 2. It is still a little unclear what use_gcc_stdint is for. I > understand that GCC apparently need some stdint definitions. That's > why I (can-) include glibc-stdint.h in tm.h by adding it in > config.gcc. What role plays use_gcc_stdint then? use_gcc_stdint in gcc/config.gcc indicates whether GCC should wrap an existing system version of or whether it should provide its own and ignore the existing one. Both choices are available, and the right choice depends on whether you have a (sounds like you do) and whether it provides anything beyond the standard types. Ian
[x86-64 psABI]: Extend x86-64 psABI to support AVX-512
Hi, Here is a patch to extend x86-64 psABI to support AVX-512: http://software.intel.com/sites/default/files/319433-015.pdf -- H.J. avx512.patch Description: Binary data
[x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
Intel MPX: http://software.intel.com/sites/default/files/319433-015.pdf introduces 4 bound registers, which will be used for parameter passing in x86-64. Bound registers are cleared by branch instructions. Branch instructions with BND prefix will keep bound register contents. This leads to 2 requirements to 64-bit MPX run-time: 1. Dynamic linker (ld.so) should save and restore bound registers during symbol lookup. 2. Extend the current 16-byte PLT entry: ff 25 32 8b 21 00jmpq *name@GOTPCREL(%rip) 68 00 00 00 00 pushq $index e9 00 00 00 00 jmpq PLT0 which clear bound registers, to 32-byte to add BND prefix to branch instructions. There are 2 psABI considerations: 1. Should PLT entries in all binaries, with and without MPX, be changed to 32-byte or just the necessary ones? 2. Only branch to PLT entry with BND prefix needs 32-byte PLT entry. If we use 32-byte PLT entry only when needed, it can be decided by: a. A new MPX PLT relocation: i. No new run-time relocation since MPX PLT relocation is resolved to branch to PLT entry at link-time. ii. Pro: No new section. iii. Con: Need a new relocation. Can't mark executable nor shared library. b. A new note section to indicate branches to external symbols with MPX prefix: i. A note section in relocatable and addition to PT_NOTE segment in executable and shared library. ii. Pro: No new relocation. iii. Con: A new section. Here is the proposed note section: An optional x86 feature note section, .note.x86-feature, to indicate features in the input files. The contents of this note section are: .section.note.x86-feature .align 4 .long .L1 - .L0 .long .L3 - .L2 .long 1 .L0: .asciz "x86 feature" .L1: .align 4 .L2: .longFeatureFlag (Feature flag) .L3: The current valid bits in FeatureFlag are #define NT_X86_FEATURE_BND_INSN_RELOC(0x1 << 0) It should be set if relocation against externally visible symbol is applied to instruction with BND prefix. The remaining bits in FeatureFlag are reserved. If a linker supports the optional feature note section, it should follow the rules below when processing the relocatable input for generating relocatable file, executable or shared library: 1. Relocatable files without the feature note section are considered as if FeatureFlag is zero. 2. An FeatureFlag bit is set if it is set in any input relocatable files. 3. The feature note section should be generated in the output file if any FeatureFlag bit is set. 4. The feature note section should be included in PT_NOTE segment when generating executable or shared library. I prefer the note section solution. Any suggestions, comments? -- H.J.
Re: [x86-64 psABI]: Extend x86-64 psABI to support AVX-512
On Tue, 23 Jul 2013, H.J. Lu wrote: > Here is a patch to extend x86-64 psABI to support AVX-512: I have no comments on this patch for now - but where is the version control repository we should use for the ABI source code, since x86-64.org has been down for some time? (I've also CC:ed the last person from AMD to post to gcc-patches, in the hope that they have the right contacts to get x86-64.org - website, mailing lists, version control - brought back up again.) -- Joseph S. Myers jos...@codesourcery.com
Re: Help forging a function_decl
Hello,
2013/7/23 Martin Jambor :
> Hi,
>
> But you do call cgraph_add_new_function on it as well, right? If not,
> how is its symbol table node (also called and serving as the call
> graph node) created?
I call finish_function for my decl. Inside that function, there's this
one call to cgraph_add_new_function, but the condition it is inside is
bypassed:
/* ??? Objc emits functions after finalizing the compilation unit.
This should be cleaned up later and this conditional removed. */
if (cgraph_global_info_ready)
{
cgraph_add_new_function (fndecl, false);
return;
}
Right after that, there's a call to cgraph_finalize_function, which I
guess works the way it should, creating its cgraph node. I took a look
at the comment in cgraph_add_new_function and it states that "this
function is intended to be used by middle end and allows insertion of
new function at arbitrary point of compilation. The function can be
either in high, low or SSA form GIMPLE." As I'm doing it in parsing
time and there was no gimplification passes yet, I guess it is ok not
to use it at this point.
> (And BTW, you are hacking on trunk, right? Older versions can be
> quite a bit different here.)
I understand that, but I intend to use Dragonegg to obtain LLVM IR
after the gcc front-end has done its work, so I'm hacking version
4.6.4, which is said to work better with Dragonegg.
> What do you mean by "50% of the time?" That you get different results
> even when you do not change your compiler? That should not happen and
> means you invoke undefined behavior, most likely depending on some
> uninitialized stuff (assuming your HW is OK) so you are probably not
> clearing some allocated structure or something. (Do you know why
> DECL_EXTERNAL was set? That looks weird).
Yeah, exactly: different results even not changing the compiler.
About DECL_EXTERNAL: it was my fault. At first I was trying to
reproduce the creation of a function_decl as in
create_omp_child_function, in omp-low.c, and I eventually forgot that
I set that attribute when playing with the possibilities.
> Anyway, my best guess is that your function is removed by
> symtab_remove_unreachable_nodes in ipa.c. (And now I also see that
> analyze_functions in cgraphunit.c is also doing its own unreachable
> node removal, but hopefully runs early enough this should not be your
> problem.) If your function is static and is not called or referenced
> from anywhere else, gcc will try to get rid of it.
I traced the execution path in gdb, and it happens that the function
is really being removed in cgraph_remove_unreachable_nodes in ipa.c
(that's basically the same function you pointed out, just another gcc
version). I don't know why that happens anyway, neither why it happens
intermittently when not debugging and never when debugging. My
function is not called or referenced yet, but neither is another
function in my source code which I put just in order to test this
issue, and yet it is not removed like my forged one. So it is in
respect to being or not static. A doubt: I tested setting TREE_STATIC
for my decl, but does that mean my function is static? The
documentation on the TREE_STATIC macro is: "In a FUNCTION_DECL,
nonzero if function has been defined".
> Try setting DECL_PRESERVE_P of your decl (or calling
> cgraph_mark_force_output_node on its call graph node which is cleaner
> but should be equivalent for debugging, I suppose). If that helps,
> this is most likely your problem.
I tried DECL_PRESERVE_P and it didn't work. In this version of gcc
there's no cgraph_mark_force_output_node. I tried
cgraph_mark_needed_node instead, didn't work either.
> What do you mean? That your function is not output or that you cannot
> use gdb at all?
That my function is never output when using gdb.
> Add -fdump-ipa-all switch and look whether the function appears
> there. Especially the cgraph dump can usually tell you that a
> function was removed as unreachable. Grep all dumps for "Reclaiming
> functions:" and see whether your function is listed.
You were right, but this is a direct consequence of my function being
removed like discussed before.
I'll keep investigating the problem and will inform you in case
something changes.
Thank you,
---
Rodolfo Guilherme Wottrich
Universidade Estadual de Campinas - Unicamp
RE: Help with using multilib for Cilk Library
> -Original Message- > From: H.J. Lu [mailto:hjl.to...@gmail.com] > Sent: Tuesday, July 23, 2013 1:04 PM > To: Iyer, Balaji V > Cc: Ian Lance Taylor; gcc@gcc.gnu.org > Subject: Re: Help with using multilib for Cilk Library > > On Tue, Jul 23, 2013 at 9:33 AM, Iyer, Balaji V > wrote: > >> Here is a patch: > >> > >> 1. Add target dependency on C++ for parallel build. > >> 2. Remove hardcoded -O3 -fpic. libtool takes care of it. > >> 3. Work around MAKEFLAGS for multilib build. > >> > > > > Hi H.J., > > Thank you! This patch got rid of all the errors for me. When I do > > make > install, it is installing both the 32 bit one and 64 bit one in > $INSTALL_DIR/lib. > How can I make the 32 bit one write to $INSTALL_DIR/lib and the 64-bit one > write to $INSTALL_DIR/lib64? > > > > Try this: > > # Target list. > -lib_LTLIBRARIES = libcilkrts.la > +toolexeclib_LTLIBRARIES = libcilkrts.la > > on libcilkrts/Makefile.am. It works now! Thanks for all your help! Thanks, Balaji V. Iyer. > > -- > H.J.
Re: Help forging a function_decl
Later I found out that cgraph_mark_needed_node was already being
called in cgraph_finalize_function, and that should really keep my
function from being removed. But when the function
cgraph_remove_unreachable_nodes executes, it is marked as unreachable
just because at this point it is not marked as needed anymore.
The piece of code which is doing that is
function_and_variable_visibility, in ipa.c. Oddly, the condition for
doing so is having DECL_EXTERNAL set for my fndecl, which I just said,
was my former mistake.
I really don't know why this erratic behavior is happening, I am
explicitly setting DECL_EXTERNAL to false.
Cheers,
---
Rodolfo Guilherme Wottrich
Universidade Estadual de Campinas - Unicamp
2013/7/23 Rodolfo Guilherme Wottrich :
> Hello,
>
> 2013/7/23 Martin Jambor :
>> Hi,
>>
>> But you do call cgraph_add_new_function on it as well, right? If not,
>> how is its symbol table node (also called and serving as the call
>> graph node) created?
>
> I call finish_function for my decl. Inside that function, there's this
> one call to cgraph_add_new_function, but the condition it is inside is
> bypassed:
>
> /* ??? Objc emits functions after finalizing the compilation unit.
> This should be cleaned up later and this conditional removed. */
> if (cgraph_global_info_ready)
> {
> cgraph_add_new_function (fndecl, false);
> return;
> }
>
> Right after that, there's a call to cgraph_finalize_function, which I
> guess works the way it should, creating its cgraph node. I took a look
> at the comment in cgraph_add_new_function and it states that "this
> function is intended to be used by middle end and allows insertion of
> new function at arbitrary point of compilation. The function can be
> either in high, low or SSA form GIMPLE." As I'm doing it in parsing
> time and there was no gimplification passes yet, I guess it is ok not
> to use it at this point.
>
>> (And BTW, you are hacking on trunk, right? Older versions can be
>> quite a bit different here.)
>
> I understand that, but I intend to use Dragonegg to obtain LLVM IR
> after the gcc front-end has done its work, so I'm hacking version
> 4.6.4, which is said to work better with Dragonegg.
>
>> What do you mean by "50% of the time?" That you get different results
>> even when you do not change your compiler? That should not happen and
>> means you invoke undefined behavior, most likely depending on some
>> uninitialized stuff (assuming your HW is OK) so you are probably not
>> clearing some allocated structure or something. (Do you know why
>> DECL_EXTERNAL was set? That looks weird).
>
> Yeah, exactly: different results even not changing the compiler.
> About DECL_EXTERNAL: it was my fault. At first I was trying to
> reproduce the creation of a function_decl as in
> create_omp_child_function, in omp-low.c, and I eventually forgot that
> I set that attribute when playing with the possibilities.
>
>> Anyway, my best guess is that your function is removed by
>> symtab_remove_unreachable_nodes in ipa.c. (And now I also see that
>> analyze_functions in cgraphunit.c is also doing its own unreachable
>> node removal, but hopefully runs early enough this should not be your
>> problem.) If your function is static and is not called or referenced
>> from anywhere else, gcc will try to get rid of it.
>
> I traced the execution path in gdb, and it happens that the function
> is really being removed in cgraph_remove_unreachable_nodes in ipa.c
> (that's basically the same function you pointed out, just another gcc
> version). I don't know why that happens anyway, neither why it happens
> intermittently when not debugging and never when debugging. My
> function is not called or referenced yet, but neither is another
> function in my source code which I put just in order to test this
> issue, and yet it is not removed like my forged one. So it is in
> respect to being or not static. A doubt: I tested setting TREE_STATIC
> for my decl, but does that mean my function is static? The
> documentation on the TREE_STATIC macro is: "In a FUNCTION_DECL,
> nonzero if function has been defined".
>
>> Try setting DECL_PRESERVE_P of your decl (or calling
>> cgraph_mark_force_output_node on its call graph node which is cleaner
>> but should be equivalent for debugging, I suppose). If that helps,
>> this is most likely your problem.
>
> I tried DECL_PRESERVE_P and it didn't work. In this version of gcc
> there's no cgraph_mark_force_output_node. I tried
> cgraph_mark_needed_node instead, didn't work either.
>
>> What do you mean? That your function is not output or that you cannot
>> use gdb at all?
>
> That my function is never output when using gdb.
>
>> Add -fdump-ipa-all switch and look whether the function appears
>> there. Especially the cgraph dump can usually tell you that a
>> function was removed as unreachable. Grep all dumps for "Reclaiming
>> functions:" and see whether your function is listed.
>
> You were right, but this is a direct conse
Re: fatal error: gnu/stubs-32.h: No such file
I'd like to mention that I too was bit by this one on Debian. I don't have a 32-bit development environment installed; why would I? I'm building primarily for myself, and if I did have to target a 32-bit environment, I'd likely have to mess with more stuff then just the compiler. If you can't find a way to detect this error, I can't imagine many people would have a problem with turning off multilibs on x86-64; it's something of a minority setup. -- Kie ekzistas vivo, ekzistas espero.
