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 compi
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.
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 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
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?
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 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
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 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 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
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 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
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, 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)
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
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
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
> 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
> 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
> > 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
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
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
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
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
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
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
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
[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
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
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 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 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
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
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
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
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
>
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
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:
...
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
> 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?
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.
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
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 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
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 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 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 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 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
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 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? Th
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
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
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
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
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
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
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
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 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
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
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
"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
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
[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
"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
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 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
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
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
"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
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
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
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 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
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
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
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
=
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
"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?
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
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
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
[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
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
"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)
>
"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)
> (
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
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
"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
"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 =
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
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
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?
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
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
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 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
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
1 - 100 of 101 matches
Mail list logo
