Given the following,
static char const rcsid[] =
"$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $";
int main() {}
When compiled with GCC 3.4.3, at -O2, the ident string above will _not_
appear in the executable. This is apparently expected behavior.
However, interestingly,
gcc -fkeep-static-
> From: James E Wilson
> Sent: Tuesday, March 08, 2005 6:59 PM
[...]
>
> Try re-reading the docs. -fkeep-static-consts is the default. The
> purpose of this is that we don't perform this optimization at -O0
> normally, but if you use -fno-keep-static-consts, then we do. So this
> option can
Richard Stallman wrote (in part):
> What's the point of cross-jumping? It saves a certain amount of
> space; it has no other benefit. All else being equal, there's no
> reason not to do it. But cross-jumping abort calls interferes with
> debugging. That's a good reason not to do it.
t's get ri
The following paper provides some background on the difficulties
encountered with parsing C++:
http://citeseer.ist.psu.edu/irwin01generated.html
Abstract: C++ is an extraordinarily difficult programming language to parse.
The language cannot readily be approximated with an LL
or LR grammar (re
This usage of a null substitution came up while I was trying to use
this form of spec. for a different switch, but the following illustrates
the problem using the existing gcc compiler as built for Redhat Linux
running on an SGI Altix:
Given a spec of this form,
%{S:X} substitutes X, if the -S
Hello, using the 3.4.3 baseline on SGI MIPS3 Irix6.5,
I'm running into a problem where bad code is generated on a relatively
trivial program when both -funit-at-a-time and -foptimize-sibling-calls
is asserted. The nature of the failure is that the RTL optimizer
seems to get confused about what va
We use the feature of placing strings into the object file somewhat
differently.
We record configuration and compilation-related info. into strings which are
collesced into their own linkage section. A runtime component traverses
this
config. info. section to ensure that the various separately l
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Nathanael Nerode
> Sent: Monday, April 25, 2005 8:47 PM
[...]
>
> Actually, I was going to try to convince y'all to allow the *configury*
> to be put in the *configure* files. All of it. The current sc
> -Original Message-
> From: Matt Thomas
> Sent: Tuesday, April 26, 2005 10:42 PM
[...]
>
> Alas, the --disable-checking and STAGE1_CFLAGS="-O2 -g" (which I was
> already doing) only decreased the bootstrap time by 10%. By far, the
> longest bit of the bootstrap is building libjava.
>
> From: Mark Mitchell
> Sent: Friday, April 29, 2005 12:00 PM
>
> Now that GCC 4.0 is out the door, I've spent some time looking at the
> status of the 3.4 branch. As stated previously, I'll be doing a 3.4.4
> release, and then turning the branch over to Gaby, to focus
> exclusively on 4.0/4.1.
configuration: i386-redhat-linux (Redhat 9.2), gcc 3.3.6 ("make bootstrap" from
the sources), and gdb "(5.3post-0.20021129.18rh)" as well as gdb 6.3 (latest)
built from sources.
I'm working on some changes to GCC 3.4.3, which I've built using gcc 3.3.6.
The GCC (3.4.3) that I'm debugging is comp
>
> This works fine on gcc 3.4, however on gcc 4.0 it creates an error during
> optimization. According to my investigation, the error occurs when there is a
> division by a constant power of 2 which needs to be transformed into
> shifting.
> The error generated is:
>
> internal compiler err
Given a binary distibution of GCC, for example, built to install under
/usr/local, is it possible to configure and build the compiler in such a
way that a binary packaging method such as RPM can allow a user to specify
an alternate installation point (perhaps /opt, or even the user's home
director
Does the -static switch play any role during compilation, or is it
a link-only switch? A quick review of gcc.c, indicates that -static
may play a role on some targets:
/* %{static:} simply prevents an error message if the target machine
doesn't handle -static. */
However, the info documenta
>
> Yes, with recent versions of gcc you can move the entire tree around
> and the gcc driver will still be able to find the various internal
> executables and header files. [...]
Ian, thanks.
Which versions qualify as "recent" above? GCC 3.4, or 4.0, or both?
Is there any documentation on how
Ian Lance Taylor wrote (in part):
> In fact many targets compile code differently depending upon whether
> the code is to be put into a shared library or not, but this is
> controlled via options like -fpic, not -static.
Is it generally safe on all currently supported targets to assert -fno-pic
w
Ian Lance Taylor wrote (in part):
> Telling the dynamic linker about a dynamic libgcc is still a problem,
> but that is a problem whereever you put the compiler.
If I'm not interested in build a dynamically linked gcc, or building
libgcc and related libraries as dynamic libraries, can I simply as
I notice that while compiling with -stdc99 (which asserts flag_isoc99) that
the
compiler issues warnings by default when it detects that a function call
references
a function which has not been previously declared.
Although it is a useful warning, my copy of the C99 spec. seems to indicate
that
s
Joseph S. Myers wrote (in part):
> No prototype is different from no declaration at all. Implicit function
> declarations are not part of C99, so the code is in error in C99 mode.
OK, thanks. I (now) understand that the reference to a warning about a missing
protoype
does not apply. However,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Menezes, Evandro
> Sent: Friday, May 27, 2005 1:55 PM
[...]
>
> That's because the error is the same but symmetrical for sin and
> cos, so that, when you calculate the sum of their squares, one
> cance
As an occasional user of the Bugzilla database, I don't find it terrible to
use, though
it would be nice if there were an abbreviated interface that looked for the
sorts of
queries that users issue the most. These often-occurring queries might be best
determined
by saving a month's worth of que
>
> Next try documentation, installation. Talks about compiling again.
> Finally, at download, binaries I find what I want. Seeing as I suspect
> that is the link most people want when they first visit, it should
> perhaps be a little more obvious, and in the main body near the top?
Your scen
While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
cgraph_expand_function() calls the hook directly:
In cgraphunit.c:
/* Expand function specified by NODE. */
static void
cgraph_expand_function (stru
Currently, the default optimization level when building,
bootstrapping GCC is -O2.
We routinely build with --with-build-config='bootstrap-debug bootstrap-O3'
because we want to verify that our UPC changes don't affect the
compiler when built with full optimizations. We also build
with --enable-c
On 09/26/14 07:47:05, Andi Kleen wrote:
> One example of an existing autotuner is the gccflags tuner in opentuner.
Although dated, ACOVEA might offer up some ideas.
http://stderr.org/doc/acovea/html/acovea_4.html
On 01/14/15 23:15:59, Jeff Law wrote:
> Sounds good. I think just starting with the list & creating the buckets
> with the list. Then post here and we'll iterate and try to nail that down
> before you start moving everything in the .texi file.
Something to consider, if the optimization options a
Recently, we tried to merge the GCC trunk into the GUPC branch
and ran into an issue caused by a recent GCC update.
The last successful merge was trunk version 172359, fyi.
For certain UPC file scope static initializers,
a per file initialization routine is created, its address
is added to a glob
On 04/22/11 11:14:11, Richard Guenther wrote:
> GF: What is needed in the new scheme of things to ensure that this
> GF: initialization function stays in the call graph?
>
> Try setting DECL_PRESERVE_P to 1.
Richard, thanks. That worked.
- Gary
This email is a follow-up to an email with a similar title
(posted a year ago). During that time period, we have worked
on making the changes suggested by Joseph Myers, Tom Tromey,
and other reviewers. We have also implemented various bug fixes
and improvements.
Our goal with this RFC is to acqu
On 09/09/11 09:09:30, Jakub Jelinek wrote:
> [...] What is the status of lra, reload-2a, pph,
> cilkplus, gupc (I assume at least some of these are 4.8+ material)?
For GUPC, we are targeting GCC 4.8.
thanks,
- Gary
Two more suggestions (off-topic to the profiling point, but on
topic to the idea of speeding up builds involving invocations
of GCC):
ccache: http://ccache.samba.org/
"ccache is a compiler cache. It speeds up recompilation by caching
previous compilations and detecting when the same compilation i
On 12/06/11 01:18:28, Joseph S. Myers wrote:
> [...] It still seems reasonable to aim for
> entering Stage 4 (regression fixes and documentation changes only) in
> early January and the 4.7.0 release in March or April.
At what point in time would the GCC 4.7 branch be created,
and the trunk would
Recently, we have been working on upgrading GCC/UPC (see
http://gccupc.org) to the GCC trunk. Previously,
we've sync'ed with the latest stable release, but
now we want to stay more current.
When built with GCC versions 4.0 through 4.3, we used
the gimplify language hook, LANG_HOOKS_GIMPLIFY_EXPR
On 09/14/09 11:52:11, Richard Guenther wrote:
> Without reading all the details of your mail I suggest that you
> perform a custom walk over the function bodies right before
> the frontend calls cgraph_finalize_compilation_unit () that
> performs the necessary lowering (and function creation) to
>
Hello,
I'm trying to set up 'reghunt' to track down a change
in behavior from 2009-03-27 (4.4.3) to present. This is
my first time setting up 'reghunt' - it is quite possible
that I still haven't got things set up properly.
I think that I've got the SVN bits, and most of the config.
settings as
On 01/06/10 12:54:21, Ian Lance Taylor wrote:
> I think you need to make sure that the script removes any existing
> config.cache files.
Ian, thanks. This turned out to be a cockpit error on my part.
The reghunt tools apparently expect the checked out gcc source tree
to have the form /gcc; thus t
On 01/09/10 12:39:55, Nenad Vukicevic wrote:
> This dwarf code started appearing since this patch:
Here's the GCC bug report that led to this patch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
It references a GDB fix as well:
http://sourceware.org/ml/gdb-patches/2009-03/threads.html#00595
h
We use TLS relocated symbols to create thread-local symbols
in the GCC UPC compiler, and have run into an issue illustrated
by the following program, on a test case that defines a
common symbol in several files, and uses it in a single file.
The following program fails to link, with multiple defs:
On 01/13/10 17:15:10, Ian Lance Taylor wrote:
[...]
> Otherwise TLS variables are generated as definitions rather than as
> common variables.
>
> Why do you want them to be common?
For GCC/UPC compiled programs there are two compilation modes: 1) Each
UPC thread is implemented as a full process,
On 09/14/09 11:52:11, Richard Guenther wrote:
> > What approach would you recommend for the
> > implementation of UPC tree re-writes that will
> > support calls to the runtime (that are inlined,
> > if applicable)?
>
> Without reading all the details of your mail I suggest that you
> perform a cus
(I'm copying this thread back to the main GCC list, to
document the problem that we ran into, RG's suggestion
and the fix that we made.)
While merging our GCC/UPC implementation with
the GCC trunk, we ran into a situation where
some tests failed on the check shown below in
verify_gimple_assign_sin
On 01/14/10 08:26:31, Ian Lance Taylor wrote:
> Online I found this:
>
> http://www.faqs.org/docs/artu/c_evolution.html
>
> [T]he ANSI Draft Standard finally settled on definition-reference
> rules in 1988. Common-block public storage is still admitted as
> an acceptable variatio
We recently ran into this 'as' bug running
tests with the GCC (4.5 pre-cursor) "trunk" compiler
on an x86_64 target running Ubuntu 8.04:
http://sourceware.org/bugzilla/show_bug.cgi?id=10255
(the bug was marked fixed in June 2009).
The issue was noted in this GCC PR:
http://gcc.gnu.org/bugzilla/sho
A GCC front-end (and runtime) for UPC (Unified Parallel C) is available
via the following GCC branch: svn://svn/gcc/branches/gupc.
The GUPC project is described here: http://gcc.gnu.org/projects/gupc.html.
Over the course of this year, we plan to work with the GCC
development community with the g
Now that GCC 4.5 has been branched from the main line,
it seems that this is an appropriate time to consider
GUPC for inclusion into the GCC trunk.
GUPC was recently checked in as a GCC branch:
http://gcc.gnu.org/projects/gupc.html
What is the recommended process for having GUPC reviewed
(and hop
On 04/07/10 11:11:05, Diego Novillo wrote:
> I would suggest splitting patches across reviewer domains. See
> previous merges from big branches for examples. This makes it easier
> for maintainers and reviewers to review the relevant parts.
> Additionally, make sure that the branch bootstraps and
Although the dscussion regarding libstdc++-v3
is likely germaine to various developers who are
currently testing their changes and managing the
ports that they're responsible for, it seems that
this thread is venturing rather far from my
initial query.
I'm still wondering: Do GCC developers routin
(Configuration: x86_64, GCC 4.2.3 base line)
I've run into a problem where GCSE decides to kill a
conditional jump instruction because it thinks that the
result is always false. This happens when GCSE decides
to propagate a constant that is "narrowed" [the original
mode of the constant is word_mo
On 11/28/08 16:02:11, Gary Funck wrote:
>
> I'd think that somewhere in there gen_lowpart() needs to
> be called.
I posted a suggested patch:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01466.html
which fixes the reported problem.
On 11/29/08 10:37:33, Eric Botcazou wrote:
> > The conditional jump instruction formed by instructions
> > 56 and 57 above is deleted because GCSE thinks that
> > (reg:SI 61 [ p$thread ]) is non-zero. It comes to this
> > conclusion when it propagates the
> >REG_EQUAL (const_int 4294967296 [0x
On 11/29/08 14:45:49, Eric Botcazou wrote:
> > Agreed. The routine that creates the errant REG_EQUAL note is
> > lookup_as_function().
>
> Really? Doesn't it only retrieve a pre-existing REG_EQUAL note?
It retrieves an equivalent rtx constant, if it exists. Before the patch,
the constant that
On 12/01/08 11:50:48, Eric Botcazou wrote:
> > cse_insn() calls lookup_as_function() ultimately through fold_rtx(), IIRC,
> > and is the routine that writes the REG_EQUAL note.
>
> OK, thanks. But I'm a little at a loss as to why this problem arises only
> now: the problematic code in lookup_as_f
For UPC code generation, we're building an alternate
method of accessing thread-local data that does not depend upon
operating system support of the __thread qualifier.
The motivation for this change is that we've noticed that
__thread has varying levels of support across operating
system/hardwar
On 05/19/09 11:29:57, Andrew Pinski wrote:
> On Tue, May 19, 2009 at 11:25 AM, Gary Funck wrote:
> >
> > For UPC code generation, we're building an alternate
> > method of accessing thread-local data that does not depend upon
> > operating system support of the
On 05/19/09 12:10:43, Andrew Pinski wrote:
> Gary wrote:
> > Is the __thread feature now more universally/portably
> > supported?
>
> Yes, see emutls.c and the VAR_DECL case in expand_expr_addr_expr_1 and
> expand_expr_real_1 in expr.c.
> [...] for the emulated support which is
> implemented on th
Recently, I was debugging an issue in the GCC/UPC front-end
that related to some problems compiling specific UPC type
declarations. The front-end was, in certain cases, dropping
UPC's "shared" qualifier.
The relevant code is in grokdeclarator:
if (!flag_gen_aux_info && (TYPE_QUALS (element_typ
On 05/20/09 09:45:11, Joseph S. Myers wrote:
> On Tue, 19 May 2009, Gary Funck wrote:
>
> > That aside, I wonder if it is an error to drop the qualifiers
> > as shown above? In the case of UPC, for example, dropping qualifiers
>
> Please read the code (and comment) im
On 05/20/09 10:40:02, Richard Guenther wrote:
> Gary wrote:
> > Above, __emutls_get_address() is called twice, with
> > the same argument. I was surprised to see that the optimizer
> > (GCC 4.3.2) didn't notice this and use CSE to avoid the second
> > redundant call, because emultls_get_address is
On 05/20/09 17:13:23, Ian Lance Taylor wrote:
> Gary Funck writes:
>
> > Do you/others happen to know who is the maintainer of the
> > TLS emulation?
>
> [...] If you have found a bug, the fastest
> way to address is probably to file a bug report.
Doing a bit of rese
FYI, over the course of the next week/so, I will
post UPC-related changes to the gcc-patches
mailing list, for review. The goal is to make the
necessary fixes/changes, based upon review feedback,
that need to be made prior to merging the GUPC branch
into the GCC trunk.
Email describing the chang
Recently, I ran into a couple of bugs/regessions that show up
only if checking is enabled. This led me to the observation that
it might be useful if checking can be enabled at runtime via a
gcc command line switch. If this capability can be enabled by
default, then regression tests could depend u
Consider the following:
$ cat -n t.c
1
2 int A[10] = { 0 };
3
4 int main()
5 {
6A[10] = 10;
7A[-1] = -1;
8return 0;
9 }
In a compiler test case that I reviewed recently, there was the
expectation that the compiler would issue a compile-
On 10/07/10 21:24:18, Ian Lance Taylor wrote:
> -Warray-bounds, but that is one of the warnings which is unfortunately
> only available when optimizing. In this case it requires -O2.
Ian, thanks. I had thought optimization might be involved, but didn't try -O2.
> There was an attempt a couple o
On 10/03/10 12:03:44, Ian Lance Taylor wrote:
> You will need to try a sample implementation and see how much the
> compiler slows down and how much bigger it gets.
I began roughing out the required changes. This will be a background
project. If I can finish it to the point of running some timin
On 10/08/10 18:38:29, Basile Starynkevitch wrote:
> I am not an expert on these optimizations, but why would you want that?
I routinely compile/build with "-O0 -g3" because the code is easier to debug. I
also admit that I compile/build with "-O0" because it is faster than
"-O2" or "-O3" for exam
How about the following:
1) Default warnings are cheap, and work fine at -O0.
2) Expensive warnings (-Wall, -Warray-bounds, -Wuninitialized, -Wunused)
[not sure about the actual list] that require optimizations, will issue
a Warning when they are requested, but the appropriate optimization level
On 10/08/10 13:22:46, Ian Lance Taylor wrote:
> I think both of those alternatives would be surprising and easily
> misunderstood behaviour for many compiler users. [...]
I find the following behavior to be surprising:
$ gcc -Warray-bounds -O0 -c t.c
$ gcc -Warray-bounds -O1 -c t.c
$ gcc -Warra
On 10/08/10 18:38:29, Basile Starynkevitch wrote:
> I am not an expert on these optimizations, but why would you want that?
> The optimizations involved are indeed expensive (otherwise it would be
> -O1 not -O2), but once you asked for them, why only get warnings
> without the code generation impr
I've been looking at how GCC 4.0 handles "volatile" internally,
and may have a question/two on that later, but in the meantime,
I noticed some interesting differences in generated code that I
thought were a bit unusual, and was wondering if someone here
might explain why GCC behaves as it does, an
> From: Bernd Jendrissek
> Sent: Friday, May 05, 2006 12:50 AM
[...]
> Systems programmers should know better than to expect a particular
> implementation of volatile. :)
>
> How, for example, would you suggest GCC generate code for this?
>
> volatile int qwerty;
>
> void p()
> {
> printf("q
While following GCC's handling of 'volatile' and other type
qualifiers, I noticed that the gimplify pass created temporaries
with a type with 'volatile' asserted if the underlying type also
had 'volatile' asserted.
Temporaries are created by the create_tmp_var_raw() procedure
in gimplify.c, which
Given,
1 volatile int jv;
2
3 int main ()
4 {
5++jv;
6 }
GCC (development branch, 4.0 and up) creates a tree
node for the expression ++jv that has 'volatile' asserted
in the type associated with the expression:
unit size
align 32 symtab 0
Working with GCC 4.0.1, we're implementing an experimental dialect of C,
called UPC, which offers language extensions for parallel computing in
a distributed shared memory setting (see: http://intrepid.com/upc).
Generally, the work has proceeded well, and the language-specific callout
in gimpli
Consider the following program made up of two separate files:
==> file1.c <==
extern int x;
int main() {
x = 5;
}
==> file2.c <==
int __thread x = 10;
This will compile, link, and run on the IA64, but will fail at link time on
AMD64:
% gcc file2.c file1.c
/usr/bin/ld: x: TLS definition in /tm
Mike Stump wrote:
>
> This sounds like a bug that should be fixed. You should only need
> __thread on the extern if there was not a previous declaration for it.
>
The compiler seems pretty determined to enforce this restriction. Same
result
with 'const' instead of _thread:
int const x;
int mai
Andrew Pinski wrote:
> I would have hoped people actually read:
> http://gcc.gnu.org/onlinedocs/gcc/C99-Thread_002dLocal-Edits.html
>
> Which actually describes the edits to the C99 standard to how
> __thread is supposed to behave.
Thanks for the reference. Per that proposal, __thread is a
st
Seongbae Park wrote:
> That's the only platform I know of that doesn't require different
> sequence.
> Should we make the language rules such that
> it's easy to implement on one platform but not on the others,
> or should we make it such that it's easy to implement in almost
> all platforms ?
Pinski wrote:
> What about the following two sources:
> char t;
> ---
> extern int t;
> What should happen? According to the C standard this is invalid code but
> the compiler does not need to diagnose the problem.
Yup. Certainly a great way to re-use space across separately compiled
"C" source
Seongbae Park wrote:
> As I said, you're welcome to implement a new option
> (either a runtime option or a compile time configuration option)
> that will allow mixing TLS vs non-TLS.
In a way, we've already done that -- in an experimental dialact of "C"
called UPC. When compiled for pthreads, al
Seongbae Park wrote:
> In UPC, anything that's not TLS (or in UPC term, "private")
> is marked explicitly as "shared". So it's NOT trasparent in
> any sense of the word.
> See, you have two choices - either
> 1) make every global variable TLS by default and mark only
> non-TLS (UPC) or
> 2) vice
Given,
struct shared_ptr_struct
{
unsigned int phase : 24;
unsigned short thread : 16;
void *addr;
};
On the x86_64 (ie, Opteron[tm]) platform, GCC appears to designate the
underlying mode of this type as a BLKmode, instead of a TImode. This
has implications in terms of the qua
On the IA64, the following record,
typedef struct sptr_struct
{
long unsigned int phase: 48;
short unsigned int thread: 16;
void *addr;
} sptr_t;
is assigned a BLKmode rather a TImode, and I was wondering whether
this is a requirement of the IA64 ABI, or a coincidental result of
On 07/15/12 21:53:02, Jonathan Wakely wrote:
> [...]
> It took me a while to get back to this, but your suggestion worked,
> this patch allows bootstrapping to get past cp/lex.o, it hasn't
> finished yet so I haven't run the tests:
> [...]
> Presumably gengtype goes through directories alphabetical
I have been experimenting with the graphite optimizer, based on GCC trunk, and
cloog-isl. I started with the attached simple "C" program, which has this
basic structure.
#define N 2
int a[N][N], b[N], c[N];
[...]
for (i = 0; i < N; i++)
{
b[i] = i;
c[i] = i + N;
}
for
Would it be possible to define a new function
attribute that transparently adds two parameters
for file name and line number? Or that etablishes
a binding between this information and existing
parameter names? This might be useful for regular
"C" programs as well.
void do_something (T1 t1, T2 t
Or no explicit parameters at all ...
void do_something (T1 t1, T2 t2) __attribute__ ((caller_info));
All this will do (with appropriate compilation switches
and/or pre-defined macros) is pass one/more hidden
arguments, which in turn can be accessed in the
function body via a built-in function.
#
We have the need to generate code that initializes
certain variables and runtime-related values with
expressions that can't be evaluated statically
at compile-time. One method to do this, would be
to create an __attribute__ ((constructor)) function
that contains statements which initialize the
val
We are in the process of updating GCC/UPC's support for
the UPC dialect of C to version 4.2.0 of GCC.
GCC/UPC is described here: http://www.intrepid.com/upc.html
Generally, things are working. However, at the moment,
all tests fail when optimizations are enabled.
For example:
test00.upc:35: inte
On Sat, Sep 01, 2007 at 01:43:37PM -0400, Diego Novillo wrote:
>
> Have you considered using the data sharing machinery in OpenMP? We
> simply create a data structure holding all shared variables, allocate
> that in shared memory and re-write all references to shared variables
> as dereferences t
Background: GCC 4.2.0 base line + mods for UPC dialect. Problem below
is probablly a result of the UPC mods and not something
inherent in GCC 4.2.0. Although the test cases that I ran
pass at -O2, some fail when the value of THREADS (the number
of parallel threads in the application) is set to th
On Mon, Sep 24, 2007 at 09:36:25AM -0400, Diego Novillo wrote:
> On 9/23/07, Gary Funck <[EMAIL PROTECTED]> wrote:
>
> > The operand, op:
> >
> > (gdb) p op
> > $49 = 0x2e1ebc60
> > (gdb) pt
> >
> This symbol was not marked for renaming a
Diego, a bit more info. It seems that gimplify_operand
is being called in the rewrite_uses pass of
tree-ssa-loop-ivopts.c. gimplify_operand() is working
on this expr:
unit size
align 32 symtab 0 alias set -1 precision 32 min max >
constant invariant
arg 0
c
While working on UPC, we ran into an interesting problem
where if -O1 is enabled, and -funit-at-a-time is disabled
(which is not the default configuration) a static variable
declaration was not emitted by the assembler. I haven't
quite worked out why this is the case, but reading the
code did not
On Mon, Oct 08, 2007 at 02:50:06PM -0700, Janis Johnson wrote:
>
> Might this be related to http://gcc.gnu.org/PR33645?
Possibly. We think that we saw a problem rebuilding one of
the math functions in libgcc2 at -O2 with unit-at-a-time
disabled, that resulted in a compilation failure. Since
that
On Thu, Oct 18, 2007 at 11:42:52AM +1000, skaller wrote:
>
> DO you know how thread local variables are handled?
> [Not using Posix TLS I hope .. that would be a disaster]
Would you please elaborate? What's wrong with the
POSIX TLS implementation? Do you know of any studies?
I ask, because we
95 matches
Mail list logo
