Hello all,
While going through the RTL dumps, I noticed a few things which i need
to get clarified.
Below is the extract, in which i get the doubt.
(insn 106 36 107 6 (set (reg:SI 13 a5)
(const_int -20 [0xffec])) 17 {movsi_short_const} (nil)
(nil))
(insn 107 106 108 6 (parallel [
I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
returning values through a void ** argument. As far as I can tell, this
doesn't actually cause any problems, but gcc 4.1 with -Wstrict-aliasing
will complain. For example, take these two separate source files:
alias1.c
On 11/10/06, Howard Chu [EMAIL PROTECTED] wrote:
I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
returning values through a void ** argument. As far as I can tell, this
doesn't actually cause any problems, but gcc 4.1 with -Wstrict-aliasing
will complain. For example, take
On 10 November 2006 07:13, Ian Lance Taylor wrote:
DJ Delorie [EMAIL PROTECTED] writes:
I compared the generated code with an equivalent explicit test,
and discovered that gcc uses a separate rtx for the intermediate:
i = 0xf;
if (j = 16)
{
int i2;
i2 = i 8;
i = i2
On 10 November 2006 07:34, Brooks Moses wrote:
The Fortran front end currently has a lang.opt entry of the following form:
ffixed-line-length-
Fortran RejectNegative Joined UInteger
I would like to add to this the following option which differs in the
last character, but should be
Hi all,
Finally got the combined compare_and_branch instruction to work. But
it has some side effects while testing other files.
20010129-1.s: Assembler messages:
20010129-1.s:46: Error: Value of 0x88 too large for 7-bit relative
instruction offset
I just designed my compare and branch insn as
I have a test case (involving lots of new code that's not checked in yet)
that's blowing up with a nonlocal goto and I'm wondering how it ever worked
because it certainly appears to me that DECL_CONTEXT has to be copied
from label to new_label. But it isn't. So how are nonlocal gotos
working?
On 11/10/06, Mike Stump [EMAIL PROTECTED] wrote:
On Nov 9, 2006, at 6:39 AM, Mohamed Shafi wrote:
When i diff the rtl dumps for programs passing negative value with and
without frame pointer i find changes from file.greg .
A quick glance at the rtl shows that insn 95 tries to use [a4+4] but
Mike Stump wrote:
Now, what are the benefits and weaknesses between mine and your, you
don't have to carry around type_context the way mine would, that's a
big win. You don't have to do anything special move a reference to a
type around, that's a big win. You have to do a structural
Dave Korn [EMAIL PROTECTED] writes:
On 10 November 2006 07:13, Ian Lance Taylor wrote:
DJ Delorie [EMAIL PROTECTED] writes:
I compared the generated code with an equivalent explicit test,
and discovered that gcc uses a separate rtx for the intermediate:
i = 0xf;
if (j = 16)
Rohit Arul Raj [EMAIL PROTECTED] writes:
1. Does attribute length affect the calculation of offset?
It does if you tell it to. The length attribute must be managed
entirely by your backend. Most backends with variable size branches
use the length attribute to select which branch insn to
On 11/9/06, Mike Stump [EMAIL PROTECTED] wrote:
On Nov 8, 2006, at 5:59 AM, Doug Gregor wrote:
However, this approach could have some odd side effects when there are
multiple mappings within one context. For instance, we could have
something like:
typedef int foo_t;
typedef int bar_t;
On 10 November 2006 15:01, Ian Lance Taylor wrote:
In any case a '+' constraint doesn't make any difference this early in
the RTL passes. combine doesn't look at constraints.
bah, of course! Ignore me, I'll just go sit in the dunce's corner for a
while :)
cheers,
DaveK
--
Mohamed Shafi [EMAIL PROTECTED] writes:
(insn 94 91 95 6 (set (reg:SI 12 a4)
(mem/c:SI (reg:SI 12 a4) [0 D.1863+0 S4 A32])) 15 {movsi_load} (nil)
(nil))
(insn 95 94 31 6 (set (reg:SI 13 a5 [orig:12+4 ] [12])
(mem/c:SI (plus:SI (reg:SI 12 a4)
(const_int
Rohit Arul Raj [EMAIL PROTECTED] writes:
(insn 106 36 107 6 (set (reg:SI 13 a5)
(const_int -20 [0xffec])) 17 {movsi_short_const} (nil)
(nil))
(insn 107 106 108 6 (parallel [
(set (reg:SI 13 a5)
(plus:SI (reg:SI 13 a5)
On Thu, Nov 09, 2006 at 11:52:02AM -0800, Mike Stump wrote:
The way the instructions are numbered suggests that the code went
wrong before this point. You have to read and understand all the
dumps, whether they are right or wrong and why, track down the code
in the compiler that is
[EMAIL PROTECTED] (Richard Kenner) writes:
I have a test case (involving lots of new code that's not checked in yet)
that's blowing up with a nonlocal goto and I'm wondering how it ever worked
because it certainly appears to me that DECL_CONTEXT has to be copied
from label to new_label. But
Mark Mitchell [EMAIL PROTECTED] writes:
Though, if we *are* doing the template-repository dance, we'll have to
do that for a while, declare victory, then invoke the LTO front end,
and, finally, the actual linker, which will be a bit complicated. It
might be that we should move the invocation
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
Though, if we *are* doing the template-repository dance, we'll have to
do that for a while, declare victory, then invoke the LTO front end,
and, finally, the actual linker, which will be a bit complicated. It
might be that we
Hi,
I've been thinking that it would be a good idea to extend the current
__attribute__((format,..)) to use an arbitrary user callback.
I searched the mailing list archives and I found some references to similar
ideas. So do you think this is feasible?
It would allow specifying arbitrary
Nuno Lopes [EMAIL PROTECTED] writes:
I've been thinking that it would be a good idea to extend the current
__attribute__((format,..)) to use an arbitrary user callback.
I searched the mailing list archives and I found some references to
similar ideas. So do you think this is feasible?
I
On Fri, 10 Nov 2006, Ian Lance Taylor wrote:
I kind of liked this idea:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html
but of course it was insane.
I still think a higher level state machine as described in the followups
is how things should be done.
The first step (or the
Intel has published Core 2 Duo Optimization Reference Manual. I will
check in this patch to update wwwdocs.
H.J.
2006-11-10 H.J. Lu [EMAIL PROTECTED]
* readings.html: Update Intel64 and IA32 SDM website.
Index: readings.html
Richard Guenther wrote:
On 11/10/06, Howard Chu [EMAIL PROTECTED] wrote:
The program prints the expected result with both strict-aliasing and
no-strict-aliasing on my x86_64 box. As such, when/why would I need to
worry about this warning?
If you compile with -O3 -combine *.c -o alias it
I've been thinking that it would be a good idea to extend the current
__attribute__((format,..)) to use an arbitrary user callback.
I searched the mailing list archives and I found some references to
similar ideas. So do you think this is feasible?
I think it would be nice. We usually founder
On Fri, Nov 10, 2006 at 07:17:29AM -0800, Ian Lance Taylor wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
1. What could be the reason for this behavior?
I'm really shooting in the dark here, but my guess is that you have a
define_expand for movdi that is not reload safe.
And in case
On Fri, Nov 10, 2006 at 09:36:59AM -0800, H. J. Lu wrote:
Intel has published Core 2 Duo Optimization Reference Manual. I will
check in this patch to update wwwdocs.
I checked it in. You can find Core 2 Duo Optimization Reference Manual
at
On 08 Nov 2006 03:45:26 +0100, Gabriel Dos Reis
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Richard Kenner) writes:
| Like when int and long have the same range on a platform?
| The answer is they are different, even when they imply the same object
| representation.
|
| The notion of
Ian Lance Taylor [EMAIL PROTECTED] writes:
[...]
| I meant something very simple: for every type, there is a
| TYPE_CANONICAL field. This is how you tell whether two types are
| equivalent:
| TYPE_CANONICAL (a) == TYPE_CANONICAL (b)
| That is what I mean when I saw one memory dereference
Doug Gregor [EMAIL PROTECTED] writes:
[...]
| With concepts, there are cases where we end up creating two different
| type nodes that we later find out should have been the same type node.
| Here's an example:
|
| templatetypename T, typename U
| where LessThanComparableT SameTypeT, U
|
On 10 Nov 2006 19:15:45 +0100, Gabriel Dos Reis
[EMAIL PROTECTED] wrote:
Doug Gregor [EMAIL PROTECTED] writes:
| With concepts, there are cases where we end up creating two different
| type nodes that we later find out should have been the same type node.
| Here's an example:
|
|
On 10 November 2006 17:55, Rask Ingemann Lambertsen wrote:
On Fri, Nov 10, 2006 at 07:17:29AM -0800, Ian Lance Taylor wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
1. What could be the reason for this behavior?
I'm really shooting in the dark here, but my guess is that you have a
Doug Gregor [EMAIL PROTECTED] writes:
| On 10 Nov 2006 19:15:45 +0100, Gabriel Dos Reis
| [EMAIL PROTECTED] wrote:
| Doug Gregor [EMAIL PROTECTED] writes:
| | With concepts, there are cases where we end up creating two different
| | type nodes that we later find out should have been the same
Hi,
My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:
int f(short *p){
int sum, i;
sum = 0;
for(i = 0; i 256; i++){
sum += *p++ 0xFF;
}
return sum;
}
The RTL snippet of interest, before combine, is,
(insn 23 22
Doug Gregor [EMAIL PROTECTED] writes:
| On 08 Nov 2006 03:45:26 +0100, Gabriel Dos Reis
| [EMAIL PROTECTED] wrote:
| [EMAIL PROTECTED] (Richard Kenner) writes:
|
| | Like when int and long have the same range on a platform?
| | The answer is they are different, even when they imply the same
[EMAIL PROTECTED] wrote:
My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:
[snip]
I've only had a very quick look at your code, but I have a feeling that
this is an instance of the kind of slip-up with GO_IF_MODE_DEPENDENT_ADDRESS
On 10 Nov 2006 20:12:27 +0100, Gabriel Dos Reis
[EMAIL PROTECTED] wrote:
Doug Gregor [EMAIL PROTECTED] writes:
I don't see why you need to merge the types, as opposed to setting
their canonical types.
I have union-find on the mind, so I'm using the terms interchangeably.
Setting their
Doug Gregor [EMAIL PROTECTED] writes:
[...]
| | For instance, say we have built the types T* and
| | U* before seeing that same-type constraint. Now, we also need
| | TYPE_CANONICAL (T*) == TYPE_CANONICAL (U*).
| | And TYPE_CANONICAL(LessThanComparableT) ==
| |
I have run into a libstdc++ configuration issue and was wondering if it
is a known issue or not.
My build failed because the compiler I am using to build GCC and
libstdc++ does not have wchar support and does not define mbstate_t.
The compiler (and library) that I am creating however, do support
From: Mark Shinwell [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:
[snip]
I've only had a very quick look at your code, but I have a feeling
thatthis is an instance of the kind of
On Nov 9, 2006, at 11:09 PM, Ian Lance Taylor wrote:
I meant something very simple: for every type, there is a
TYPE_CANONICAL field. This is how you tell whether two types are
equivalent:
TYPE_CANONICAL (a) == TYPE_CANONICAL (b)
Ah, yes, that would work. Hum, so simple, why was I
Dave Korn wrote:
It may seem a bit radical, but is there any reason not to modify the
option-parsing machinery so that either '-' or '=' are treated interchangeably
for /all/ options with joined arguments? That is, whichever is specified in
the .opt file, the parser accepts either?
I
On Fri, 10 Nov 2006, Ian Lance Taylor wrote:
I kind of liked this idea:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html
but of course it was insane.
I still think a higher level state machine as described in the followups
is how things should be done.
wouldn't that be killing a
Ian Lance Taylor wrote:
This assumes, of course, that we can build an equivalence set for
types. I think that we need to make that work in the middle-end, and
force the front-ends to conform. As someone else mentioned, there are
horrific cases in C like a[] being compatible with both a[5]
Mike Stump [EMAIL PROTECTED] writes:
| On Nov 9, 2006, at 11:09 PM, Ian Lance Taylor wrote:
| I meant something very simple: for every type, there is a
| TYPE_CANONICAL field. This is how you tell whether two types are
| equivalent:
| TYPE_CANONICAL (a) == TYPE_CANONICAL (b)
|
| Ah,
From: Mark Shinwell [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:
[snip]
I've only had a very quick look at your code, but I have a feeling
thatthis is an instance of the kind of
We're going to have to think seriously about threading the compiler.
Intel predicts 80 cores in the near future (5 years). http://
hardware.slashdot.org/article.pl?sid=06/09/26/1937237from=rss To
use this many cores for a single compile, we have to find ways to
split the work. The best
On Fri, Nov 10, 2006 at 12:38:07PM -0800, Mike Stump wrote:
How many hunks do we need, well, today I want 8 for 4.2 and 16 for
mainline, each release, just 2x more. I'm assuming nice, equal sized
hunks. For larger variations in hunk size, I'd need even more hunks.
Or, so that is just
On 10 November 2006 20:06, Mark Mitchell wrote:
Dave Korn wrote:
It may seem a bit radical, but is there any reason not to modify the
option-parsing machinery so that either '-' or '=' are treated
interchangeably for /all/ options with joined arguments? That is,
whichever is specified
Dave Korn wrote:
On 10 November 2006 20:06, Mark Mitchell wrote:
Dave Korn wrote:
It may seem a bit radical, but is there any reason not to modify the
option-parsing machinery so that either '-' or '=' are treated
interchangeably for /all/ options with joined arguments? That is,
ON THE CALL: Kenny Zadack (Natural Bridge), Diego Novillo (Red Hat),
Vladimir Makarov (Red Hat), Mark Smith (Gelato), Bob Kidd (UIUC),
Andrey Belevantsev (RAS), Arutyun Avetisyan (RAS), Mark Davis (Intel),
Sebastian Pop (Ecole des Mines de Paris)
Agenda:
1) Gelato ICE April GCC track proposed
Dave Korn wrote:
On 10 November 2006 20:06, Mark Mitchell wrote:
Dave Korn wrote:
It may seem a bit radical, but is there any reason not to modify the
option-parsing machinery so that either '-' or '=' are treated
interchangeably for /all/ options with joined arguments? That is,
whichever is
On Nov 10, 2006, at 12:46 PM, H. J. Lu wrote:
Will use C++ help or hurt compiler parallelism? Does it really matter?
I'm not an expert, but, in the simple world I want, I want it to not
matter in the least. For the people writing most code in the
compiler, I want clear simple rules for
On Fri, 2006-11-10 at 12:46 -0800, H. J. Lu wrote:
On Fri, Nov 10, 2006 at 12:38:07PM -0800, Mike Stump wrote:
How many hunks do we need, well, today I want 8 for 4.2 and 16 for
mainline, each release, just 2x more. I'm assuming nice, equal sized
hunks. For larger variations in hunk
On Fri, 2006-11-10 at 13:31 -0800, Mike Stump wrote:
On Nov 10, 2006, at 12:46 PM, H. J. Lu wrote:
Will use C++ help or hurt compiler parallelism? Does it really matter?
I'm not an expert, but, in the simple world I want, I want it to not
matter in the least. For the people writing most
On 2006-11-10, at 21:46, H. J. Lu wrote:
On Fri, Nov 10, 2006 at 12:38:07PM -0800, Mike Stump wrote:
How many hunks do we need, well, today I want 8 for 4.2 and 16 for
mainline, each release, just 2x more. I'm assuming nice, equal sized
hunks. For larger variations in hunk size, I'd need
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
in a library compiled
On 2006-11-10, at 22:33, Sohail Somani wrote:
On Fri, 2006-11-10 at 12:46 -0800, H. J. Lu wrote:
On Fri, Nov 10, 2006 at 12:38:07PM -0800, Mike Stump wrote:
How many hunks do we need, well, today I want 8 for 4.2 and 16 for
mainline, each release, just 2x more. I'm assuming nice, equal
Le Fri, Nov 10, 2006 at 01:33:42PM -0800, Sohail Somani écrivait/wrote:
I don't think it can possibly hurt as long as people follow normal C++
coding rules.
The main issue is not really language choice though. The main issues
would likely be defining data to be isolated enough to be useful
On Nov 10, 2006, at 9:14 AM, Ian Lance Taylor wrote:
Nuno Lopes [EMAIL PROTECTED] writes:
I've been thinking that it would be a good idea to extend the current
__attribute__((format,..)) to use an arbitrary user callback.
I searched the mailing list archives and I found some references to
On Nov 9, 2006, at 11:37 PM, Mark Mitchell wrote:
It might be that we should move the invocation of the real linker
back into gcc.c, so that collect2's job just becomes
Or move all of collect2 back into gcc.c. There isn't a reason for it
being separate any longer.
But I do get a failure in verify_flow_info with the appended test case.
Indeed that's where I get the ICE.
verify_flow_info is only used when checking is enabled, so
maybe that is why people aren't seeing it?
But isn't that the default on the trunk?
Mike Stump wrote:
...
Thoughts?
Raw thoughts:
1. Threading isn't going to help for I/O bound portions.
2. The OS should already be doing some of the work of threading.
Some 'parts' of the compiler should already be using CPUs: 'make',
the front-end (gcc) command, the language compiler,
On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote:
No, surely you don't want to do that! You really need a movdi pattern -
even more so if there are no natural DImode-sized registers, as gcse can get
terribly confused by bad reg_equal notes if you don't. See e.g.:
Mike Stump wrote:
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
in a
I'm not subscribed to this list, I just noticed this discussion
while browsing around... Don't know if the list accept
non-subscriber messages either, but let's see:
Ian Lance Taylor wrote:
codesearch.google.com finds about 6000 uses of extern line in
code written in C, but the search
On 10 November 2006 21:18, Brooks Moses wrote:
Dave Korn wrote:
But that's already not possible -- that's essentially how I got into
this problem in the first place. If one tries to define both of those,
the declaration of the enumeration-type holding the option flags breaks,
so you can't
Snapshot gcc-4.1-20061110 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Sohail Somani wrote:
struct __some_random_name
{
void operator()(int t){t++;}
};
for_each(b,e,__some_random_name());
Would this require a new tree node like LAMBDA_FUNCTION or should the
parser do the translation? In the latter case, no new nodes should be
necessary (I think).
On Fri, 10 Nov 2006, Nuno Lopes wrote:
On Fri, 10 Nov 2006, Ian Lance Taylor wrote:
I kind of liked this idea:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html
but of course it was insane.
I still think a higher level state machine as described in the followups
is
On Fri, 2006-11-10 at 22:49 +0100, Marcin Dalecki wrote:
I don't think it can possibly hurt as long as people follow normal C++
coding rules.
Contrary to C there is no single general coding style for C++. In
fact for a project
of such a scale this may be indeed the most significant
On Nov 10, 2006, at 2:19 PM, Kevin Handy wrote:
What will the multi-core compiler design do to the old processors
(extreme slowness?)
Roughly speaking, I want it to add around 1000 extra instructions per
function compiled, in other words, nothing. The compile speed will
be what the
On Fri, 2006-11-10 at 14:47 -0800, Mark Mitchell wrote:
Sohail Somani wrote:
struct __some_random_name
{
void operator()(int t){t++;}
};
for_each(b,e,__some_random_name());
Would this require a new tree node like LAMBDA_FUNCTION or should the
parser do the translation?
[EMAIL PROTECTED] (Richard Kenner) writes:
But I do get a failure in verify_flow_info with the appended test case.
Indeed that's where I get the ICE.
verify_flow_info is only used when checking is enabled, so
maybe that is why people aren't seeing it?
But isn't that the default on
Dave Korn wrote:
On 10 November 2006 21:18, Brooks Moses wrote:
But that's already not possible -- that's essentially how I got into
this problem in the first place. If one tries to define both of those,
the declaration of the enumeration-type holding the option flags breaks,
so you can't do
Richard Guenther wrote:
On 11/10/06, Howard Chu [EMAIL PROTECTED] wrote:
I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
returning values through a void ** argument. As far as I can tell, this
doesn't actually cause any problems, but gcc 4.1 with -Wstrict-aliasing
will
Joe Buck wrote:
On Fri, Nov 10, 2006 at 04:18:25PM -0800, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Hm, actually it still prints the correct result for me. What platform
are you using where it actually makes a
Mike Stump writes:
We're going to have to think seriously about threading the compiler. Intel
predicts 80 cores in the near future (5 years). [...] To use this many
cores for a single compile, we have to find ways to split the work. The
best way, of course is to have make -j80 do that for us, this
Howard Chu [EMAIL PROTECTED] writes:
I understand that logic, in the general case. In this specific example,
none of those conditions apply. foo is an uninitialized local
variable. Therefore the compiler cannot know that it has a valid copy of
it in any register. In fact what it should know
Andreas Schwab wrote:
Howard Chu [EMAIL PROTECTED] writes:
I understand that logic, in the general case. In this specific example,
none of those conditions apply. foo is an uninitialized local
variable. Therefore the compiler cannot know that it has a valid copy of
it in any register. In
I am having some trouble with getting type names as declared by the user
in source. In particular if i have two functions:
void Function(int i);
void Function(char c);
when processing the parameters i get an INTEGER_TYPE node in the
parameter list for both function as expected,
The competition is already starting to make progress in this area.
We don't want to spend time in locks or spinning and we don't want to
liter our code with such things, so, if we form areas that are fairly
well isolated and independent and then have a manager, manage the
compilation process
It will load the value from memory, true, but who says that the store to
memory will happen before that? The compiler is allowed to reorder the
statements since it knows that foo and *arg cannot alias.
If the compiler is smart enough to know how to reorder the statements,
then it should be
On 11/10/06, Mike Stump [EMAIL PROTECTED] wrote:
On Nov 10, 2006, at 12:46 PM, H. J. Lu wrote:
Will use C++ help or hurt compiler parallelism? Does it really matter?
I'm not an expert, but, in the simple world I want, I want it to not
matter in the least. For the people writing most code in
Daniel Berlin wrote:
It will load the value from memory, true, but who says that the
store to
memory will happen before that? The compiler is allowed to reorder
the
statements since it knows that foo and *arg cannot alias.
If the compiler is smart enough to know how to reorder the
Hm. If you're going to reorder these things, then I would expect either
an error or a warning at that point, because you really do know that a
reference to an uninitialized variable is happening.
We do warn when we see an uninitialized value if -Wuninitialized is on.
We don't warn at every
On Fri, 2006-11-10 at 15:23 -0800, Sohail Somani wrote:
Do you need new class types, or just an anonymous FUNCTION_DECL?
Hi Mark, thanks for your reply.
In general it would be a new class. If the lambda function looks like:
void myfunc()
{
int a;
...(int i1,int i2) extern (a)
On Fri, 2006-11-10 at 19:46 -0800, Andrew Pinski wrote:
On Fri, 2006-11-10 at 15:23 -0800, Sohail Somani wrote:
Do you need new class types, or just an anonymous FUNCTION_DECL?
Hi Mark, thanks for your reply.
In general it would be a new class. If the lambda function looks like:
On Fri, 10 Nov 2006, Daniel Berlin wrote:
It will load the value from memory, true, but who says that the store to
memory will happen before that? The compiler is allowed to reorder the
statements since it knows that foo and *arg cannot alias.
If the compiler is smart enough to
Most people aren't waiting for compilation of single files.
If they do, it is because a single compilation unit requires
parsing/compilation of too many unchanging files, in which case
the primary concern is avoiding redoing useless compilation.
The common case is that people just don't use the
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote:
The common case is that people just don't use the -j feature
of make because
1) they don't know about it
2) their IDE doesn't know about it
3) they got burned by bad Makefiles
4) it's just too much typing
Don't forget:
5) running 4 GCC
On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote:
while speaking about uninitialized variables gcc developers probably want
to look at their own sources first:
gcc/testsuite/gcc.dg/vect/vect-27.c
If any code in the testsuite is broken, it should be changed. And this
is not really
On 2006-11-11, at 06:08, Geert Bosch wrote:
Just compiling
int main() { puts (Hello, world!); return 0; }
takes 342 system calls on my Linux box, most of them
related to creating processes, repeated dynamic linking,
and other initialization stuff, and reading and writing
temporary files for
On Sat, 2006-11-11 at 00:08 -0500, Geert Bosch wrote:
Most of my compilations (on Linux, at least) use close
to 100% of CPU. Adding more overhead for threading and
communication/synchronization can only hurt.
In my daily work, I take processes that run 100% and make them use 100%
in less time.
Daniel Berlin wrote:
We ask the TBAA analyzer can a store to a short * touch i.
In this case, it says no, because it's not legal.
If you know the code is not legal, why don't you abort the compilation
with an error code? The current silent behavior provides a mechanism for
creating
On Fri, 2006-11-10 at 23:05 -0800, Howard Chu wrote:
Daniel Berlin wrote:
We ask the TBAA analyzer can a store to a short * touch i.
In this case, it says no, because it's not legal.
If you know the code is not legal, why don't you abort the compilation
with an error code?
The code is
On Nov 10, 2006, at 5:43 PM, Paul Brook wrote:
Can you make it run on my graphics card too?
:-) You know all the power on a bleeding edge system is in the GPU
now. People are already starting to migrate data processing for
their applications to it. Don't bet against it. In fact, we
Andrew Pinski wrote:
On Fri, 2006-11-10 at 23:05 -0800, Howard Chu wrote:
Daniel Berlin wrote:
We ask the TBAA analyzer can a store to a short * touch i.
In this case, it says no, because it's not legal.
If you know the code is not legal, why don't you abort the compilation
On Fri, Nov 10, 2006 at 02:32:10PM -0800, Howard Chu wrote:
With the previous example, if alias1.c was instead:
#include stdio.h
extern void getit( void **arg );
main() {
union {
int *foo;
void *bar;
} u;
getit( u.bar );
On Fri, 10 Nov 2006, Mike Stump wrote:
On Nov 10, 2006, at 12:46 PM, H. J. Lu wrote:
Will use C++ help or hurt compiler parallelism? Does it really matter?
I'm not an expert, but, in the simple world I want, I want it to not matter
in the least. For the people writing most code in the
1 - 100 of 188 matches
Mail list logo
