Re: How can I write a builtin func?

[Liu]

2010/12/10 WANG.Jiong :
> On 12/10/2010 02:17 PM, Liu wrote:
>
> Hi all,
>   I'm porting gcc to a MIPS-based DSP, I need write some builtin
> func for some insns, but I can't find a doc., any one should help me?
> Show me a example please? Thanks very much.
>
> Liu.
>
>
> Maybe you should at least implement the following two hooks:
>
> TARGET_INIT_BUILTINS
>   ---> to do some initialization
>
> TARGET_EXPAND_BUILTIN
>   ---> to expand builtin related tree to rtl
>   I suggest you define some UNSPEC rtl,  like:
>  (define_insn "xxx"
>  [set (match_operand: .)
>  (unspec: [...] UNSPEC_XXX)]
>   ..
>     )
>
>   and then expand builtin tree to these rtl by calling the
> related gen_xxx
>
> Suggest you to see s390's related hook implementation.
>
> --
> Best,
> Wong.KwongYuan

Dear Wong.KwongYuan,
  Thank you very much! Your answer is very clear!
  I'll look into it, maybe you will help me more when I get more problems.
Thanks again!

Liu.

Re: How can I write a builtin func?

[WANG.Jiong]

On 12/10/2010 02:17 PM, Liu wrote:

Hi all,
   I'm porting gcc to a MIPS-based DSP, I need write some builtin
func for some insns, but I can't find a doc., any one should help me?
Show me a example please? Thanks very much.

Liu.
   

Maybe you should at least implement the following two hooks:

TARGET_INIT_BUILTINS
  ---> to do some initialization

TARGET_EXPAND_BUILTIN
  ---> to expand builtin related tree to rtl
  I suggest you *define some UNSPEC rtl*,  like:
 (define_insn "xxx"
 [set (match_operand: .)
 (unspec: [...] UNSPEC_XXX)]
  ..
)

  and then expand builtin tree to these rtl by calling the 
related *gen_xxx*


Suggest you to see s390's related hook implementation.

---
Best,
Wong

How can I write a builtin func?

[Liu]

Hi all,
  I'm porting gcc to a MIPS-based DSP, I need write some builtin
func for some insns, but I can't find a doc., any one should help me?
Show me a example please? Thanks very much.

Liu.

Re: "ld -r" on mixed IR/non-IR objects (

[H.J. Lu]

On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu  wrote:
> On Wed, Dec 8, 2010 at 9:36 AM, H.J. Lu  wrote:
>> On Wed, Dec 8, 2010 at 5:54 AM, H.J. Lu  wrote:
>>> On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen  wrote:
> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>
>> The only problem left is mixing of lto and non lto objects. this right
>> now is not handled. IMHO still the best way to handle it is to use
>> slim lto and then simply separate link the "left overs" after deleting
>> the LTO objects. This can be actually done with objcopy (with some
>> limitations), doesn't even need linker support.
>>
>
> Quite possibly a better way to deal with that is to provide a mechanism
> for encapsulating arbitrary binary code objects inside the LTO IR.

 Then you would need to teach your assembler and everything
>>>
>>> The magic section is generated by linker directly. No changes to
>>> assembler is required.
>>>
 else that may generate ELF objects to generate this magic object. But why
 not just ELF directly? that is what it is after all.
>>>
>>> My proposal isn't specific to ELF.
>>>

 To be honest I don't really see the point of all this complexity you
 guys are proposing just to save fat LTO. Fat LTO is always a bad idea
 because it's slow and  does lots of redundant work. If LTO is to become
 a more wide spread mode it has to go simply because of the poor
 performance.

 With slim LTO passthrough is  very straight-forward: simple pass
 through every section that is not LTO and generate code for the LTO
 sections. No new magic sections needed at all.

>>>
>>> My proposal works on both fat and slim LTO objects.  The idea is
>>> you can use "ld -r" on any combination of inputs and its output
>>> still works as before "ld -r".
>>>
>>
>> Here is the revised proposal.
>>
>
> The initial implementation of my proposal is available on hjl/lto-mixed
> branch at
>
> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
>
> Simple case works.  More cleanups are needed.  Feedbacks
> are welcome.
>

I checked in patches to remove temporary files.


-- 
H.J.

Re: "ld -r" on mixed IR/non-IR objects (

[H.J. Lu]

On Wed, Dec 8, 2010 at 9:36 AM, H.J. Lu  wrote:
> On Wed, Dec 8, 2010 at 5:54 AM, H.J. Lu  wrote:
>> On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen  wrote:
 On 12/07/2010 04:20 PM, Andi Kleen wrote:
>
> The only problem left is mixing of lto and non lto objects. this right
> now is not handled. IMHO still the best way to handle it is to use
> slim lto and then simply separate link the "left overs" after deleting
> the LTO objects. This can be actually done with objcopy (with some
> limitations), doesn't even need linker support.
>

 Quite possibly a better way to deal with that is to provide a mechanism
 for encapsulating arbitrary binary code objects inside the LTO IR.
>>>
>>> Then you would need to teach your assembler and everything
>>
>> The magic section is generated by linker directly. No changes to
>> assembler is required.
>>
>>> else that may generate ELF objects to generate this magic object. But why
>>> not just ELF directly? that is what it is after all.
>>
>> My proposal isn't specific to ELF.
>>
>>>
>>> To be honest I don't really see the point of all this complexity you
>>> guys are proposing just to save fat LTO. Fat LTO is always a bad idea
>>> because it's slow and  does lots of redundant work. If LTO is to become
>>> a more wide spread mode it has to go simply because of the poor
>>> performance.
>>>
>>> With slim LTO passthrough is  very straight-forward: simple pass
>>> through every section that is not LTO and generate code for the LTO
>>> sections. No new magic sections needed at all.
>>>
>>
>> My proposal works on both fat and slim LTO objects.  The idea is
>> you can use "ld -r" on any combination of inputs and its output
>> still works as before "ld -r".
>>
>
> Here is the revised proposal.
>

The initial implementation of my proposal is available on hjl/lto-mixed
branch at

http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary

Simple case works.  More cleanups are needed.  Feedbacks
are welcome.

Thanks.


-- 
H.J.

Re: internal compiler error in gcc trunk when using std::map

[Jonathan Wakely]

On 10 December 2010 00:40, Nathan Ridge wrote:
>
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

This mailing list is not the right way to report bugs, you should have
followed the instructions in the output you quoted. Had you searched
bugzilla you'd probably have found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701

internal compiler error in gcc trunk when using std::map

[Nathan Ridge]

Hello,
 
I've just build the gcc trunk and tried to compile some code that compiled fine 
with gcc 4.5.
It gave an internal compiler error.
I've reduced it to the following minimal test case:
 
#include 
#include 
int main()
{
std::map m;
std::pair p;
m.insert(p);
return 0;
}
 
Here's the command used to compile:
 
g++-4.6 --std=c++0x test.cpp
 
Here's the output:
 
In file included from 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
 from 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
 from 
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
 from ice.cpp:1:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
 In constructor âconstexpr std::pair<_T1, _T2>::pair(const std::pair<_U1, 
_U2>&) [with _U1 = std::basic_string, _U2 = int, _T1 = const 
std::basic_string, _T2 = int]â:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:780:68:
   instantiated from âconst bool 
std::__is_convertible_helper, int>&, 
std::pair, int>, false>::__valueâ
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:787:12:
   instantiated from âstd::is_convertible, 
int>&, std::pair, int> >â
test.cpp:8:15:   instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:107:43:
 internal compiler error: in build_data_member_initialization, at 
cp/semantics.c:5502
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
 
And here's the output of g++-4.6 -v:
 
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../src/configure --program-suffix=-4.6 --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101209 (experimental) (GCC)
 
Thanks,
Nate.
  

gcc-4.5-20101209 is now available

[gccadmin]

Snapshot gcc-4.5-20101209 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101209/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 167668

You'll find:

 gcc-4.5-20101209.tar.bz2 Complete GCC (includes all of below)

  MD5=85b43d39084f0d0e381e9c65b658cf4b
  SHA1=7fa12ee33bcbdaa72c013cd4eab9c5abb066afd5

 gcc-core-4.5-20101209.tar.bz2C front end and core compiler

  MD5=e7f26a26764b87c7bb7dd0ffc2afd67c
  SHA1=5528f027446ac819016a23111efdaa1eb47581a0

 gcc-ada-4.5-20101209.tar.bz2 Ada front end and runtime

  MD5=9ffd6c8367f5dc43d8efe8bf3babcda9
  SHA1=4cd222ce9a2d7066c1af870a9c3a65d59f96aee7

 gcc-fortran-4.5-20101209.tar.bz2 Fortran front end and runtime

  MD5=e0c7d09677c346562bf82298787ea387
  SHA1=091e5ff4ad58561cfd0eda8ae152a7b5f4e3ff8f

 gcc-g++-4.5-20101209.tar.bz2 C++ front end and runtime

  MD5=79df01ddf6f966e9c1fca83d46783863
  SHA1=c63ecf3157fa2e7f956f5e5fed03600eb1aa5818

 gcc-java-4.5-20101209.tar.bz2Java front end and runtime

  MD5=a451d0832a84b811cd795091693b556c
  SHA1=d4283fbf48f58525c901b3162e29fc6dc7eeb7a9

 gcc-objc-4.5-20101209.tar.bz2Objective-C front end and runtime

  MD5=66afc1c7d0f18b74c4db832d006a1c63
  SHA1=829e5c5e4dabaaa99867ea33a8c30235a449a8e7

 gcc-testsuite-4.5-20101209.tar.bz2   The GCC testsuite

  MD5=60faa754e0d6dd9a1f79b072dba7c592
  SHA1=2b48bc7a03410caae7b953d284ff2de42c889fd8

Diffs from 4.5-20101202 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: v2: plugin to warn about surplus includes

[Ian Lance Taylor]

Michalis Giannakidis  writes:

> I am trying your plugin to  to warn about surplus includes:
> http://gcc.gnu.org/ml/gcc/2010-05/msg00418.html

You should probably e-mail Bernhard Reutner-Fischer, who wrote the
plugin.

> I have some problems compiling against gcc v4.5.1.
>
> ~/local/gcc-4.5.1/bin/g++ -I`~/local/gcc-4.5.1/bin/gcc
> -print-file-name=plugin`/include -fPIC -shared -O2 rm_includes.cpp -o
> plugin.so

By naming the plugin rm_includes.cpp you are compiling it as a C++
file.  That is probably not what you want to do.

Ian

Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org

[Richard Guenther]

On Thu, 9 Dec 2010, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> > The branch remains frozen and all checkins until after the final release
> > of GCC 4.5.2 require explicit RM approval.
> 
> I'd like to get the following three testsuite-only patches into the
> branch if possible:
> 
>   [v3] Don't create unlinkable 64-bit libtestc++.a on IRIX 6
> http://gcc.gnu.org/ml/libstdc++/2010-11/msg00165.html
>   http://gcc.gnu.org/ml/libstdc++/2010-12/msg00058.html
> 
>   [libgomp] Link libgomp with -lpthread on IRIX 6
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02931.html
> 
>   [libffi, testsuite] Provide PRIuPTR, PRI[du]64 for IRIX 6.5
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02547.html

They can wait until after the 4.5.2 release.

Thanks,
Richard.

Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org

[Rainer Orth]

Richard Guenther  writes:

> The branch remains frozen and all checkins until after the final release
> of GCC 4.5.2 require explicit RM approval.

I'd like to get the following three testsuite-only patches into the
branch if possible:

[v3] Don't create unlinkable 64-bit libtestc++.a on IRIX 6
http://gcc.gnu.org/ml/libstdc++/2010-11/msg00165.html
http://gcc.gnu.org/ml/libstdc++/2010-12/msg00058.html

[libgomp] Link libgomp with -lpthread on IRIX 6
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02931.html

[libffi, testsuite] Provide PRIuPTR, PRI[du]64 for IRIX 6.5
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02547.html

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: v2: plugin to warn about surplus includes

[Michalis Giannakidis]

Hello,

I am trying your plugin to  to warn about surplus includes:
http://gcc.gnu.org/ml/gcc/2010-05/msg00418.html

I have some problems compiling against gcc v4.5.1.

~/local/gcc-4.5.1/bin/g++ -I`~/local/gcc-4.5.1/bin/gcc
-print-file-name=plugin`/include -fPIC -shared -O2 rm_includes.cpp -o
plugin.so

 ~/local/gcc-4.5.1/bin/g++ -fplugin=./plugin.so test_rm_includes.cpp
-o test_rm_includes
cc1plus: error: Cannot load plugin ./plugin.so
./plugin.so: undefined symbol: _Z14linemap_lookupP9line_mapsj

 nm -C plugin.so
00201dc8 a _DYNAMIC
00201fe8 a _GLOBAL_OFFSET_TABLE_
 w _Jv_RegisterClasses
 U warning_at(unsigned int, int, char const*, ...)
 U fancy_abort(char const*, int, char const*)
1400 T handle_struct(void*, void*)
 U linemap_lookup(line_maps*, unsigned int)
<-

Could you please instruct me of what I should link against to get
linemap_lookup ?


Thank you,
--
Michalis Giannakidis
http://mgiannakidis.blogspot.com

Re: "ld -r" on mixed IR/non-IR objects (

[Andi Kleen]

On Thu, Dec 09, 2010 at 02:34:27AM +, Dave Korn wrote:
> On 08/12/2010 18:40, Andi Kleen wrote:
> 
> > Fat LTO is just too slow. I suspect with that kind of performance
> > penalty most people simply would not use it at all.
> 
>   How slow is "too" slow?  How many people out of a hundred won't use it?  Got
> numbers, or just a gut feeling?

I didn't do a survey if that's what you're asking.

It depends on what tree you use. Before Honza's rebalancing fixes
it was really bad, especially with the tendency to run out of memory
on a 3-4GB system and swap a lot (or generate too many temporary files 
and when you use tmpfs in ram that amounts to the same)

There were also some problems that I had to limit parallelism
below what my machine could do to run out of memory, but that also got 
better in mainline.

Anyways with a recent 4.6 saw slowdowns in compilation of ~2.5x
which is imho too slow. If it was < 1.5x or so things would be
more acceptable I think, especially if the resulting code
is significantly better.

I believe Honza's gcc summit paper has more numbers:

There seem to be also some other bottlenecks currently,
like too much redundant information in the LTO files,
which causes too much IO time.

I haven't done detailed numbers again, but I expect slim LTO
and when the other problems are fixed to be significantly 
faster and have a chance to be below 1.5. There's still
some work to be done in all of these areas.

The memory consumption issue probably also
still needs some work, right now it's still too easy
to start swapping.

With slim LTO there's also some other avenues of speeding
up available, for example it would be pretty simple to not
call the assembler for the LTO generating stages but
just write object files directly. I'm not fully sure
how much this would buy.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.