> GCC 4.1 is going rather well thus far.
>
> Technically, Stage 1 ended on April 25th, though I failed to announce
> that. There are a few stage 1 tasks that have not made it in yet,
> according to the Wiki:
>
> # Autovectorization Enhancements
> Items 1.4, 2.1, 2.3 (1.3)
Items 1.4 and 2.3 ar
Hi.
Looks good to me.
Also I hope to post new pragma handling mechanism patch in near
future. Currently I'm trying to find sparc/solaris box to make some
tests. This will require some minor changes to the parser. In
particular I plan to remove threadprivate handler from FE to a
separate handler w
Per Bothner wrote:
> Mark Mitchell wrote:
>
>>Building libjava takes forever on any platform, relative to the rest of
>>the compiler build.
[...]
> One way to speed up libcgj compilation by quite a bit would be to
> compile more than one .java file at a time. For example:
>gcj -c java/util
> James E Wilson
>> Jonathan Bastien-Filiatrault wrote:
>> * We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On this
>> DSP, there are two 40-bits accumulators. How do we make GCC take
>> advantage of this and which machine mode do we use ?
>
> GCC has little support for non-power-of-2
GCC 4.1 is going rather well thus far.
Technically, Stage 1 ended on April 25th, though I failed to announce
that. There are a few stage 1 tasks that have not made it in yet,
according to the Wiki:
# Autovectorization Enhancements
Items 1.4, 2.1, 2.3 (1.3)
# CFG Transparent Inlining, Profile-Gu
On Wed, May 04, 2005 at 09:29:44AM -0700, Joe Buck wrote:
> So the basic issue is this: why the hell does the linker need so much
> memory?
- long symbol names and lots of symbols
- lots of sections
- optimizations that edit section contents, requiring the contents to
be kept in memory. eg. str
Andrew Haley dixit:
>Do you have any reason to suspect this might be MirOS specific?
We have to patch a lot. Some of it is OpenBSD legacy, some from
NetBSD, some from newer GNU tools, some patches are build system
specific. And since it happened on execution of a class with only
one page source c
> If this were being done at the level of register allocation, why would
> one need a user visible option? 'Just' rearrange the register file to look
> like a set of single bit registers overlaid on a more conventional register
> file.
As someone pointed out, this might change semantics (read: scr
> Unless you are using an architecture with btst, bset, bclr instructions.
Pretty much any architechure that could be called a binary computer has
something like that ;-)
Samuel Lauber
--
___
Surf the Web in a faster, safer and easier way:
Download Ope
Per Bothner wrote:
One way to speed up libcgj compilation by quite a bit would be to
compile more than one .java file at a time. For example:
gcj -c java/util/*.java -o java-util.o
This reduces libtool overhead, reduces the duplication in reading
dependencies, and probably reduces link overheads
On Wed, May 04, 2005 at 05:08:23PM -0700, James E Wilson wrote:
> We can perhaps handle this well in the tree-aliasing code (if
> it handled restrict at all), but it would be difficult to
> handle this well in the RTL aliasing code.
>
It doesn't. Mostly for similar reasons.
Perhaps we could be m
Snapshot gcc-3.3-20050504 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050504/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050504
You'll
On Wed, 2005-05-04 at 16:24, Jeroen Dobbelaere wrote:
> I'm aware of that. The reason are asked for more clarity is that I
> think gcc should
> do better (as in the example I gave), but I want to be sure that this
> is still allowed
> by the standard.
Certainly gcc can and should do better, and th
Mark Mitchell wrote:
Building libjava takes forever on any platform, relative to the rest of
the compiler build.
In addition to fixing/replacing libtool (could it be rewritten as a C
program?) there are a number of other known gcj performance problems.
When compiling A.java, gcj needs to read a lo
On 5/4/05, James E Wilson wrote:
[..]
> The standard says "A translator is free to ignore any or all aliasing
> implications of restrict". So there is no conflict with the standard
> here. We are free to do as little optimization as we want, and in the
> case of a restricted char pointer, we do n
On Wed, 2005-05-04 at 14:27, Jeroen Dobbelaere wrote:
> Is this correct ?
I was only trying to explain how gcc works for the one example that you
posted. I was not trying to explain precise semantics of how restrict
works according to the ISO C standard, and my message should not be
construed as
Mike Stump wrote:
On May 4, 2005, at 12:47 PM, Chris Friesen wrote:
One problem with using volatile is that it can destroy performance.
Gosh, I was going to elaborate and give the more complete answer, but
decided against it, I was wrong.
Heh...sorry. I've been trying to figure out who's respo
On May 4, 2005, at 12:47 PM, Chris Friesen wrote:
One problem with using volatile is that it can destroy performance.
Gosh, I was going to elaborate and give the more complete answer, but
decided against it, I was wrong.
only need to really read it in from memory the first time after I
take a
Diego Novillo wrote:
On Wed, May 04, 2005 at 02:47:14PM -0600, Chris Friesen wrote:
In multiple messages to comp.programming.threads he has stated that
volatile is not necessary between threads if you use the posix locking
functions, and in fact that one of the main purposes of the posix locks
On 5/4/05, James E Wilson <[EMAIL PROTECTED]> wrote:
[..]
> The optimization does not happen for this example because we apparently
> have no way to represent an alias set for a restricted char pointer.
> char * and void * are allowed to alias anything. That is alias set 0
> internally. A restric
On Wed, May 04, 2005 at 02:47:14PM -0600, Chris Friesen wrote:
> In multiple messages to comp.programming.threads he has stated that
> volatile is not necessary between threads if you use the posix locking
> functions, and in fact that one of the main purposes of the posix locks
> is to ensure
Diego Novillo wrote:
On Wed, May 04, 2005 at 01:47:20PM -0600, Chris Friesen wrote:
Also, what about threads and pthread locking? Do I need to use volatile
there? If not, then what about using pthread locking between processes?
Things will only break for you when GCC pulls in function bodies
a
Jeroen Dobbelaere wrote:
void test_2(unsigned long* __restrict__ bar, char* __restrict__ bas)
{
unsigned long tmp = *bar;
*bas = 0;
*bar = tmp;
}
The optimization in the first example happens in the postreload cse
pass, and is relying on RTL alias analysis info.
The optimization does not ha
Chris Friesen wrote:
Mike Stump wrote:
It is safer to. People might compile your whole app at once for
better optimization, and the compiler might be just smart enough to
optimize it away.
One problem with using volatile is that it can destroy performance. I
only need to really read it in
> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
Daniel> On Wed, May 04, 2005 at 04:15:53PM -0400, Paul Koning wrote:
>> OUCH.
>>
>> Some of the types in question are probably not used in the program
>> -- they are there for debugging. It's disturbing to see this sort
>> of
On Wed, May 04, 2005 at 04:15:41PM -0400, Diego Novillo wrote:
> Same reply I gave you before. As long as the address of your
> shared memory is outside of the function and the pointer is
> itself a global variable or gets its value from the heap, then
> calls to functions that cannot be inlined
On Wed, May 04, 2005 at 04:15:53PM -0400, Paul Koning wrote:
> OUCH.
>
> Some of the types in question are probably not used in the program --
> they are there for debugging. It's disturbing to see this sort of
> incompatibility.
-fno-eliminate-unused-debug-types?
> The rule for "used" clearly
> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
Daniel> On Wed, May 04, 2005 at 03:53:35PM -0400, Paul Koning wrote:
>> I'm doing some tests to see if 4.0.0 will improve our debug
>> experience, which is mixed indeed with complex C++ code and 3.3.3.
>>
>> So far it looks like
On Wed, May 04, 2005 at 01:47:20PM -0600, Chris Friesen wrote:
> Also, what about threads and pthread locking? Do I need to use volatile
> there? If not, then what about using pthread locking between processes?
>
Same reply I gave you before. As long as the address of your
shared memory is ou
On Wed, May 04, 2005 at 03:53:35PM -0400, Paul Koning wrote:
> I'm doing some tests to see if 4.0.0 will improve our debug
> experience, which is mixed indeed with complex C++ code and 3.3.3.
>
> So far it looks like things are MUCH worse. I built my application
> and looked at it with GDB. Many
I'm doing some tests to see if 4.0.0 will improve our debug
experience, which is mixed indeed with complex C++ code and 3.3.3.
So far it looks like things are MUCH worse. I built my application
and looked at it with GDB. Many of the structure names are missing.
I did some checking with readelf,
Mike Stump wrote:
On May 4, 2005, at 10:59 AM, Chris Friesen wrote:
If I share memory between two processes, and protect access to the
memory using standard locking (fcntl(), for instance), do I need to
specify that the memory is volatile?
It is safer to. People might compile your whole app
Dale Johannesen wrote:
Both behaviors are standard-compliant.
I don't think anyone's disagreeing with that. The point is that the
user *requires* a volatile read, but the std *does not* guarantee it.
> Treating a reference as volatile when you don't have to just means
> strictly following the rule
On May 4, 2005, at 10:59 AM, Chris Friesen wrote:
I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the
memory using standard locking (fcntl(), for instance), do I need to
specify that the memory is volatile?
It is
On Wed, 2005-05-04 at 09:37, Anuradha Suraparaju wrote:
> I've attached a sample file to this email. The class defined in the cpp
> file is a cut down and modfied version of the class used in Dirac.
That is a fine bug report. You just need to put it in bugzilla if you
want us to do anything about
> "James" == James E Wilson writes:
James> On Wed, 2005-05-04 at 06:00, Paul Koning wrote:
>> I wonder if the work-in-progress PDP10 port
>> (http://pdp10.nocrew.org/gcc/) might help with this.
James> Interesting, but a hobbyist port for a 36-bit machine that was
James> end-of-lifed abo
Chris Friesen wrote:
I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the
memory using standard locking (fcntl(), for instance), do I need to
specify that the memory is volatile? Or is the fact that I'm using
fcnt
On Wed, May 04, 2005 at 11:59:49AM -0600, Chris Friesen wrote:
> Without the locks, the compiler is free to only load *b once (and in
> fact gcc does so). Is the addition of the locks sufficient to force *b
> to be re-read each time, or do I need to declare it as
>
As long as you keep 'b' poin
Note:
- I could build GCC 4.0.0 only with Fortran95 and C.
- with C++ and Java building failed.
- I will try to build GCC 4.0 with itself, now with (nearly) all languages.
gcc -v
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc-4.0.0/configure --program-suffix=-4.0.0c
On Wed, May 04, 2005 at 12:43:46PM -0400, Ian Lance Taylor wrote:
> At present the linker provides command line options --no-keep-memory
> and --reduce-memory-overheads to significantly reduce the amount of
> memory required during the link.
>
> It should be possible in principle to partially adap
On Wed, 2005-05-04 at 06:00, Paul Koning wrote:
> I wonder if the work-in-progress PDP10 port
> (http://pdp10.nocrew.org/gcc/) might help with this.
Interesting, but a hobbyist port for a 36-bit machine that was
end-of-lifed about 2 decades ago has little chance of success, unless
there are some v
> "Dale" == Dale Johannesen <[EMAIL PROTECTED]> writes:
Dale> On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:
>> Andrew Haley <[EMAIL PROTECTED]> writes:
>>
>> | Nathan Sidwell writes: | > Dale Johannesen wrote:
>> | >
>> | > > And we don't have to document the behavior at all; it
I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the
memory using standard locking (fcntl(), for instance), do I need to
specify that the memory is volatile? Or is the fact that I'm using
fcntl() enough to force t
On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
| Nathan Sidwell writes:
| > Dale Johannesen wrote:
| >
| > > And we don't have to document the behavior at all; it is not
documented
| > > now.
| > I disagree. It's not documented explicitly in gcc
On Wed, 4 May 2005, Dave Korn wrote:
Why isn't --enable-languages=c,c++,f77 sufficient to stop this?
Because you assigned that to $LANGOPT (no trailing 'S'), but the configure
command line has it spelt as $LANGOPTS (note trailing 'S'!), so it didn't
_actually_ get passed to the configure command
Joe Buck <[EMAIL PROTECTED]> writes:
> So the basic issue is this: why the hell does the linker need so much
> memory? Sure, if you have tons available, it pays to trade memory for
> time, mmap everything, then build all the hashes you want to look up
> relationships in every direction. But if i
I've attached a sample file to this email. The class defined in the cpp
file is a cut down and modfied version of the class used in Dirac.
I compiled it using the following options:
g++ -mmmx -g -O3 test_mmx_diff4.cpp
The run time comparison is attached to this email as well.
Hope this helps.
Original Message
>From: Hugh Sasse
>Sent: 04 May 2005 15:45
> # LANGOPT="--enable-languages=c,c++,f77,java,objc"
> LANGOPT="--enable-languages=c,c++,f77"
>
> cd $BUILD_DIR
> /bin/rm -rf ./*
> ${GCC_SOURCE_DIR}/configure $ASOPT $LDOPT $LANGOPTS --disable-nls \
> --with-local-prefix=/tmp/g
I wrote:
> > I'm glad you're looking at speeding up the linker. Please make sure to
> > look at memory consumption as well, since performance falls off a cliff
> > once the working set exceeds physical memory. A good test would be to
> > bootstrap gcc on a machine with 256M, or that is artificia
Thorsten Glaser writes:
> Andrew Haley dixit:
>
> >In which case it would be best to post a bug report at
> >gcc.gnu.org/bugzilla and attach both source and class files.
>
> What for? I'm 99% sure nobody else has got the bug, since
> most probably haven't even heard of the MirOS operating
On Wed, May 04, 2005 at 09:00:05AM -0700, Joe Buck wrote:
> On Wed, May 04, 2005 at 06:41:59AM -0700, H. J. Lu wrote:
> > On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> > > Joe Buck writes:
> > > > Richard Henderson showed that the libjava build spends 2/3 of its time
> > > > in
Andrew Haley dixit:
>In which case it would be best to post a bug report at
>gcc.gnu.org/bugzilla and attach both source and class files.
What for? I'm 99% sure nobody else has got the bug, since
most probably haven't even heard of the MirOS operating
system. And it's only in the latest snapshot.
On Wed, May 04, 2005 at 06:41:59AM -0700, H. J. Lu wrote:
> On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> > Joe Buck writes:
> > > Richard Henderson showed that the libjava build spends 2/3 of its time
> > > in libtool, and that his hand-hacked (but not portable) modification to
Forwarded Message
From: Andrew J. Hutton <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: 3rd Annual - GCC & GNU Toolchain Developers' Summit
Date: Wed, 04 May 2005 11:53:40 -0400
The 3rd Annual GCC & GNU Toolchain Developers' Summit will be taking
place June 22nd ~ 24th, 2005 a
On Wednesday 04 May 2005 16:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what th
On Wednesday 04 May 2005 17:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what th
On Wednesday 04 May 2005 13.34, Paul Brook wrote:
>
> On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
>
> > I have understood that at the moment some misbehaviour of the front-end
> > prevents it, but I don't quite understand what the problem is. Can anyone
> > shed some light?
>
> Basically t
On Wed, May 04, 2005 at 05:18:56PM +0200, Wlodzimierz Lipert wrote:
> Hi! A little mistake during copy/paste. :)
>
> template < typename T, int S >
> class A{
>
> public:
> T _V[S ];
> int a;
> }
You're missing a ';' here.
>
> template < typename T >
> class B : public A< T, 2 /*
On Wed, 2005-05-04 at 11:07, Jeffrey A Law wrote:
> On Wed, 2005-05-04 at 10:28 -0400, Andrew MacLeod wrote:
> > Why is it we try to swap operands in get_expr_operands, where we are
> > otherwise simply parsing not modifying?
> >
> > /* If it would be profitable to swap the operands, then
Hi! A little mistake during copy/paste. :)
template < typename T, int S >
class A{
public:
T _V[S ];
int a;
}
template < typename T >
class B : public A< T, 2 /* const */ >
{
B( T t ) : A::V[0]( t ), A::V[1] ( t ) /* ERROR reported by
compiler. Why? */
, a( 1 ) /* no error */ {};
Hi!
template < typename T, int S >
class A{
public:
T _V[S ];
int a;
}
template < typename T >
class B : public A< T, 2 /* const */ >
{
B( T t ) : A::V[0]( t ), A::V[1] /* ERROR reported by
compiler. Why? */
, a( 1 ) /* no error */ {};
B( T t1, T t2 ){
A::V[0] = t1; // no error.
}
};
It apear
On Wed, 2005-05-04 at 10:28 -0400, Andrew MacLeod wrote:
> Why is it we try to swap operands in get_expr_operands, where we are
> otherwise simply parsing not modifying?
>
> /* If it would be profitable to swap the operands, then do so to
>canonicalize the statement, enabling b
I'm trying to bring an old machine (Solaris 2.5.1, Sparc, Sun4c) up
to date. It has been my experience that I can't build GCC with a
version of gcc that is too old. Thus, to reach gcc-3.4.3 I'm trying
to build gcc-3.3.5 first, with 2.95.2
I have a build script
#!/bin/sh -x
PATH=/bin:/usr/sbin:
On Wed, May 04, 2005 at 07:22:12AM -0700, Earl Chew wrote:
> Can anyone tell me if there is a patch for this problem?
Yes, there is:
ftp://sources.redhat.com/pub/gcc/releases/gcc-4.0.0/diffs/gcc-3.4.3-4.0.0.diff.bz2
FYI, this is PR middle-end/9997
> Consider:
>
> void bar(char*);
>
> v
On Wednesday 04 May 2005 16:22, Earl Chew wrote:
> Can anyone tell me if there is a patch for this problem?
The patch is called GCC 4.0.
Gr.
Steven
Why is it we try to swap operands in get_expr_operands, where we are
otherwise simply parsing not modifying?
/* If it would be profitable to swap the operands, then do so to
canonicalize the statement, enabling better optimization.
By placing canonicalization of such
Can anyone tell me if there is a patch for this problem?
Consider:
void bar(char*);
void foo(int x)
{
if (x) { char y[4096]; bar(y); }
else { char z[4096]; bar(z); }
}
Cygwin gcc 3.4.2 -O2 yields:
pushl %ebp
movl$8216, %eax /* Should be abou
Thorsten Glaser writes:
> Andrew Haley dixit:
>
> >No, but I do know that I would not even attempt to start looking at
> >this with no debugging info in libgcj. libgcj builds by default with
> >full debugging info, so something (someone) must have removed it.
>
> Yes, our libraries are st
H. J. Lu writes:
> On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> > Joe Buck writes:
> > > On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote:
> > > > At this point, it doesn't feel like switching to 1.5.16 is worth the
> > > > effort. 2.0 should be far more m
On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> Joe Buck writes:
> > On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote:
> > > At this point, it doesn't feel like switching to 1.5.16 is worth the
> > > effort. 2.0 should be far more maintainable, and hopefully
> >
On Wednesday 04 May 2005 13:15, Biagio Lucini wrote:
> On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
> > On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
> > > we have to extend the gfortran internal representation also
> >
> > Yes, initially most of the effort will be in C/C+
Andrew Haley dixit:
>No, but I do know that I would not even attempt to start looking at
>this with no debugging info in libgcj. libgcj builds by default with
>full debugging info, so something (someone) must have removed it.
Yes, our libraries are stripped by default. I can build one with
full
> "James" == James E Wilson writes:
James> Jonathan Bastien-Filiatrault wrote:
>> * We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On
>> this DSP, there are two 40-bits accumulators. How do we make GCC
>> take advantage of this and which machine mode do we use ?
James> GCC
On Wed, May 04, 2005 at 12:15:18PM +, Biagio Lucini wrote:
> Also, talking about IR, since OpenMP is mostly unique, probably
> we just need to link the gfortran parser to the work in the
> middle-end that is currently being done, with perhaps a few
> (hopefully no) exception.
>
Yes, the FEs e
Mattias Karlsson wrote:
On Wed, 4 May 2005, Nathan Sidwell wrote:
Sam Lauber wrote:
Would it be possible to have a -fpack-bools option that packs
booleans into
the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a
register
(or memory, as the case may be)?
why would you want to do t
On 5/4/05, Sam Lauber <[EMAIL PROTECTED]> wrote:
> Would it be possible to have a -fpack-bools option that packs booleans into
> the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register
> (or memory, as the case may be)?
Why don't you use bitfields then?
Richard.
On Wed, 4 May 2005, Nathan Sidwell wrote:
Sam Lauber wrote:
Would it be possible to have a -fpack-bools option that packs booleans into
the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a
register
(or memory, as the case may be)?
why would you want to do this? Seems to me you migh
On 4 May 2005, Sam Lauber stipulated:
> Would it be possible to have a -fpack-bools option that packs booleans into
> the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register
> (or memory, as the case may be)?
How could you do that without breaking the semantics of the program?
On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
>
> On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
>
> > we have to extend the gfortran internal representation also
>
> Yes, initially most of the effort will be in C/C++ since that's
> the only parser we have so far.
>
Is ther
Thorsten Glaser writes:
>
>
> A quick look into CVSweb shows me _Jv_ClassReader::handleFieldsEnd ()
> is still the same as in 3.4.4. Does anyone have an idea where this
> SIGSEGV could come from?
No, but I do know that I would not even attempt to start looking at
this with no debugging info
Hello,
I've got Java classes from source ("99 bottles of beer") compiled
to bytecode and from source or bytecode to a dynamically linked
executable working just fine, also Sun's JDK works on the generated
bytecode - however, gij does not, even without boehm-gc (which
prevented it from working befo
Andrew Haley <[EMAIL PROTECTED]> writes:
| Nathan Sidwell writes:
| > Dale Johannesen wrote:
| >
| > > And we don't have to document the behavior at all; it is not documented
| > > now.
| > I disagree. It's not documented explicitly in gcc now, because it is doing
| > what the std permits
Sam Lauber wrote:
Would it be possible to have a -fpack-bools option that packs booleans into
the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register
(or memory, as the case may be)?
why would you want to do this? Seems to me you might save up to 7 bytes
of data memory at a va
Joe Buck writes:
> On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote:
> > At this point, it doesn't feel like switching to 1.5.16 is worth the
> > effort. 2.0 should be far more maintainable, and hopefully
> > significantly more efficient on hosts where the use of shell functions
Nathan Sidwell writes:
> Dale Johannesen wrote:
>
> > And we don't have to document the behavior at all; it is not documented
> > now.
> I disagree. It's not documented explicitly in gcc now, because it is doing
> what the std permits, and so documented there. We should document either
>
Hi,
I have a question concerning '__restrict__' :
With gcc-4.0.0 (-O3 -fomit-frame-pointer, on i686), following piece of code :
void test_1(unsigned long* __restrict__ bar, unsigned long* __restrict__ bas)
{
unsigned long tmp = *bar;
*bas = 0;
*bar = tmp;
}
void test_2(unsigned long* __r
On Wed, May 04, 2005 at 01:02:18AM -0700, Richard Henderson wrote:
> On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
> > For that instruction, instantiate_virtual_regs_in_insn
> > enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS
> > is entered, where if (safe_insn_predicat
Dale Johannesen wrote:
And we don't have to document the behavior at all; it is not documented
now.
I disagree. It's not documented explicitly in gcc now, because it is doing
what the std permits, and so documented there. We should document either
a) that current gcc is not breaking the std, and
On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
> For that instruction, instantiate_virtual_regs_in_insn
> enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS
> is entered, where if (safe_insn_predicate (insn_code, 1, new) is entered.
> It then jumps to verify, without changi
On Tue, May 03, 2005 at 05:44:47PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >I notice, that your last change in function.c forgets virtual
> >registers in the RTL in some conditions. In older version (the last I used
> >was 20050412),
> >this has not happend.
>
> Patches should go t
90 matches
Mail list logo
