Treatment of builtin that receives function pointer
Hi,
I have declared a builtin that receives a function pointer in gcc 4.3.4.
While handling the builtin I want to find the assembler name of the
function the pointer points to.
My current code works if the the function is a void (*)(void), but it
doesn't work for anything else and unfortunately, casting it won't
help.
The interesting part is that if when I handle the builtin, I call
debug_tree on the call_expr to the builtin.
With something like:
void foo(void) {...}
...
__mybuiltin(foo);
I get the following for call_expr:
arg 0
unsigned HI size unit size
align 16 symtab 0 alias set -1 canonical type 0xb7c5ebc8>
constant invariant
arg 0
addressable asm_written used public static decl_5 QI file
functionsize.c line 4 col 1 align 16 initial
result
(mem:QI (symbol_ref:HI ("foo") ) [0 S1 A16])>>
This works because I access arg0 and from the function_decl I get the
function name.
Now, if foo becomes:
void foo(int * x) { ... }
I get instead:
arg 0
unsigned HI size unit size
align 16 symtab 0 alias set -1 canonical type 0xb7c69bc8>
used unsigned ignored HI file functionsize.c line 18 col 5
size unit size
align 16 context
(reg/f:HI 21 [ foo?0? ])
chain
used unsigned ignored QI file functionsize.c line 18 col 5
size unit size
align 16 context
(reg:QI 20 [ D.1186 ]) chain >>
which doesn't contain any informtation regarding the name of foo...
Interestingly it contains an align 16 context function_decl main,
which is from where I am calling the builtin but I don't think this is
important.
Now, I wonder in this more general case, where can I obtain the
function decl (so I can get its assembler name) for the function the
pointer is pointing to?
Cheers,
--
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net
RE: Possible IRA bug in assign_hard_reg
Thanks for the detailed answer.
While we're on the subject of assign_hard_reg, I notice the costs and
min_cost variable are set but never used (decisions are being made with
the full_costs array and min_full_cost). Should they be referenced
somehow or are they just redundant?
Cheers,
Ian
> -Original Message-
> From: Vladimir Makarov [mailto:vmaka...@redhat.com]
> Sent: 21 January 2010 21:08
> To: Ian Bolton
> Cc: gcc@gcc.gnu.org
> Subject: Re: Possible IRA bug in assign_hard_reg
>
> Ian Bolton wrote:
> > Near the end of assign_hard_reg in ira-color.c, there is this code:
> >
> >
> > if (min_full_cost > mem_cost)
> > {
> > if (! retry_p && internal_flag_ira_verbose > 3 && ira_dump_file
> !=
> > NULL)
> > fprintf (ira_dump_file, "(memory is more profitable %d vs %d) ",
> > mem_cost, min_full_cost);
> > best_hard_regno = -1;
> > }
> >
> >
> > If retry_p is true then we are in reload, so I wouldn't expect us to
> > override best_hard_regno in this case. I think the code should
read:
> >
> >
> > if (min_full_cost > mem_cost && ! retry_p)
> > {
> > if (internal_flag_ira_verbose > 3 && ira_dump_file != NULL)
> > fprintf (ira_dump_file, "(memory is more profitable %d vs %d) ",
> > mem_cost, min_full_cost);
> > best_hard_regno = -1;
> > }
> >
> >
> > I'm probably wrong, but I wanted to check.
> >
> >
> The original code is ok, I think.
>
> First, retry_p is true not only from reload. It is true when we are
> trying to assign hard register after IR flattening during which new
> allocnos can be created to resolve cycles for register shuffling on
> region borders.
>
> If memory is more profitable we should use independently from where we
> call assign_hard_reg.
>
> Retry_p is used as guard for dump printing because it is a part of
dump
> when allocno is popped from coloring stack (in this case retry_p is
> false).
Obsoleting IRIX < 6.5, Solaris 7, and Tru64 UNIX < V5.1
I'd like to obsolete support for some older versions of IRIX, Solaris, and Tru64 UNIX which get increasingly difficult and time consuming to support. The plan is to obsolete them in the GCC 4.5 release and remove the support in GCC 4.6. That means that in GCC 4.5.x, an attempt to configure for those targets will fail like this: *** Configuration alpha-dec-osf4.0f is obsolete. *** Specify --enable-obsolete to build it anyway. *** Support will be REMOVED in the next major release of GCC, *** unless a maintainer comes forward. but it is still possible to override this by adding the --enable-obsolete option mentioned in the error message. No support will actually be removed in this release. The detailed plan is to obsolete support for the following versions: * IRIX before 6.5: ** IRIX 5.3 entered retired mode by the end of 1998. Patches are no longer available from support.sgi.com, and a full bootstrap and test cycle takes 8 1/2 days on the machines I have available, even without java/libgcj. ** IRIX 6.2 entered retired mode by 01/2003 and patches aren't available either. I don't have any machine available running that version. ** IRIX 6.3 and 6.4 were only ever released for specific hardware. ** With a few exceptions, all machines supported by IRIX 6.[2-4] are supported by IRIX 6.5, too (at least until 6.5.22). ** I also consider obsoleting support for the O32 ABI: the SGI linker used is different from the N32/N64 ld, and has repeatedly caused problems which couldn't be resolved even when SGI still had full IRIX support. Also, the ISO C99 support in libc is only available for the N32 and N64 ABIs. * Solaris 7: Solaris 7 isn't supported any more since 08/2008: http://www.sun.com/service/eosl/eosl_solaris.html I cannot test it either on bare metal nor in branded zones or (probably) xVM domUs. Given that Solaris 8, 9, 10, and 11 will continue to be supported, that should be enough reason to stop. * Tru64 UNIX before V5.1: ** Tru64 UNIX V4.0 ended prior-version support in 07/2007. The version has many standards conformance problems compared to V5.1, so it seems inappropriate to invest much more work here. ** Tru64 UNIX V5.0 was relatively short-lived; prior-version support already ended in 10/2003. I don't have any machines to test it on, and for all practical purposes, V5.1 should be an appropriate replacement. ** Since prior-version support for V5.1 and V5.1A has ended in 03/2004 resp. 07/2007, support for V5.1 effectively means V5.1B, though bugs affecting the other V5.1 releases will be considered. http://h30097.www3.hp.com/support.html I'd like to hear if this is causing massive problems for anyone, and especially to get comments on the obsoletion of the IRIX 6.5 O32 ABI support. I'll triage the bug reports for those obsoleted releases and try to fix them on the GCC 4.5 branch. A short overview of my maintenance activities and current projects is on http://www.cebitec.uni-bielefeld.de/~ro/gcc/ I'm currently looking for a hardware donation to at least speed up Tru64 UNIX V5.1 testing. Unless someone strongly objects and steps up to provide testing and bug fixing, I'll install a patch to enforce this within a week and announce it on the GCC 4.5 changes page. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Strange conversion to int64
Hey, I'm having a little trouble understanding the conversion gcc is
doing in a statement with the following types:
int64 = int32 * uint32
This is running on a 64bit machine with gcc (GCC) 4.4.2 20091027 (Red
Hat 4.4.2-7)
Following simple code snippet:
1 #include
2 #include
3
4 using namespace std;
5
6 int main(int argc, char* argv[])
7 {
8 int32_t neg = -1;
9 uint32_t mult = 64;
10
11 int64_t res = neg * mult;
12 int32_t res2 = neg * mult;
13
14 cout << res << endl << res2 << endl;
15
16 uint64_t mult64 = 64;
17
18 res = neg * mult64;
19 res2 = neg * mult64;
20
21 cout << res << endl << res2 << endl;
22
23 return 0;
24 }
with the output
4294967232
-64
-64
-64
When compiled it gives an understandable warning
main.cpp: In function ‘int main(int, char**)’:
main.cpp:19: warning: conversion to ‘int32_t’ from ‘uint64_t’ may
alter its value
still that operation will generate the output I expect.
Is there some strange casting rule that I'm not following properly?
cheers,
Tony
Re: Strange conversion to int64
Tony Bernardin writes: > Hey, I'm having a little trouble understanding the conversion gcc is > doing in a statement with the following types: This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for gcc developers. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. > int64 = int32 * uint32 According to the rules of the C++ language, this will convert the int32 to uint32, do a uint32 multiplication producing a uint32 result, and then zero extend the uint32 result to assign it to int64. This seems consistent with the output you reported. Ian
