Re: Write rights to commit to GCC
I assume that you only target OpenACC support for C/C++ and not for Fortran, do you? Actually, Fortran is in our checklist, too. BTW: The Cauldron 2013 recordings haven't shown up at YouTube, yet. It would be great to see them! -- Thanks, Evgeny.
Re: New GCC port/retarget
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
New GCC port/retarget
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? Regards, Hendrik Greving
Re: Help forging a function_decl
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. Again, thank you for the help. --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp 2013/7/22 Rodolfo Guilherme Wottrich : > 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. > > 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. And when I try to > debug gcc with gdb, it always fails. > Any thoughts? Maybe I am missing something related to garbage > collection or so... Not a clue. > > --- > Rodolfo Guilherme Wottrich > Universidade Estadual de Campinas - Unicamp > > > 2013/7/22 Martin Jambor : >> Hi, >> >> On Wed, Jul 17, 2013 at 04:52:30PM -0300, Rodolfo Guilherme Wottrich wrote: >>> Hello there, >>> >>> Please disregard this message in case it doesn't fit here. >>> >>> During compilation of a C file, I need to be able to create a global >>> function definition, with whatever a body I may have forged. I mean, >>> the function is not going to be present in the source file and I got >>> to create the respective tree structure so it can be later gimplified >>> and further compiled like any other function present in the source. I >>> would only need to create that function in case some OpenMP directive >>> is encountered, so my latest and unsuccessful try to do so was to >>> create the tree structures for a FUNCTION_DECL and, say, a variable >>> declared inside the scope of that function, after the parsing of a >>> #pragma omp parallel in c_parser_omp_parallel() in file c-parser.c. I >>> followed and tried to re-create the steps I found in the function >>> create_omp_child_function(), in file omp-low.c, and >>> http://gcc.gnu.org/onlinedocs/gccint/Function-Basics.html#Function-Basics. >>> >>> I think maybe the problem is that my new function doesn't go under >>> rest_of_compilation, therefore it is not gimplified and obviously no >>> code for it is generated. >> >> it's a bit difficult to say without knowing what you are doing and at >> what compilation stage you are doing it but perhaps you could try >> calling cgraph_add_new_function on the new decl? Also try reading the >> comment at the beginning of cgraphunit.c. >> >> Hope it helps, >> >> Martin >> >> >>> >>> Summarizing: I tried to forge a function in parsing time, but >>> couldn't. What am I doing wrong, and how can one do such a thing? >>> Maybe the problem is that I create no calls to that new function, what >>> do you think? Anyway, I'm compiling with -O0, so I guess no >>> optimization pass would remove my function just because it is not >>> being used. >>> >>> Thanks in advance, >>> >>> --- >>> Rodolfo Guilherme Wottrich >>> Universidade Estadual de Campinas - Unicamp
Re: Git mirror changes
On Mon, Jul 22, 2013 at 5:37 PM, Jason Merrill wrote: > On 07/22/2013 04:59 PM, Diego Novillo wrote: >> >> Not sure if I completely understand, but would this change make it >> easier to deal with subdirectory branches? It's pretty horrid now. > > > That's the idea. Excellent! In that case, I'm all for it. Diego.
Re: atomic support for LEON3 platform
> 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. -- Eric Botcazou
Re: Git mirror changes
On 07/22/2013 04:59 PM, Diego Novillo wrote: On Mon, Jul 22, 2013 at 4:39 PM, Jason Merrill wrote: 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. Not sure if I completely understand, but would this change make it easier to deal with subdirectory branches? It's pretty horrid now. That's the idea. Jason
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-gnu/ >> >> 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/libs >> >> 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/libs >> >> > 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 directory `/export/users/my-files/b-gcc >> >> > >> >> > >> >> > From what it looks like, it is reading the 64 bit library for the >> >> > 32 bit mode (or >> >> vice-versa). How do I fix this? I am also attaching my configure.ac >> >> and Makefile.am. Please note that it is not fully cleaned up (e.g. I >> >> have stuff commented out etc). Can someone please tell me what I am doing >> wrong? >> >> >> >> When building the 32bit libcillkrts you are linking against the >> >> 64-bit >> >> libstdc++. It's right there on your command line: >> >> /export/u
Re: TARGET_SECTION_TYPE_FLAGS
I was wrong. It is used in varasm.c:named_section. On Mon, Jul 22, 2013 at 11:22 AM, Hendrik Greving wrote: > Is this hook still used? I don't see anything in the tool-chain > referring to it. It is documented however. > Regards, > Thanks, > Hendrik Greving
Re: Git mirror changes
On Mon, Jul 22, 2013 at 4:39 PM, Jason Merrill wrote: > 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. Not sure if I completely understand, but would this change make it easier to deal with subdirectory branches? It's pretty horrid now. I don't fully understand what you are after with these changes, but they seem benign. Diego.
Re: Git mirror changes
On 07/22/2013 02:39 PM, Jason Merrill wrote: 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? Do we want to limit creation of non-personal branches via git? No strong opinions. It might help if you gave a bit of rationale behind the proposed change though. Jeff
Re: Git mirror changes
On Mon, Jul 22, 2013 at 1:39 PM, Jason Merrill wrote: > 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? > > Do we want to limit creation of non-personal branches via git? What about distro/company branches that are in the git only or is that included in the personal branches? Thanks, Andrew Pinski > > Any other thoughts? > > Jason
Git mirror changes
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? Do we want to limit creation of non-personal branches via git? Any other thoughts? Jason
GNU Tools Cauldron 2013 - Slides
I have uploaded all the slides I received to the wiki page. If you presented a talk and do not see your slides in http://gcc.gnu.org/wiki/cauldron2013, please fix the link yourself or let me know and I'll add them to the table (if you can fix the links yourself, you'll be doing me a big favour). I am in the process of uploading and processing videos, but I think it will take me at least another day or two to finish. I'll send an update after they are ready. Diego.
Re: RFC: Gimple combine/folding interface
On Mon, Jul 22, 2013 at 01:36:17PM -0600, Jeff Law wrote:
> Before designing an interface which inherently includes that
> information we should think hard about if it's valuable and if a
> tree combiner is the right place.
>
> I have high hopes that we can get the zero/sign extension
> elimination we want by carrying VRP information and querying it.
>
> As Richi has mentioned, we really want a folder we can call
> independently of whatever pass we're in. Though I'd also like a
> folder that can query for pass specific information if it's handy
> and useful.
For the preservation of VRP info we already have patch in process of review:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00121.html
As for zero bits info, I've recently run into a case where having the zero
bits information preserved alongside of the VRP info could be helpful,
for optimizing away the vectorizer scalar loop for bound. If non-zero bits
computation proves or e.g. user asserts through if (val % 32)
__builtin_unreachable () or similar, even when the bounds of the loop aren't
constant, we could figure out that the number of iterations is a multiply of
vectorization factor and avoid computing that
So, perhaps let vrp{1,2} compute the vrp info and preserve (plus if not
specified just set nonzero bits to all ones), and this pass or other compute
the nonzero bits? Sign bit copies is just an int, perhaps also track that.
Jakub
Re: RFC: Gimple combine/folding interface
On 07/21/2013 08:14 PM, Andrew Pinski wrote:
On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski wrote:
I was creating a new gimple/folding interface and wanted some opinions
on the interface.
typedef double_int (*nonzerobits_t)(tree var);
typedef tree (*valueizer_t)(tree var);
class gimple_combine
{
public:
gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
IIRC, the zero/nonzero bits stuff in combine is mostly good at pruning
sign/zero extensions, eliminating bit masking in the low bits for alphas
and for cleaning up addressing of varargs arguments that were on the
stack. Yea, there are times when it can do other stuff, but that's my
recollection for what it was actually good at.
Before designing an interface which inherently includes that information
we should think hard about if it's valuable and if a tree combiner is
the right place.
I have high hopes that we can get the zero/sign extension elimination we
want by carrying VRP information and querying it.
As Richi has mentioned, we really want a folder we can call
independently of whatever pass we're in. Though I'd also like a folder
that can query for pass specific information if it's handy and useful.
One of the interesting things we're going to need to figure out is when
walking the use-def chains do we want to build the more complex
expression, then fold it, keeping the result if it's gimple. Or do we
want to work strictly with an exploded operator/operands represenation.
Jeff
TARGET_SECTION_TYPE_FLAGS
Is this hook still used? I don't see anything in the tool-chain referring to it. It is documented however. Regards, Thanks, Hendrik Greving
Re: Help forging a function_decl
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. 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. And when I try to debug gcc with gdb, it always fails. Any thoughts? Maybe I am missing something related to garbage collection or so... Not a clue. --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp 2013/7/22 Martin Jambor : > Hi, > > On Wed, Jul 17, 2013 at 04:52:30PM -0300, Rodolfo Guilherme Wottrich wrote: >> Hello there, >> >> Please disregard this message in case it doesn't fit here. >> >> During compilation of a C file, I need to be able to create a global >> function definition, with whatever a body I may have forged. I mean, >> the function is not going to be present in the source file and I got >> to create the respective tree structure so it can be later gimplified >> and further compiled like any other function present in the source. I >> would only need to create that function in case some OpenMP directive >> is encountered, so my latest and unsuccessful try to do so was to >> create the tree structures for a FUNCTION_DECL and, say, a variable >> declared inside the scope of that function, after the parsing of a >> #pragma omp parallel in c_parser_omp_parallel() in file c-parser.c. I >> followed and tried to re-create the steps I found in the function >> create_omp_child_function(), in file omp-low.c, and >> http://gcc.gnu.org/onlinedocs/gccint/Function-Basics.html#Function-Basics. >> >> I think maybe the problem is that my new function doesn't go under >> rest_of_compilation, therefore it is not gimplified and obviously no >> code for it is generated. > > it's a bit difficult to say without knowing what you are doing and at > what compilation stage you are doing it but perhaps you could try > calling cgraph_add_new_function on the new decl? Also try reading the > comment at the beginning of cgraphunit.c. > > Hope it helps, > > Martin > > >> >> Summarizing: I tried to forge a function in parsing time, but >> couldn't. What am I doing wrong, and how can one do such a thing? >> Maybe the problem is that I create no calls to that new function, what >> do you think? Anyway, I'm compiling with -O0, so I guess no >> optimization pass would remove my function just because it is not >> being used. >> >> Thanks in advance, >> >> --- >> Rodolfo Guilherme Wottrich >> Universidade Estadual de Campinas - Unicamp
Re: resurrecting automatic dependencies
> "Diego" == Diego Novillo writes: Diego> Have you any plans for other build system work? Nope, no other plans. This was just an unfinished item from long ago that Cauldron inspired me to try to complete. Tom
Re: Help forging a function_decl
Hi, On Wed, Jul 17, 2013 at 04:52:30PM -0300, Rodolfo Guilherme Wottrich wrote: > Hello there, > > Please disregard this message in case it doesn't fit here. > > During compilation of a C file, I need to be able to create a global > function definition, with whatever a body I may have forged. I mean, > the function is not going to be present in the source file and I got > to create the respective tree structure so it can be later gimplified > and further compiled like any other function present in the source. I > would only need to create that function in case some OpenMP directive > is encountered, so my latest and unsuccessful try to do so was to > create the tree structures for a FUNCTION_DECL and, say, a variable > declared inside the scope of that function, after the parsing of a > #pragma omp parallel in c_parser_omp_parallel() in file c-parser.c. I > followed and tried to re-create the steps I found in the function > create_omp_child_function(), in file omp-low.c, and > http://gcc.gnu.org/onlinedocs/gccint/Function-Basics.html#Function-Basics. > > I think maybe the problem is that my new function doesn't go under > rest_of_compilation, therefore it is not gimplified and obviously no > code for it is generated. it's a bit difficult to say without knowing what you are doing and at what compilation stage you are doing it but perhaps you could try calling cgraph_add_new_function on the new decl? Also try reading the comment at the beginning of cgraphunit.c. Hope it helps, Martin > > Summarizing: I tried to forge a function in parsing time, but > couldn't. What am I doing wrong, and how can one do such a thing? > Maybe the problem is that I create no calls to that new function, what > do you think? Anyway, I'm compiling with -O0, so I guess no > optimization pass would remove my function just because it is not > being used. > > Thanks in advance, > > --- > Rodolfo Guilherme Wottrich > Universidade Estadual de Campinas - Unicamp
mach pass deleting instructions?
So I'm trying to get compare-and-branch working on my architecture. I
have the following patterns:
(define_expand "cbranchsf4"
[(set
(reg:CC CC_REGNO)
(compare:CC
(match_operand:SF 1 "register_operand")
(match_operand:SF 2 "register_operand")))
(set
(pc)
(if_then_else
(match_operator 0 "comparison_operator"
[(reg:CC CC_REGNO)
(const_int 0)]
)
(label_ref
(match_operand 3 "" ""))
(pc))
)]
""
{}
)
(define_insn "*test_sf"
[(set
(reg:CC CC_REGNO)
(compare
(match_operand:SF 0 "register_operand" "r")
(match_operand:SF 1 "register_operand" "r")))]
""
"fcmp %0, %1, %1"
[(set_attr "length" "4")]
)
(define_insn "*branch_"
[(set
(pc)
(if_then_else
(condition
(reg:CC CC_REGNO)
(const_int 0))
(label_ref
(match_operand 0))
(pc)))]
""
"b %0"
[(set_attr "length" "4")]
)
The architecture is utterly traditional and the code above is stolen
pretty much intact from the moxie port (which I'm using as a reference
because it seems to be simple and easy to understand).
When I actually try to build stuff, however, the branch gets emitted but
then silently deleted during the mach pass. The debug tracing (as
produced by -da) doesn't say why; it just removes it. Naturally the
resulting program doesn't work. Example:
int cmp(float a, float b)
{ return a>b; }
->
cmp:
push r6, lr
mov r6, #1 ; fast
fcmp r0, r1, r1
<--- branch instruction to .L2 should be here
mov r6, #0 ; fast
.L2:
mov r0, r6 ; fast
pop r6, pc
Does anyone have any suggestions as to what I'm doing wrong, and where
to start looking? For example, what is the mach pass actually trying to
do, and is there any way to get it to give me more information about why
it's doing it?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ 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: Write rights to commit to GCC
Jeff Law wrote: On 07/22/2013 03:07 AM, Evgeny Gavrin wrote: Earlier we (Samsung R&D Institute Rus) proposed to implement OpenACC for GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html We got our assignment form, now. Great! I am looking forward to the implementation! I assume that you only target OpenACC support for C/C++ and not for Fortran, do you? Note there were two good BOF sessions at the GNU Cauldron last week on accelerator support in GCC. I would strongly suggest you get in contact with folks from those sessions. Recordings of those sessions ought to show up relatively soon if they haven't already. The only BoF I know about is Torvald's http://gcc.gnu.org/ml/gcc/2013-06/msg00226.html ; it's also the only one listed in the schedule/abstract at http://gcc.gnu.org/wiki/cauldron2013 Was the second one a follow up - or dit it focus on something else? BTW: The Cauldron 2013 recordings haven't shown up at YouTube, yet. Tobias
Re: Write rights to commit to GCC
On 07/22/2013 10:18 AM, Tobias Burnus wrote: Note there were two good BOF sessions at the GNU Cauldron last week on accelerator support in GCC. I would strongly suggest you get in contact with folks from those sessions. Recordings of those sessions ought to show up relatively soon if they haven't already. The only BoF I know about is Torvald's http://gcc.gnu.org/ml/gcc/2013-06/msg00226.html ; it's also the only one listed in the schedule/abstract at http://gcc.gnu.org/wiki/cauldron2013 Was the second one a follow up - or dit it focus on something else? BTW: The Cauldron 2013 recordings haven't shown up at YouTube, yet. The second was a follow-up, also led by Torvald. jeff
Re: GCC 4.8.1 MIPS
On Sun, 2013-07-21 at 10:24 -0700, Hendrik Greving wrote:
> The enum opt_code in gcc/options.h looks like this;
>
> enum opt_code
> {
> N_OPTS,
> OPT_SPECIAL_unknown,
> OPT_SPECIAL_ignore,
> OPT_SPECIAL_program_name,
> OPT_SPECIAL_input_file
> };
>
> I have a feeling I am missing something. Any idea what?
>
> Thanks,
> Regards,
> Hendrik Greving
Which MIPS target are you building? I have not had any problems
building a MIPS cross compiler using the GCC 4.8.1 sources.
When I look at gcc/options.h in my build directory I see a very
(very) large opt_code enum:
enum opt_code
{
OPT = 0, /* -### */
/* OPT__CLASSPATH = 1, */ /* --CLASSPATH */
(lots of deleted lines)
OPT_fpic = 773,/* -fpic */
OPT_fpie = 774,/* -fpie */
(lots more deleted lines)
OPT_v = 1212, /* -v */
OPT_version = 1213,/* -version */
OPT_w = 1214, /* -w */
OPT_wrapper = 1215,/* -wrapper */
OPT_x = 1216, /* -x */
OPT_z = 1217, /* -z */
N_OPTS,
OPT_SPECIAL_unknown,
OPT_SPECIAL_ignore,
OPT_SPECIAL_program_name,
OPT_SPECIAL_input_file
};
You are not configuring/building directly in the source directory are
you? That doesn't work. options.h is built during the make process, it
looks like it didn't get made correctly for you. You might be missing
some tool (grep, awk, etc) that is needed when making option.h.
Steve Ellcey
sell...@mips.com
Re: Write rights to commit to GCC
On 07/22/2013 03:07 AM, Evgeny Gavrin wrote: Hi, all! Earlier we (Samsung R&D Institute Rus) proposed to implement OpenACC for GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html We got our assignment form, now. I can attach signed and approved pdf, if needed. What should we do to get rights to create branch for OpenACC and submit a few patches to mainline? Like this one: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html See: Get an account on gcc.gnu.org/sourcware.org via this form, with my email as approving the request and "gcc" as the project. http://sourceware.org/cgi-bin/pdw/ps_form.cgi You'll want to review this page as well. http://gcc.gnu.org/svnwrite.html Note there were two good BOF sessions at the GNU Cauldron last week on accelerator support in GCC. I would strongly suggest you get in contact with folks from those sessions. Recordings of those sessions ought to show up relatively soon if they haven't already.
RE: Help with using multilib for Cilk Library
> -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-gnu/ > >> 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/libs > >> 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/libs > >> > 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 directory `/export/users/my-files/b-gcc > >> > > >> > > >> > From what it looks like, it is reading the 64 bit library for the > >> > 32 bit mode (or > >> vice-versa). How do I fix this? I am also attaching my configure.ac > >> and Makefile.am. Please note that it is not fully cleaned up (e.g. I > >> have stuff commented out etc). Can someone please tell me what I am doing > wrong? > >> > >> When building the 32bit libcillkrts you are linking against the > >> 64-bit > >> libstdc++. It's right there on your command line: > >> /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstd > >> c++- > >> v3/src/.libs/libstdc++.so. > >> If that argument is needed at all, it needs to be > >> /exp
Altera Nios II port submission
To the GCC Steering Committee, Mentor Graphics has submitted, and recently re-submitted an updated version, of a GCC backend port for the Altera Nios II architecture, currently on gcc-patches awaiting technical review [1]. We're proposing, upon port approval and commit to trunk, Sandra Loosemore and myself (Chung-Lin Tang), both of Mentor Graphics, as target maintainers. Thank you, Chung-Lin [1] http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00526.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00527.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00528.html
Re: RFC: Gimple combine/folding interface
On 07/20/2013 02:09 AM, Andrew Pinski wrote:
gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
allow_full_reassiocation(reas) {}
I think this constructor should be marked "explicit".
--
Florian Weimer / Red Hat Product Security Team
dejagnu multilib options and dg-{add|additional-}options
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
Re: Write rights to commit to GCC
On 07/22/2013 10:07 AM, Evgeny Gavrin wrote: > Hi, all! > > Earlier we (Samsung R&D Institute Rus) proposed to implement OpenACC for > GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html > > We got our assignment form, now. I can attach signed and approved pdf, > if needed. > > What should we do to get rights to create branch for OpenACC and submit > a few patches to mainline? Like this one: > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html I'm sorry, we're just being a little slow. You posted your patch a day before Americans were going away for their big holiday. Not a good excuse, I know, but probably true. Have a look in the MAINTAINERS file at the list of people who are responsible for the are you patched. Find the right person, and mail them directly. Remind them of your patch. Andrew.
Wrong code for i686 target with -O3 -flto
Hi All! Unfortunately now the compiler generates wrong code for i686 target when options -O3 and -flto are used. It started more than a month ago and reflected in PR57602. Such combination of options could be quite important at least from the performance point of view. Since there was almost no reaction on this PR I'd like to ask either to look at it in some observable future or revert the commit which is guilty for the issue. Thanks, Igor
Write rights to commit to GCC
Hi, all! Earlier we (Samsung R&D Institute Rus) proposed to implement OpenACC for GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html We got our assignment form, now. I can attach signed and approved pdf, if needed. What should we do to get rights to create branch for OpenACC and submit a few patches to mainline? Like this one: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html -- Thanks, Evgeny.
Re: RFC: Gimple combine/folding interface
Andrew Pinski wrote:
>On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski
>wrote:
>> I was creating a new gimple/folding interface and wanted some
>opinions
>> on the interface.
>>
>> typedef double_int (*nonzerobits_t)(tree var);
>> typedef tree (*valueizer_t)(tree var);
>>
>> class gimple_combine
>> {
>> public:
>> gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
>> valueizerv(b), allow_full_reassiocation(false) {}
>> gimple_combine() : nonzerobitsf(NULL), valueizerv(NULL),
>> allow_full_reassiocation(false) {}
>> gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
>> allow_full_reassiocation(reas) {}
>> tree build2 (location_t, enum tree_code, tree, tree, tree);
>> tree build1 (location_t, enum tree_code, tree, tree);
>> tree build3 (location_t, enum tree_code, tree, tree, tree, tree);
>> tree combine (gimple);
>> private:
>> nonzerobits_t nonzerobitsf;
>> valueizer_t valueizerv;
>> bool allow_full_reassiocation;
>> tree binary (location_t, enum tree_code, tree, tree, tree);
>> tree unary (location_t, enum tree_code, tree, tree);
>> tree ternary (location_t, enum tree_code, tree, tree, tree, tree);
>> };
Just a few comments before I return to work late in August. I like the way of
using a c++ object to store combiner flags as opposed to extra arguments. For
the optimizers I want to retain the ability to specify the desired result
(constant, single op, arbitrary) which also allows shortcutting some transforms.
I also want to retain the ability to return the combining result piecewise
without building trees, at least for results that fit a single gimple stmt.
>> bool replace_rhs_after_ssa_combine (gimple_stmt_iterator *, tree);
... Precisely to avoid this.
I'm not sure if you want to replace the fold-const.c workers with this
infrastructure?
Richard.
>> This is what I have so far and wonder if there is anything else I
>> should include.
>>
>> This will be used to replace the folding code in fold-const.c and
>gimple-fold.c.
>
>I placed what I decided in a branch in git:
>
>http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gimple-ssa-combine.h;h=3d597291c1756cdf6e3318fd190ac70911ceb702;hb=d32468a31ab5e50fabab3a04303f6892ad890fd5
>
>Note I won't have time to work on this again until the middle of August
>or so.
>
>The status of the current patch is that it is able to build libgcc but
>there are some addition ICEs due to checking to make sure all of the
>forwprop optimizations are pushed over to gimple_combine (since I
>started this work on an older code base).
>
>Thanks,
>Andrew Pinski
>
>>
>> Thanks,
>> Andrew Pinski
