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
#i
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 th
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
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 shou
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] b
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 wa
"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 =
"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 ba
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
--
Ca
"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)
> (
"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. B
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 invoc
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
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 char
"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?
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 fi
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 w
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 o
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
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
http://developer.intel.com/products/processor/manu
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 a
"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:
|
| template
| where LessThanComparable && SameType
| const T& weird_min(con
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:
|
| template
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
"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 bee
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 imp
[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
th
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 can
"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(LessThanComparable) ==
| > | TYPE_CANONICAL(LessTha
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 w
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 t
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 thinking
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 m
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 t
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/1937237&from=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 ju
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 sp
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? Th
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 cont
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 the
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
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
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 eve
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
siz
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 use
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, t
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.:
>
> http://gcc
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 ca
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
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
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 significa
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 compil
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
[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
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 th
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 compl
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 difference?
Rather, he is sayi
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 differen
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, t
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 k
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 fa
> > 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 a
> 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 pr
> 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 shoul
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 s
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 poin
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)
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
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
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 tim
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 source-
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?
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 hide
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
>
> extern void getit( void **arg );
>
> main() {
>union {
>int *foo;
>void *bar;
>} u;
>
>getit( &u.
1 - 100 of 101 matches
Mail list logo
