On Sat, Oct 7, 2023 at 3:08 PM Hanke Zhang via Gcc wrote:
>
> Hi, I've recently been working on static local variables in C. I would
> like to ask about some questions about that.
>
> For example, for the following program,
>
> void foo() {
> static int x =
Hi, I've recently been working on static local variables in C. I would
like to ask about some questions about that.
For example, for the following program,
void foo() {
static int x = 0;
x++;
}
int main() {
foo();
}
After optimization with the -O3 -flto option, the entire program
> On Wed, Jun 14, 2017 at 1:14 PM, Prachi Godbole
> wrote:
> > I'm developing a solution to optimize away intermediate stores (loads) for
> static local variables which are assigned to before referenced on every path
> through a function.
> >
> > Currently G
On Wed, Jun 14, 2017 at 1:14 PM, Prachi Godbole
wrote:
> I'm developing a solution to optimize away intermediate stores (loads) for
> static local variables which are assigned to before referenced on every path
> through a function.
>
> Currently GCC eliminates all loads/
On Wed, Jun 14, 2017 at 12:14 PM, Prachi Godbole
wrote:
> I'm developing a solution to optimize away intermediate stores (loads) for
> static local variables which are assigned to before referenced on every path
> through a function.
>
> Currently GCC eliminates all loads/
I'm developing a solution to optimize away intermediate stores (loads) for
static local variables which are assigned to before referenced on every path
through a function.
Currently GCC eliminates all loads/stores in a straight line code but not in
control structures. AFAIU, passes like
Hi, I'm trying to implement *inherited* thread-local C++ variables.
These are are per-thread values, like regular thread-local variables,
with one twist: the value in a new thread is copied from the value in
the parent thread, instead of being set to its default value.
Everything is workin
Hi,
I'm (still) working on a new gcc-4.5.2 backend for a private processor.
Today i'm concerned about the debug mode using DWARF2.
Here is my problem:
When I use GDB on a executable compiled with -g option I notice that the
addresses of all my local variables are wrong.
I read gcci
Hi,
If you look at them more closely, you will see that the two different
macro's give different answers to the same problem.
If you like, I will retry at gcc-h...@gcc.gnu.org, although I suppose
binut...@sourceware.org should be having a copy too.
Thanks,
Mischa.
On 10/13/2012 02:03 AM, J
On 12 October 2012 22:43, Mischa Baars wrote:
> Hi All,
>
> Who can take a first look at this in the morning?
Hi,
I looked, they seem to be some files. Nice.
If you want people to look at them properly you should probably send
them to the gcc-help list and explain why you want people to look at
Hi All,
Who can take a first look at this in the morning?
Thanks,
Mischa.
function.o: file format elf64-x86-64
Disassembly of section .text:
:
0: c3 ret
function.o: file format elf64-x86-64
Disassembly of section .text:
0
you did, and run it under gdb, I can print all the
local variables throughout the function.
So I think you should bring this up with the kdbg developers for more
information.
Ian
al variable until I execute the line:
memset(tmpspec,0,300);
After executing this line, kdbg displays all of the local variables. I
have noticed previously that kdbg omits some local variables in the
'locals' window. That behaviour may (is probably?) related to this
behaviour also.
weixing ji writes:
> I am writing a plugin which is invoked at the event
> "PLUGIN_OVERRIDE_GATE". My question is how to access all the local
> variables of a function if I get a FUNC_DECL tree node. I have tried
> as following:
> for(block = DECL_INITIAL(fn_decl);
hi,
I am writing a plugin which is invoked at the event
"PLUGIN_OVERRIDE_GATE". My question is how to access all the local
variables of a function if I get a FUNC_DECL tree node. I have tried
as following:
for(block = DECL_INITIAL(fn_decl); block; block = TREE_CHAIN(block))
{
Jérémie Salvucci writes:
> I am trying to get an access to local variables of a function thanks
> to the GIMPLE representation. When I read the dump file after the CFG
> pass, I can see a new temporary variable added. For example with the
> identity function I would like to get an a
s duplicates.
>
> Nenad
>
> On 7/8/10 7:33 PM, asmwarrior wrote:
>>
>> I have post this message to both GCC and GDB, because I'm not sure it is
>> a bug in GDB or GCC.
>> Hi, I have just find two dwarf debug entries f
On 2010-7-9 13:58, Nenad Vukicevic wrote:
I reported something similar back in January:
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
As I recall, GCC creates duplicates.
Nenad
Thanks for the reply. I also found your message,
This bug has been fixed,see:
http://gcc.gnu.org/bugzilla/show_
find two dwarf debug entries for one local variables.
For example, the sample code is just like:
-
wxString ParserThread::ReadAncestorList()
{
wxString ccc;
wxString templateArgument;
wxString aaa;
aaa = m_Tokenizer.GetToken(); /
I have post this message to both GCC and GDB, because I'm not sure it
is a bug in GDB or GCC.
Hi, I have just find two dwarf debug entries for one local variables.
For example, the sample code is just like:
-
wxString ParserThread::ReadAncesto
Hello all,
I am trying to get an access to local variables of a function thanks to
the GIMPLE representation. When I read the dump file after the CFG pass,
I can see a new temporary variable added. For example with the identity
function I would like to get an access to the uid of this
On 2010-6-20 14:18, Ian Lance Taylor wrote:
asmwarrior writes:
My question is: Is there any possible that GCC can emit some debug
information to indicate that one variable is initialed or not.(at
least in the DEBUG build mode)
You didn't mention which version of gcc you are testing.
I add the "-fvar-tracking" option, there will have debug
information included. Then, GDB can use this information to avoid to
print the uninitialized local variables?
Thanks.
Asmwarrior ollydbg from codeblocks' forum.
asmwarrior writes:
> My question is: Is there any possible that GCC can emit some debug
> information to indicate that one variable is initialed or not.(at
> least in the DEBUG build mode)
You didn't mention which version of gcc you are testing. With current
gcc see if the -fvar-tracking option
tring");
stdStr.append(" value");
std::map m;
m[0] = "000";
m[1] = "111";
}
If I set a breakpoint in the first line of test function, and send
command "info local" to gdb, then gdb get crashed. That is because GDB
regard every local va
Basile STARYNKEVITCH wrote:
I'm not sure to understand the meaning of "MELT GC being incompatible
with GGC one". On the contrary, it is designed to be compatible, it is
compatble in practice, and it works quite well.
If an ggc_collect_with_local scheme is not possible (but I repeat that I
Richard Guenther wrote:
On Mon, Oct 13, 2008 at 7:23 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
Hello All,
Andrew Pinski wrote:
On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
Hello All,
I am sometimes wishing to be able to scan so
On Mon, Oct 13, 2008 at 7:23 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Hello All,
>
> Andrew Pinski wrote:
>>
>> On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Hello All,
>>
Hello All,
Andrew Pinski wrote:
On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
Hello All,
I am sometimes wishing to be able to scan some few local variables in GCC
garbage collector, GGC.
The only time I can think of when you want to do that is wh
On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Hello All,
>
> I am sometimes wishing to be able to scan some few local variables in GCC
> garbage collector, GGC.
The only time I can think of when you want to do that is when the pass
creat
Hello All,
I am sometimes wishing to be able to scan some few local variables in
GCC garbage collector, GGC.
One could imagine, for instance, that some passes would prefer, instead
of using static GTY-ed variables, to declare some local GTY-ed structure
LS , and to explicitly invoke the GGC
Well, you are right. The code looks good and works also. But I have some
kind of a reference implementation which is based on GCC 2.7.2.3. In
this version the local variables are allocated the other way around, the
way in which I expected. Obviously, the order of allocation has changed
till now
Robert Dewar writes:
> Markus Franke wrote:
>
> > Please let me know whether I missunderstood something completely. If
> > this behaviour is correct what can I do to change it to the other way
> > around. Which macro variable do I have to change?
>
> There is no legitimate reason to care a
Markus Franke wrote:
Please let me know whether I missunderstood something completely. If
this behaviour is correct what can I do to change it to the other way
around. Which macro variable do I have to change?
There is no legitimate reason to care about the order of variables
in the local stac
Dear GCC Developers,
I am working on a target backend for the DLX architecture and I have a
question concerning the layout of the stack frame.
Here is a simple test C-program:
---snip---
int main(void)
{
int a = 1;
int b = 2;
int c = a + b;
return c;
}
---snap---
On 12/13/06, Sandeep Kumar <[EMAIL PROTECTED]> wrote:
Hi all,
I tried compiling the above two programs :
on x86, 32 bit machines.
[EMAIL PROTECTED] ~]# gcc test.c
Try with optimization enabled (try -O1 and/or -O2).
Gr.
Steven
.
How actually is teh memory allocated by gcc for local variables.
Kindly help.
int main()
{
char x;
return 0;
}
[EMAIL PROTECTED] ~]# gcc test.c
[EMAIL PROTECTED] ~]# objdump -S a.out | less
08048348 :
8048348: 55 push %ebp
8048349: 89 e5
Ian Lance Taylor wrote:
You neglected to mention which version of gcc you were using, or which
target. The description and test case sound like GCC PR 9997:
http://gcc.gnu.org/PR9997
which was fixed for the 4.0 release.
Sorry, I'm using GCC 3.4.4, haven't tested on 4.0.X.
I saw the PR 9997,
Hanzac Chen <[EMAIL PROTECTED]> writes:
> Some idea: Maybe local stack use in the code compiled by GCC should be
> optimized 'cause some local variables are conditional. If the condition
> is not satisfied, then these variables don't need to be allocated from
> the sta
Hi,
Some idea: Maybe local stack use in the code compiled by GCC should be
optimized 'cause some local variables are conditional. If the condition
is not satisfied, then these variables don't need to be allocated from
the stack (e.g. sub $VAR_SIZE, %esp).
For example:
int *func(un
40 matches
Mail list logo
