For some analysis I am doing, I need to determine if a particular SSA_NAME_VAR
node is pointed-to by a function argument. I am iterating across the function's
arguments via DECL_ARGUMENTS(), but each argument is just a DECL node, and
contains no associated points-to data, as far as I can tell. I
Hi,
> The hard part is not getting the information at compile time. The
> information is readily available after register allocation. Heck, you
> can see right in the dump files; e.g., use -da when you compile and look
> at the pro_and_epilogue dump file.
I am glad to hear that news. Thanks,
Hi,
> The hard part is not getting the information at compile time. The
> information is readily available after register allocation. Heck, you
> can see right in the dump files; e.g., use -da when you compile and look
> at the pro_and_epilogue dump file.
Can I dump other information such as
On Tue, May 17, 2011 at 10:10 AM, Matt Davis wrote:
> For some analysis I am doing, I need to determine if a particular SSA_NAME_VAR
> node is pointed-to by a function argument. I am iterating across the
> function's
> arguments via DECL_ARGUMENTS(), but each argument is just a DECL node, and
>
陳韋任 writes:
>> The hard part is getting that information to be available at runtime.
>
> The easiest way is saving that information on the disk. Or I can use
> `objcopy` to insert the information to the executable. The binary
> translator can read that information at runtime.
>
> I guess what
Hello,
I'm currently writing a gcc backend for a microcontroller architecture which
can only handle indirect memory accesses.
In normal cases all works fine, but there is a special case where the reload
pass (<- not sure) produces a direct memory access in -O2 optimization mode
which causes the
On 05/16/2011 05:00 PM, Pat Haugen wrote:
I'm seeing some odd behavior in ira for PowerPC, starting with the big
ira merge best I can tell (r171649).
void foo(float *f1, float*f2) {
*f1 = *f2;
}
If I compile with gcc -S -m64 -O3 -mcpu=power7 and look at the ira
dump, I see that the pseudo u
Camo Johnson writes:
> So NOW it is a direct store operation. And the compiler crashes with the
> following error message:
>
> ../uart2sim/uart2i_3.c: In Funktion »main«:
> ../uart2sim/uart2i_3.c:307: Fehler: Befehl erfüllt nicht seine Bedingungen:
> (insn 44 41 45 4 ../uart2sim/uart2i_3.c:272 (
On 05/17/2011 11:07 AM, Vladimir Makarov wrote:
Thanks for pointing this out, Pat. Your patch could fix this particular problem
but using GENERAL_REGS only is wrong. The final allocno class should be
NON_SPECIAL_REGS. I will search for a better solution. Unfortunately, such
changes in the cod
Hi,
I¹m not sure if this have been dealt with or not, but I happen to be
thinking about it at the moment and wanted to say something before I forget.
There is as situation in which I believe an improvement is needed:
Regarding all the scanf functions reading long values
(sscanf,fscanf,scanf,... etc
Hi,
Has anyone compiled netbeans with gcj?
If so, can you please post your method?
Thanks,
Sean
Sean Robert McGuffee writes:
> Regarding all the scanf functions reading long values
> (sscanf,fscanf,scanf,... etc...).
I'm sorry, this is the wrong mailing list. gcc is just the compiler.
Functions like sscanf, fscanf, scanf are part of the C library. gcc
does not provide a C library.
In an
Sean Robert McGuffee writes:
> Has anyone compiled netbeans with gcj?
> If so, can you please post your method?
The mailing list gcc@gcc.gnu.org is for discussions related to the
development of gcc itself. Questions like this should go on the mailing
list gcc-h...@gcc.gnu.org. Or, in this case
Snapshot gcc-4.4-20110517 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110517/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
14 matches
Mail list logo
