On Tue, Mar 30, 2021 at 1:39 PM Erick Ochoa wrote:
>
> > If the global is module local we should initialize it with NULL, yes. If
> > it is
> > not module local it should be initialized with NONLOCAL (that's both what
> > should currently happen correctly - it's needed for non-field-sensitive in
> If the global is module local we should initialize it with NULL, yes. If it
> is
> not module local it should be initialized with NONLOCAL (that's both what
> should currently happen correctly - it's needed for non-field-sensitive init
> as well).
>
Awesome, thanks Richard! One more question:
n initialize a field? Like struct->field = function()?
initializers refers to static initializers (DECL_INITIAL) on global variables
which satisfy the property of being assemblyable by varasm but can
have some arbitrary GENERIC structure in their field initializers
(like address calculations
Else we'd have to parse arbitrary initializers. */
&& !(in_ipa_mode
&& is_global_var (decl)))
>From what I understand here the points-to analysis is explicitly not
using field sensitivity for global variables when in IPA. I am
wondering,
0) Is "i
On Mon, Jan 14, 2013 at 2:00 AM, Thomas Baier wrote:
> Dear list,
>
> I've just subscribed to the list and I hope this is the right place for
> the following question.
>
> The operating system I'd like to use gcc for (OS-9, for the curious)
> requires an ABI,
On Mon, 2013-01-14 at 08:00 +0100, Thomas Baier wrote:
> The operating system I'd like to use gcc for (OS-9, for the curious)
> requires an ABI, where global variables are only accessed through
> register indirect addressing. On the powerpc platform, r2 is used for
> indirect add
On Mon, Jan 14, 2013 at 10:03 AM, Eric Botcazou wrote:
>> The Mac OS 9 ABI is very similar to the AIX ABI. So you should be
>> able to start with the AIX ABI and go from there.
>
> Are you sure that you're talking about the same OS-9 as Thomas here?
Oh OS-9. Anyways it does sound more like the
> The Mac OS 9 ABI is very similar to the AIX ABI. So you should be
> able to start with the AIX ABI and go from there.
Are you sure that you're talking about the same OS-9 as Thomas here?
--
Eric Botcazou
On Sun, Jan 13, 2013 at 11:00 PM, Thomas Baier wrote:
> Dear list,
>
> I've just subscribed to the list and I hope this is the right place for
> the following question.
>
> The operating system I'd like to use gcc for (OS-9, for the curious)
> requires an ABI,
Dear list,
I've just subscribed to the list and I hope this is the right place for
the following question.
The operating system I'd like to use gcc for (OS-9, for the curious)
requires an ABI, where global variables are only accessed through
register indirect addressing. On the powerp
On 11/26/07, Andrew Ducore <[EMAIL PROTECTED]> wrote:
> since the 'a' function is mapped to the label "_Z1av". (compile with
> -S and look at the .s file.) This occurs even when the global variable
> isn't declared within an extern "C" {} block. Should non-'extern "C"
> {}' global variable names al
When using g++, one can get label conflicts in assembler code by using
specific names for globals that match up against functions. e.g.:
void a () {}
int _Z1av;
since the 'a' function is mapped to the label "_Z1av". (compile with
-S and look at the .s file.) This occurs even when the global varia
> We explicitly pull out initializers from variables that are:
> /* Pull out any truly constant values. */
> if (TREE_READONLY (rhs)
> && TREE_STATIC (rhs)
> && DECL_INITIAL (rhs)
> && valid_gimple_expression_p (DECL_INITIAL (rhs)))
>ret
On 7/18/07, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
Hi,
GCC currently doesn't bootstrap on s390x. The problem is that
gengtype is miscompiled and I suspect the fre - sccvn changes to be
the culprit.
When sccvn performs the depth-first search for uses it might reach
global variable definitio
Hi,
GCC currently doesn't bootstrap on s390x. The problem is that
gengtype is miscompiled and I suspect the fre - sccvn changes to be
the culprit.
When sccvn performs the depth-first search for uses it might reach
global variable definitions. If the global variable is initialized
with a value th
Hi,
I guess it's about the gcc version. Gcc 3.4.4 does put the zero'd
variables into bss section. But I'd like to know if the older one does
it too. Say 2.95.2 19991024 (release)?
Thanks again.
Eric.
On Dec 20, 2005 08:17 AM, Eric Fisher <[EMAIL PROTECTED]> wrote:
> >Yes for zero'd initialized variables, GCC puts them into BSS to say
> >space in the executable.
>
> Thanks. But, you say 'to say space in the executable'. I'm not clear
> what does it mean.
"save space".
Gr.
Steven
>Yes for zero'd initialized variables, GCC puts them into BSS to say
>space in the executable.
Thanks. But, you say 'to say space in the executable'. I'm not clear
what does it mean.
Eric.
On Dec 20, 2005, at 2:02 AM, Eric Fisher wrote:
Hello,
For such a program,
int a=0;
int main(void)
{
...
}
We will see the compiler put the variable 'a' into the bss section.
That means that 'a' is a non-initialized variable. I don't know if this
is the gcc's strategy.
Yes for zero'd initi
Hello,
For such a program,
int a=0;
int main(void)
{
...
}
We will see the compiler put the variable 'a' into the bss section.
That means that 'a' is a non-initialized variable. I don't know if this
is the gcc's strategy.
Happy Christmas.
Eric.
On Aug 29, 2005, at 5:34 AM, [EMAIL PROTECTED] wrote:
I'm trying to extract global variables from a set of c++ files. I
tried
using:
cp_namespace_decls(global_namespace);
But this returns a whole set of variables which I do not want to know
about now (i.e stdout, timezone, _ZTISt10ostrs
Hello,
I'm trying to extract global variables from a set of c++ files. I tried
using:
cp_namespace_decls(global_namespace);
But this returns a whole set of variables which I do not want to know
about now (i.e stdout, timezone, _ZTISt10ostrstream e.t.c)
How do I get rid of this excess or wh
Maybe this is responsible for part of PR21828?
I'd say this *is* PR21828: note that the variables whose
type is unknown are global variables in C code compiled
with -O2 ...
Oh, of course. I was confusing with the first part:
Run till exit from #0 mangle_macro_name ([snip
Paolo Bonzini wrote:
> Maybe this is responsible for part of PR21828?
I'd say this *is* PR21828: note that the variables whose
type is unknown are global variables in C code compiled
with -O2 ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
> Yes; in fact 'main' is even superfluous. Just compile
>
> int var;
>
> with -S -O2 -g on gcc 3.4 and 4.0 and look at the resulting
> assembler file, the difference is quite obvious ...
Maybe this is responsible for part of PR21828?
Paolo
On Mon, May 30, 2005 at 10:13:19PM +0200, Ulrich Weigand wrote:
> Andrew Pinski wrote:
>
> > You can reproduce it using:
> > static int i;
> > int main(void)
> > {
> >i += 3;
> >i *= 5;
> >return 0;
> > }
> >
> > and readelf and looking for the DW_TAG_variable tag.
>
> Yes; in fact '
Andrew Pinski wrote:
> You can reproduce it using:
> static int i;
> int main(void)
> {
>i += 3;
>i *= 5;
>return 0;
> }
>
> and readelf and looking for the DW_TAG_variable tag.
Yes; in fact 'main' is even superfluous. Just compile
int var;
with -S -O2 -g on gcc 3.4 and 4.0 and
, *no* debug info for global
variables
appears to be emitted at all.
I could not reproduce it with any of the following examples on
i686-pc-linux-gnu
with dwarf-2:
Never mind, gdb must use something else for variables.
You can reproduce it using:
static int i;
int main(void)
{
i += 3;
i
On May 30, 2005, at 2:59 PM, Ulrich Weigand wrote:
Hello,
we've just noticed a quite serious regression in debug info output
in GCC 4.0 over previous releases: when building with -funit-at-a-time
(which is on by default with -O2), *no* debug info for global variables
appears to be emitt
Hello,
we've just noticed a quite serious regression in debug info output
in GCC 4.0 over previous releases: when building with -funit-at-a-time
(which is on by default with -O2), *no* debug info for global variables
appears to be emitted at all.
The problem appears to be this piece of co
30 matches
Mail list logo
