Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names
On Aug 1, 2008, at 7:53 AM, Mark Mitchell wrote: My concern is that the path we're heading towards is: ... 2. Middle-end builds call graphs, etc., and throws out 99.5% of the functions and debug info, after deciding it's not needed. (Note, for example, that mangled names are typically not needed for inline functions.) Note that you often still need the mangled form of a symbol name when inlined if -g is present. -Chris
using gimple_duplicate_sese_tail for subloops
Hi I am working on expanding auto par for outer loops, and while doing so, I need to duplicate the whole body of the outer loop. the current function that is used for the inner loops is gimple_duplicate_sese_tail, only it doesn't support subloops. Any ideas on how I can alternatively get the same functionality? Thanks, Razya
Debugging a custom GCC Back End
Hi, I'm creating a GCC Back-End for a virtual CPU. I have already created a Machine Description (cpu.md) File and the Target Description Makro Files (cpu.h cpu.c). I have only implemented all the makros, which are needed for compiling the GCC. But not all which are needed for the CPU. The compilation of my custom GCC works, but the binary I get is not working. I always get the "internal compiler error: Segmentation fault" message if I try to Compile a c-file. But the GCC don't tell me, where or why the error occurred. Is there any possibility to debug the gcc-backend? Or how can I find out where the Error occurred? Thank you for your help, Balthasar PS: My English is not so good, but I hope you understand my problem! signature.asc Description: OpenPGP digital signature
Re: patch for merging graphite branch (before tuplification)
Hello All
Richard Guenther wrote:
On Sun, Aug 3, 2008 at 8:23 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
On Sat, 2 Aug 2008, Sebastian Pop wrote:
You have to get a copy of the release 0.9 of PPL from:
http://www.cs.unipr.it/ppl/Download/
I see this is documented as needing (a) C++, (b) GCC 4.0.3 or later, (c)
GMP compiled with the C++ interface enabled. I believe we previously
reached a conclusion that if GCC is made to require C++ it would work with
any version of GCC 3.4 or later (and did not discuss the question of the
GMP C++ interface). Recall that right now the documented requirement is
that a cross-compiler (so all non-Ada front ends) can be built with GCC
2.95 or later; Ada requires 3.4 or later; and any ISO C compiler should
work for bootstrapping a native compiler.
If Graphite can be disabled then the bootstrapping issue goes away as you
can in a first step build current GCC with C++ enabled and do a second stage
with Graphite enabled.
I also am in favor of having some stuff in GCC which use external
libraries, provided this stuff can be disabled at configure time.
My MELT branch also uses PPL (and some other libraries, in particular
libtldl) but AFAIK all can be entirely disabled (and is disabled by
default) at configure time.
In addition, once the legal issues on permitting plugins are settled,
hopefully a plugin infrastructure could be proposed to help such issues.
Actually, I would personnaly welcome that GCC would evolve in a stuff
where the core compiler is becoming much simpler & smaller, and where
very interesting extra features (perhaps including graphite) are as
plugins. I hope that the long time trend would be:
a core GCC, without sophisticated optimisations, providing several
front-ends (including C++ & Ada)& many back-ends + many plugins (several
of them distributed within the GCC compiler itself, not separately)
providing interesting features & optimisations.
Maybe the list of people is getting too long. I'm CC-ing the gcc@ list
(also reply-to:) because perhaps such discussion belongs more to gcc@
than to gcc-patches@
I also have no idea of the GCC runtime license issues mentionned at
previous GCC 2008 summit in june 2008 at Ottawa. Are things more clarified?
Thanks for reading
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
RE: Debugging a custom GCC Back End
Balthasar Biedermann wrote on 03 August 2008 14:59: > The compilation of my custom GCC works, but the binary I get is not > working. I always get the "internal compiler error: Segmentation fault" > message if I try to Compile a c-file. > But the GCC don't tell me, where or why the error occurred. Is there any > possibility to debug the gcc-backend? Or how can I find out where the > Error occurred? Sure, it works fine under a debugger like gdb. See the wiki page for more information: http://gcc.gnu.org/wiki/DebuggingGCC cheers, DaveK -- Can't think of a witty .sigline today
Re: Build requirements for the graphite loop optimization passes
On Sun, 3 Aug 2008, Sebastian Pop wrote: > Hi, > > I'm moving this thread to gcc@ mailing list for a wider audience. This message didn't seem to go to the gcc list. > On Sun, Aug 3, 2008 at 2:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > I agree with Joseph's comments. Thanks, > > > > -- > > Mark Mitchell > > CodeSourcery > > [EMAIL PROTECTED] > > (650) 331-3385 x713 > > > > On Aug 3, 2008, at 11:23 AM, "Joseph S. Myers" <[EMAIL PROTECTED]> > > wrote: > > > >> On Sat, 2 Aug 2008, Sebastian Pop wrote: > >> > >>> Hi, > >>> > >>> The graphite branch has been tuplified and the port to PPL passes the > >>> graphite testsuite. For building the graphite branch right now, here > >>> are the steps you'll have to go through: > >>> > >>> You have to get a copy of the release 0.9 of PPL from: > >>> http://www.cs.unipr.it/ppl/Download/ > >> > >> I see this is documented as needing (a) C++, (b) GCC 4.0.3 or later, (c) > >> GMP compiled with the C++ interface enabled. I believe we previously > >> reached a conclusion that if GCC is made to require C++ it would work with > >> any version of GCC 3.4 or later (and did not discuss the question of the > >> GMP C++ interface). Recall that right now the documented requirement is > >> that a cross-compiler (so all non-Ada front ends) can be built with GCC > >> 2.95 or later; Ada requires 3.4 or later; and any ISO C compiler should > >> work for bootstrapping a native compiler. > >> > > Note that we ported Cloog to PPL because of the "GPLv2 only" license > of PolyLib, and thus there are two ways to configure Cloog, and one > does not require C++. > > PolyLib is written in C and its main author, Doran Wilde agreed to > contact PolyLib's authors for changing the license of PolyLib to > "GPLv3 or later". This license change is still not complete. Because > such changes usually take more time than solving a technical problem, > porting Cloog to PPL, we now have two polyhedral library back-ends in > Cloog. Clearly GCC's configure code should constrain the choice of back-end, its version, and how it is configured, precisely enough to determine uniquely the code generated by GCC. Exactly how far this means constraining things is a key piece of information that we need. (But the configure code also shouldn't allow configuring with a GPLv2 version of polylib.) > >> At this point I think the policy questions regarding the build > >> requirements for graphite, even as an optional feature, need to be raised > >> on their own in a thread on the gcc list rather than buried in the patch > >> discussion. > >> > >> I also think that the configuration machinery needs to be set up so that > >> if static versions of Cloog/PPL are being used then the compiler will also > >> be linked with static libgcc/libstdc++ (-static-libgcc > >> -Wl,-Bstatic,-lstdc++,-Bdynamic with the GNU linker, other options may be > >> needed for e.g. OS X), as stated in Ian's slides - even for an optional > >> feature using C++. > >> > >> C++ also increases the importance of testing the libraries on all primary > >> and secondary host OSes. > > We can set up some of the systems needed to test the graphite passes. > Do we have the list of primary and secondary host OSes documented > somewhere? http://gcc.gnu.org/gcc-4.4/criteria.html On that list, arm-eabi and mipsisa64-elf are bare-metal targets that do not make sense as hosts. So the testing needed is for the other platforms in those lists, including that the .s files generated (for whatever tests in the testsuite are built with graphite enabled, say) for some given target do not depend on the host. I'm not particularly concerned about different CPUs for the same OS (I don't think testing on five different GNU/Linux hosts gives more useful information than just testing on 32-bit and 64-bit GNU/Linux), rather about testing the different OSes in the list. Pick a target that can be tested on a simulator following simtest-howto.html (either arm-eabi or mipsisa64-elf will do, and both use 64-bit HOST_WIDE_INT so you won't run into pre-existing HOST_WIDE_INT-dependence code generation issues). Build for it on whatever hosts and make a script to run the graphite tests and save the .s files available, along with a baseline tarball of .s files for people to compare against. Native build and testing on those systems is a good idea as well as comparing the code generated for host-dependence. > Thanks, > Sebastian Pop and Jan Sjodin > -- > AMD - GNU Tools -- Joseph S. Myers [EMAIL PROTECTED]
Re: patch for merging graphite branch (before tuplification)
On Sun, 3 Aug 2008, Basile STARYNKEVITCH wrote: > I also am in favor of having some stuff in GCC which use external libraries, > provided this stuff can be disabled at configure time. My view as a general principle is that options such as -O2 must have exactly the same results regardless of how GCC is configured, whether -g is used (apart from debug info differences), whether precompiled headers are used, what host GCC is running on, what libraries it uses, what versions of them it uses or how those libraries are configured. So anything optional can't be included in an option that's supported with it missing; any option enabling an optional feature must give an error if the relevant code is not linked in. Any differences in code generated (or diagnostics given, etc.) based on the above factors are bugs. Of course such bugs exist, but we should take reasonable care about not introducing new ones. This means obvious things such as not putting an optional feature into an option that is accepted without the feature enabled, as well as checking new host libraries for how they might affect the above. Separately, we know that options not included in -On are liable to bit-rot so we need to be quite careful when adding them, balancing the risks of bit-rot and the costs of additional build dependencies, together with how advantageous the option would be likely to be in -On. -- Joseph S. Myers [EMAIL PROTECTED]
