Steven Bosscher writes:
> On Tue, Nov 29, 2011 at 6:04 PM, Georg-Johann Lay wrote:
>> I attached a patch but I fail to find the right configure options for
>> gcc/binutils as the testsuite complains
>>
>> ./avr/bin/ld: bad -plugin option
>>
>> Configured gcc with --enable-lto and binutils 2.21 w
On Tue, Nov 29, 2011 at 6:04 PM, Georg-Johann Lay wrote:
> I attached a patch but I fail to find the right configure options for
> gcc/binutils as the testsuite complains
>
> ./avr/bin/ld: bad -plugin option
>
> Configured gcc with --enable-lto and binutils 2.21 with --enable-plugin.
Huh, wait. I
> "David" == David Malcolm writes:
David> I maintain gcc-python-plugin [1]. I'm hoping to expose the function
David> decl_as_string() from the C++ frontend from within my plugin.
I think this problem was discussed before, either here or on
gcc-patches, I forget.
David> (b) somehow set thin
On Wed, 2011-11-30 at 15:06 -0500, David Malcolm wrote:
[...snip...]
> Any thoughts on how to address this? Are there any other approaches
> I've missed?
Answering my own question, Dave Korn pointed out in another thread:
http://gcc.gnu.org/ml/gcc/2011-01/msg00310.html
that one can use dlsym()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/30/11 13:06, David Malcolm wrote:
> Any thoughts on how to address this? Are there any other
> approaches I've missed?
Does print_decl do what you need?
jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG
On Wed, Nov 30, 2011 at 15:06, David Malcolm wrote:
> Any thoughts on how to address this? Are there any other approaches
> I've missed?
Why not use a langhook? We do this for lang_hooks::decl_printable_name.
Diego.
I maintain gcc-python-plugin [1]. I'm hoping to expose the function
decl_as_string() from the C++ frontend from within my plugin.
Unfortunately, given that that symbol is defined within gcc/cp/error.c,
it is only defined within the C++ frontend: cc1plus. This works OK when
my plugin is dynamical
Libstdc++-v3 use to provide a locked implementation of classes for sizes
which didn't have lock-free support. That was removed for this release
as it caused a program compiled with a specific version of GCC to be
locked into that implementation. The design criteria for the new
__atomic builti
Hi, Joey, thanks!
The detail is here (should be included in my original post):
https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU/edit?hl=en_US
-Han
On Tue, Nov 29, 2011 at 10:44 PM, Ye Joey wrote:
> On Wed, Nov 30, 2011 at 7:53 AM, Han Shen(沈涵) wrote
Georg-Johann Lay writes:
> If general_operand can be perceived as
>
> (define_predicate "general_operand"
>(ior (match_operand 0 "memory_operand")
> (match_operand 0 "register_operand")
> (match_operand 0 "immediate_operand")))
>
> how can low_io_mem ever match?
Oh, I see, I
Georg-Johann Lay writes:
> I just can't find the right configure options to get the LTO stuff
> work, i.e. how to enable plugins in binutils and LTO in gcc.
For binutils: configure with --enable-plugins (note: not
--enable-plugin).
For gcc: should be on by default, or configure with --enable-lt
Denis Chertykov wrote:
2011/11/29 Georg-Johann Lay:
I attached a patch but I fail to find the right configure options for
gcc/binutils as the testsuite complains
./avr/bin/ld: bad -plugin option
Configured gcc with --enable-lto and binutils 2.21 with --enable-plugin.
Maybe the patch can be
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
Is insn combine allowed to match the insn because from combine's
perspective just a CONST_INT (i.e. low_io_address_operand) is moved
across the access of UDR0?
Yes.
Or is this a bug in insn combine?
No.
If combine is right -- and thus the
13 matches
Mail list logo
