On Sun, May 01, 2005 at 10:31:05PM +, Thorsten Glaser wrote:
> Could you please go to http://wiki.mirbsd.de/MirbsdKsh, get the source,
> compile it and try with it instead of your usual /bin/sh (I suppose GNU
> bash) again?
>
> I'd be interested if that warrants a noticeable speedup.
No visib
[EMAIL PROTECTED] wrote:
What's wrong with this ? It is ok in gcc 3 not not ok with gcc4:
#define SERVICE_TYPE(type, val, state) SERVICE_##type = val,
typedef enum service_e {
SERVICE_TYPE(NONE, 0, false)
SERVICE_TYPE(FTP,1, true)
SERVICE_TYPE_MAX
} service_type_t;
Compi
On May 1, 2005, at 10:10 PM, R. D. Flowers wrote:
I have added content to http://gccnews.chatta.us . I tell of my plan
for it, and a mailing list summary for last November. I hope to add
other months until it is caught up. I welcome your opinions, either on
this list or privately.
VLA is not ver
I have added content to http://gccnews.chatta.us . I tell of my plan for it,
and a mailing list summary for last November. I hope to add other months until
it is caught up. I welcome your opinions, either on this list or privately.
--
rick f.
End DRM for brains !
The World has latched itself to y
Jason Thorpe <[EMAIL PROTECTED]> wrote:
>> I would also like to note that I *myself* requested preprocessed
>> source code to
>> NetBSD developers at least 6 times in the past 2 years. I am sure
>> Andrew Pinski
>> did too, a comparable amound of times. These requests, as far as I
>> can understan
Reporting a successful build on OpenBSD 3.7-BETA:
./config.guess
i386-unknown-openbsd3.7
Built with native gcc within OpenBSD:
# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)
I used GNU make and ins
[EMAIL PROTECTED] (Andrew Haley) wrote on 30.04.05 in <[EMAIL PROTECTED]>:
> Matt Thomas writes:
> > Joe Buck wrote:
> > > I think you need to talk to the binutils people. It should be possible
> > > to make ar and ld more memory-efficient.
> >
> > Even though systems maybe demand paged, ha
Andrew Haley dixit:
>Richard Henderson writes:
> >
> > Now, unless I've done something drastically wrong, it appears as if we
> > are spending 2/3 of our time in the libtool script.
>
>Yes, that's right. That's similar to what my oprofile experiments suggest.
Could you please go to http://wiki.
Dixi:
>Mark Mitchell dixit:
>
>>In general, GCC 3.4.3 is working for people
>
>I've been playing around a lot with the various 3.4.4 snapshots
>lately, and got everything to work, except for libjava:
With the change in the configuration file, it works now. However,
I'm curious about why FreeBSD d
Diego Novillo wrote:
On Sun, May 01, 2005 at 02:16:27PM -0400, Friends wrote:
Only when I compile with an optimization level of "O2" or "O3" does the
program exit with a memory access error.
It may be a bug in GCC and it may also be a bug in your program
(some problems like aliasing bugs only ar
On Sun, 1 May 2005, Gerald Pfeifer wrote:
> This is the variant of the patch I applied on the 4.0 branch.
Sorry, that was a typo: for the 4.0 branch I used exactly the same
version as for mainline. This slightly different patch is what I
applied on the 3.4 branch.
> 2005-05-01 Gerald Pfeifer <
Hi,
What's wrong with this ? It is ok in gcc 3 not not ok with gcc4:
#define SERVICE_TYPE(type, val, state) SERVICE_##type = val,
typedef enum service_e {
SERVICE_TYPE(NONE, 0, false)
SERVICE_TYPE(FTP,1, true)
SERVICE_TYPE_MAX
} service_type_t;
Thanks
dave
Hi Nathan,
> Kazu, I hope I have time to look in detail at your investigation, however
> one thing that might be causing a problem is that FOR_EACH_EDGE is an iterator
> that works for a non-constant VEC. This means there's an extra level of
> indirection that the optimizer cannot remove, unless
On Sun, May 01, 2005 at 10:45:15PM +0530, Virender Kashyap wrote:
> Also what exactly happens in a = b + c (b,c local) ?
>
That statement is already in GIMPLE form, so it's not changed.
What you describe is how the conversion into gimple occurs, have
you found a problem with it? I'm not sure whe
On Sun, May 01, 2005 at 02:16:27PM -0400, Friends wrote:
> Only when I compile with an optimization level of "O2" or "O3" does the
> program exit with a memory access error.
>
It may be a bug in GCC and it may also be a bug in your program
(some problems like aliasing bugs only are exposed at hi
I have reviewed the gcc web page for reporting bugs and this situation is not
covered.
I have a program that I have been compiling with the gcc 2.9 and 3.4 series.
In the past week I upgraded to gcc 4.0.0
I compiled the program and corrected the warning message about using "unsigned
char *" wh
Snapshot gcc-4.1-20050501 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050501/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-05-01 17:43 UTC
You'll
On Sun, 1 May 2005, Gerald Pfeifer wrote:
> Thanks for the clear report, Dimitri. I just installed the following
> change to mainline (which will become GCC 4.1) and will shortly do the
> same on the 4.0 branch.
This is the variant of the patch I applied on the 4.0 branch.
Gerald
2005-05-01 Ge
Hi,
it looks like in mainline this test recently started failing at compile
time on some machines. I'm puzzled, unfortunately cannot reproduce the
problem and would be grateful is someone could send me (either privately
or in public) more information (e.g., an extract from libstdc++.log, at
least
Hello,
> >To see what kind of code GCC generates for FOR_EACH_EDGE, I wrote a
> >simple dummy function.
>
> Kazu, I hope I have time to look in detail at your investigation, however
> one thing that might be causing a problem is that FOR_EACH_EDGE is an
> iterator
> that works for a non-constant
Kazu Hirata wrote:
To see what kind of code GCC generates for FOR_EACH_EDGE, I wrote a
simple dummy function.
Kazu, I hope I have time to look in detail at your investigation, however
one thing that might be causing a problem is that FOR_EACH_EDGE is an iterator
that works for a non-constant VEC.
Hi,
In GIMPLE IR, variables that need to live in memory are to be first
loaded into temporaries and then used in expressions. The memory here
referes here to data area i guess. Because for local variables which
reside on stack , this rule does not apply, as an expression like
c = a + b ; whe
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.
In 01.sibling, I have the instruction:
(insn 10 8 12 1 (set (mem/f/i:HI (plus:HI (reg/f:HI 23 virtual-stack-vars)
On Fri, 29 Apr 2005, Dimitri Papadopoulos-Orfanos wrote:
> Some links are broken on this page:
> http://gcc.gnu.org/install/specific.html
>
> Specifically:
> i?86-*-sco3.2v5*
> i?86-*-solaris2.10
> x86_64-*-*, amd64-*-*
> all ELF targets
That's even further collatera
Richard Henderson writes:
>
> Now, unless I've done something drastically wrong, it appears as if we
> are spending 2/3 of our time in the libtool script.
Yes, that's right. That's similar to what my oprofile experiments suggest.
Andrew.
As you noted, when the scheduler decides between stores and adds it always
prefers the adds (first at t = 5), due to its critical path heuristic. In
Jon's example, stores seem "costly" as one cannot issue a load or store
immediately following a store. Perhaps the scheduler could take the
(resou
26 matches
Mail list logo
