Hey,
I'm going to do more testing on this, but it seems this patch reduces the
number of DOM iterations from the number of else if statements in pr19097 to
2 DOM iterations. This is a massive savings and the savings if from
calling fold_build2 (cond_code, boolean_type_node, op0, op1) in
On 8/25/05, Andrew Pinski [EMAIL PROTECTED] wrote:
In the last 24 hours, something has gone in which makes
the GCJ interpreter gij abort on even simple Hello World
classes. For example, the RuntimeCheck program in
the Jacks testsuite:
I had (probably) the same thing yesterday.
On Thu, Aug 25, 2005 at 01:29:05AM -0400, DJ Delorie wrote:
It sounds like you're interested in MinGW. If you really wanted to
help MinGW users, you'd fix MinGW so that it supported these the same
way that DJGPP and Cygwin do, for *all* MinGW applications, not just
gcc. I'd have to have to
Jiang Long wrote:
Hello,
I am compiling GCC-4.0.1 with the following :
../gcc-4.0.1/configure --enable-tree-browser=yes
--prefix=/home/jiang/DEV/gcc-dev/trunk/install
--enable-languages=c,c++ --enable-maintainer-mode=yes
After a while I got the following errors with :
Adding multilib
I have met the same question. My solution to this is just to
remove ./config.cache in every sub-directories and try again. This
solution is effective although I am not sure about it. Anyone
could confirm or deny this.
I think make distclean should be done before ./configure if the
Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for that. If Mark wants to duplicate that in MinGw
The problem in front of me is something like this..
op0 = 1
op1 = op0 leftshift op2
The above is a part of the template to be matched, with one of the
conditions that op0 should be dead after the 2nd insn.
This will be optimized to
op1 = 1 leftshift op2 (by the peephole2 pass to the rtl
Ashwin wrote:
The problem in front of me is something like this..
op0 = 1
op1 = op0 leftshift op2
This will be optimized to
op1 = 1 leftshift op2 (by the peephole2 pass to the rtl pattern
corresponding to this and hence the requirement that op0 should be dead
after insn2)
However if the
On Thursday 25 August 2005 07:12, Christoph Hellwig wrote:
On systems with small command-line buffers, this is a must-have
feature.
Do you really want every application to work around a broken propritary
system?
GCC supports many proprietary systems and non-GNU systems, even
though that
Mark Mitchell [EMAIL PROTECTED] writes:
I'm not sure what you're saying. The limitation on command-line
length can be in either the shell, or the OS. In Windows 2000, the
limitation comes primarily from the Windows command shell.
Linux has a similar limit which comes from the OS (normally
I want GCC to work well for people, no matter what operating system they
are using. This is a feature that everyone who produces Windows-hosted
versions of GCC ends up implementing; I'd like to keep us all from
having to keep reinventing the wheel.
Indeed there's a quite old
On Wed, 2005-08-24 at 21:26 -0400, Daniel Berlin wrote:
On Wed, 2005-08-24 at 19:19 -0400, Andrew MacLeod wrote:
removing a stmt doesn't mean that the def is no longer needed.
That ws the goal of the extra argument, however
I noticed this after I sent the note :-). I didn't like the extra
On Thu, 2005-08-25 12:31:34 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
I'm not sure what you're saying. The limitation on command-line
length can be in either the shell, or the OS. In Windows 2000, the
limitation comes primarily from the Windows
On Thursday 25 August 2005 12:45, Jan-Benedict Glaw wrote:
Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
UltraSparc, ...).
Yes you're right. Somehow I only remembered the number 32.
Anyways, it's still
On Thu, 2005-08-25 12:49:16 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
On Thursday 25 August 2005 12:45, Jan-Benedict Glaw wrote:
Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
UltraSparc, ...).
Yes
On i386, GCC currently emits calls to libm math functions like f.i.
sin(). This pessimizes code a lot if we are using SSE math, as we need to
obey the standard i387 FP ABI. The sub-target specific math routines
library will provide a way to present different ABI math routines to GCC,
possibly
You'll have something like this in your test
operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
i.e. you only need to test for op0's death if it is different from op1.
Paolo
Exactly.. this is the same thing as calling dead_or_set_p(insn,
operands[0]). If it can be done
GCC supports many proprietary systems and non-GNU systems, even
though that isn't the purpose of the GCC project according to the
mission statement. Not everyone is happy about that, but that's
just the way it is. IMHO if you're going to support proprietary
systems then you might as well try
On 8/25/05, Ashwin Kolhe [EMAIL PROTECTED] wrote:
You'll have something like this in your test
operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
i.e. you only need to test for op0's death if it is different from op1.
Paolo
Exactly.. this is the same thing as
Andi Kleen wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
I'm not sure what you're saying. The limitation on command-line
length can be in either the shell, or the OS. In Windows 2000, the
limitation comes primarily from the Windows command shell.
Linux has a similar limit which comes
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for that.
man xargs?
operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
Exactly.. this is the same thing as calling dead_or_set_p(insn,
operands[0]).
i am sorry, since we are using peephole2, the variable insn points
to the first insn in the template and not the last. so the call should
be
Marcin Dalecki wrote:
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for
On 8/25/05, Paolo Bonzini [EMAIL PROTECTED] wrote:
I consider this to be less readable than the peep2 way to do it,
especially if your peephole2 had three or four instructions. And
peep2_regno_dead_p uses an array (a circular buffer) so it's more
efficient. Indeed dead_or_set_p even has a
Ashwin Kolhe wrote:
On 8/25/05, Paolo Bonzini [EMAIL PROTECTED] wrote:
I consider this to be less readable than the peep2 way to do it,
especially if your peephole2 had three or four instructions. And
peep2_regno_dead_p uses an array (a circular buffer) so it's more
efficient. Indeed
On 2005-08-25, at 13:57, Paolo Bonzini wrote:
Marcin Dalecki wrote:
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and
Do you mean the source code? A hint: grep ^func_name *.c will get to it
for every function in gcc.
In this case it is in recog.c, look at peep2_reg_dead_p but also
peep2_regno_dead_p. There are other peep2_* functions you may use.
Paolo
I am sorry.. I think u got me wrong. I have had a
I'm not sure how I can fix MinGW; see above. Also, if a MinGW
application wants to invoke some other Windows program, the behavior
should be the same as if I compiled that application with Visual C, or
Intel's C compiler, or whatever; if we were using magic to pass
command-line
Mark's patch is apparently necessary for good Windows support,
Only on one out of three supported windows platforms. The other two
already have it as part of the os.
FWIW, I should note that GCJ already has support for @file
style list of input files:
http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
and has had it for quite some time now.
DJGPP and Cygwin hosted programs will never see these options, because
the runtime has already
DJ Delorie wrote:
I'm not sure how I can fix MinGW; see above. Also, if a MinGW
application wants to invoke some other Windows program, the behavior
should be the same as if I compiled that application with Visual C, or
Intel's C compiler, or whatever; if we were using magic to pass
DJ Delorie wrote:
Only on one out of three supported windows platforms. The other two
already have it as part of the os.
but that one out of three is by far the most
important one in practice!
Yup. Simple things like 'ls *' or 'rm -rf a*' can bring you all the joy.
I hesitate to point out that the problem isn't long command lines per
se, it's that we have a poor way of specifying large quantities of
information that, perhaps, belongs in an include file somehow.
#define FOOINC
Ranjit == Ranjit Mathew [EMAIL PROTECTED] writes:
Ranjit FWIW, I should note that GCJ already has support for @file
Ranjit style list of input files:
Ranjit http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
Ranjit and has had it for quite some time now.
Also, the interpretation of
Jim == James E Wilson [EMAIL PROTECTED] writes:
Jim The interface between the front ends and cgraph really needs to be
Jim worked out here. Currently, the C and C++ front ends are calling some
Jim cgraph functions in different orders, and we are having lots of debug
Jim related problems.
Let
On 8/25/05, DJ Delorie [EMAIL PROTECTED] wrote:
FWIW, I should note that GCJ already has support for @file
style list of input files:
http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
and has had it for quite some time now.
DJGPP and Cygwin hosted programs will never
On Thu, Aug 25, 2005 at 02:02:48PM +0530, Ashwin wrote:
However if the pattern happens to be something like this :
op0 = 1
op0 = op0 leftshift op2
Ah, I see. Well, peep2_reg_dead_p doesn't include or_set in its
definition, so it shouldn't do what you're suggesting. I wouldn't
be opposed to
Ive never been a big fan of having to call something to release
ssa_names, its too bug prone. I would much prefer to see something like
a cleanup pass done every once in a while... an ssa-name garbage
collector if you will :-). It seems to me that between major
optimization passes, any
On Wed, 2005-08-24 at 18:19 -0400, Andrew Pinski wrote:
I am writing a quick and dirty DCE pass which is faster the
current DCE and does not do anything with stores/loads.
FWIW, I've always been a fan of a very very simple DCE pass
which can be scheduled often, possibly after every pass that
On Wed, 2005-08-24 at 18:28 -0400, Daniel Berlin wrote:
If we take this after DCE, we still refer to a statement which no longer
exists which we don't collect in the GC.
As i said when i pointed this out to you, we should probably skip
walking common.chain on SSA_NAME.
But that's
* Andi Kleen:
Linux has a similar limit which comes from the OS (normally around 32k)
So it would be useful there for extreme cases too.
IIRC, FreeBSD has a rather low limit, too. And there were discussions
about command line length problems in the GCC build process on VMS.
On Thu, Aug 25, 2005 at 06:09:25PM +0200, Florian Weimer wrote:
* Andi Kleen:
Linux has a similar limit which comes from the OS (normally around 32k)
So it would be useful there for extreme cases too.
IIRC, FreeBSD has a rather low limit, too. And there were discussions
about command
And there were discussions about command line length problems in the GCC
build process on VMS.
The problem on VMS is not so much total command line length as element
length, e.g. strlen (argv [x]). A single element cannot exceed 1024
characters or something like that (have to look it up to
On Thu, Aug 25, 2005 at 06:09:25PM +0200, Florian Weimer wrote:
* Andi Kleen:
Linux has a similar limit which comes from the OS (normally around 32k)
So it would be useful there for extreme cases too.
IIRC, FreeBSD has a rather low limit, too. And there were discussions
about command
On Aug 24, 2005, at 3:54 PM, Jiang Long wrote:
After a while I got the following errors with :
configure: error: `target_alias' was not set in the previous run
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm
On Aug 25, 2005, at 6:19 AM, Ashwin Kolhe wrote:
I am actually trying to find out WHY and WHEN peep2_reg_dead_p
was introduced. I checked the mailing list but dint find anything
relavent.
Did you do a cvs diff/log and hunt it down, read the check-in
comment, then find a PR number and read
Mark Mitchell [EMAIL PROTECTED] writes:
I've created a new 4.2 Project page for response files, which is
what Microsoft calls files that contain command-line options.
Conventionally, if you pass @file as an argument to a program, the
file is read, and the contents are treated as command-line
On Thu, Aug 25, 2005 at 10:27:12AM -0700, Ian Lance Taylor wrote:
[ re: @file ]
Without getting into whether it's a good idea to overcome OS
limitations in this way, I do think that response files are a useful
feature even on Unix systems. But on Unix systems I think we need to
at least
feature even on Unix systems. But on Unix systems I think we need to
at least consider the possibility of real source file names starting
with '@'. The patch as it stands will have a rather perplexing effect
if such a file is compiled. Maybe that's OK.
What DJGPP and Cygwin do is thusly:
gcc -c ./@foop.cpp
and of course the same goes for files with names that begin with '-'.
That only works if the argument reflects a file name, and not some
other syntactical sugar. Granted, gcc has no such arguments, but
libiberty has a wider scope than just gcc.
On Thu, 2005-08-25 at 02:42 -0400, James Morrison wrote:
Hey,
I'm going to do more testing on this, but it seems this patch reduces the
number of DOM iterations from the number of else if statements in pr19097 to
2 DOM iterations.
Certainly any time we can optimize more of the comparisons
On Thu, Aug 25, 2005 at 06:49:06PM +0530, Ashwin Kolhe wrote:
I am actually trying to find out WHY and WHEN peep2_reg_dead_p
was introduced.
When the peephole2 pass was introduced. Another feature of the
peephole2 pass is that we can allocate *new* scratch registers,
and the pattern fails to
The following demonstrates a bug in combine
(x86 -mtune=pentiumpro -O2):
struct Flags {
int filler[18];
unsigned int a:14;
unsigned int b:14;
unsigned int c:1;
unsigned int d:1;
unsigned int e:1;
unsigned int f:1;
};
extern int bar(int), baz();
int foo (struct Flags *f) {
if
20548 seems to be fixed on x86_64 (I've put it in WAITING for powerpc
and hppa where it was also reported), but two new regressions appeared,
those are probably unrelated to your patch:
23564: c52104f c52104h (run) missing check
23565: c32001e (run x86_64 only) inccorect array bounds
I didn't
(Note! I am starting a new thread of an old thread because of old
thread's corruption which prevented me from responding).
Following test case:
struct S {
double d1, d2, d3;
};
struct S ms()
{
struct S s = {0,0,0};
return s;
}
Compiled with -O1 -mdynamic-no-pic
* Dale Johannesen:
The test of f-b comes out as
testl $1048512, 73(%eax)
This is wrong, because 4 bytes starting at 73 goes outside the
original object and can cause a page fault.
sizeof (struct Flags) is 76, so this isn't a bug, IMHO.
Forgot to attach the patch:
Index: i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.795.4.33
diff -c -p -r1.795.4.33 i386.c
*** i386.c 15 Aug 2005 23:36:10 - 1.795.4.33
--- i386.c
* Florian Weimer:
* Dale Johannesen:
The test of f-b comes out as
testl $1048512, 73(%eax)
This is wrong, because 4 bytes starting at 73 goes outside the
original object and can cause a page fault.
sizeof (struct Flags) is 76, so this isn't a bug, IMHO.
Scratch that, I obviously
On Aug 25, 2005, at 2:09 PM, Fariborz Jahanian wrote:
Compiled with -O1 -mdynamic-no-pic -march=pentium4 produces:
pxor%xmm0, %xmm0
movsd %xmm0, 16(%eax)
movsd %xmm0, 8(%eax)
movsd %xmm0, (%eax)
But following code results in 7% performance gain in
On Thu, Aug 25, 2005 at 10:27:12AM -0700, Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
I've created a new 4.2 Project page for response files, which is
what Microsoft calls files that contain command-line options.
Conventionally, if you pass @file as an argument to a
DJ Delorie wrote:
feature even on Unix systems. But on Unix systems I think we need to
at least consider the possibility of real source file names starting
with '@'. The patch as it stands will have a rather perplexing effect
if such a file is compiled. Maybe that's OK.
This is different
On Thu, Aug 25, 2005 at 10:51:42AM -0400, DJ Delorie wrote:
I'm not sure how I can fix MinGW; see above. Also, if a MinGW
application wants to invoke some other Windows program, the behavior
should be the same as if I compiled that application with Visual C, or
Intel's C compiler, or
On Thu, Aug 11, 2005 at 02:20:04PM -0400, Christopher Faylor wrote:
On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote:
Well, it's stopping a real fix for the MinGW build failure being made.
Adding #! support to libiberty won't work because the problem scripts
have MSYS/Cygwin paths for
pex-win32 is used by both MinGW and generic winnt targets, so I'd
say keeping it generic is preferred, but if MinGW can be detected, add
those checks too.
Using WindowsRoutinesForQueryingStuff is fine; that file is already
Win32 specific. Just don't break the mscdll stuff ;-)
Dale Johannesen [EMAIL PROTECTED] writes:
The test of f-b comes out as
testl $1048512, 73(%eax)
This is wrong, because 4 bytes starting at 73 goes outside the
original object and can
cause a page fault. The change from referencing a word at offset 72
to offset 73
happens in
Fariborz Jahanian [EMAIL PROTECTED] writes:
Forgot to attach the patch:
Index: i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.795.4.33
diff -c -p -r1.795.4.33 i386.c
*** i386.c 15 Aug
On Thu, Aug 25, 2005 at 12:37:32PM -0700, Ian Lance Taylor wrote:
Fariborz Jahanian [EMAIL PROTECTED] writes:
Forgot to attach the patch:
Index: i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving
On Thu, Aug 25, 2005 at 02:59:24PM -0400, DJ Delorie wrote:
pex-win32 is used by both MinGW and generic winnt targets, so I'd
say keeping it generic is preferred, but if MinGW can be detected, add
those checks too.
So, should it default to finding an executable on the path first and
then look for
So, should it default to finding an executable on the path first and
then look for MinGW/MSYS versions of the program if it can't find
the executable on the path?
Hmmm... 99% of the cases will be #!/bin/sh anyway. What's the
right shell to run for that in MinGW? If you can detect MinGW[*],
On Aug 25, 2005, at 12:47 PM, H. J. Lu wrote:
On Thu, Aug 25, 2005 at 12:37:32PM -0700, Ian Lance Taylor wrote:
Fariborz Jahanian [EMAIL PROTECTED] writes:
Forgot to attach the patch:
Index: i386.c
===
RCS file:
On Aug 25, 2005, at 3:59 PM, Fariborz Jahanian wrote:
I think the problem may be somewhere else. I got the same xmm0 code
sequence on Linux/ia32 with -msse3 -mfpmath=sse. However, I got
xorl%eax, %eax
movq%rax, 16(%rdi)
movq%rax, 8(%rdi)
movq
Mark Mitchell wrote:
However, there's demonstrable interest in this feature for GNU/Linux as
well, from the lists, and for Java on all operating systems.
Please don't use '@filename' on Linux, use a normal switch with an
argument. The problems of '-' being used for switches is bad enough
On Thu, Aug 25, 2005 at 04:00:53PM -0400, DJ Delorie wrote:
So, should it default to finding an executable on the path first and
then look for MinGW/MSYS versions of the program if it can't find
the executable on the path?
Hmmm... 99% of the cases will be #!/bin/sh anyway. What's the
right
On Thu, Aug 25, 2005 at 12:37:32PM -0700, Ian Lance Taylor wrote:
For what it's worth, as I told Fariborz, I suspect that returning 0 is
correct for SFmode, but I'm somewhat doubtful for DFmode.
Indeed.
And his test case is odd since the resulting code has more instructions
and is larger.
Ralf Schubert wrote:
is there any reference about the warning- and error-messages gcc (e.g.
4.0.1) produces when compiling a C-source code ?
What I'm looking for is a summary with some explanations. I tried hard,
but couldn't find something suitable.
We don't have a list of all of the
Dale Johannesen wrote:
This is wrong, because 4 bytes starting at 73 goes outside the original
object and can
cause a page fault.
FYI You can write a testcase for this by using mmap to allocate a page
of memory, putting a copy of the structure 76 bytes from the end of the
mmapped region, and
Etienne Lorrain wrote:
Investigated again a big increase of size going from GCC-3.4 to 4.x
(gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
to reproduce:
If you want this fixed, you should file a bug report into our bugzilla
database.
Here is a quicker way to
-Original Message-
From: jacky
Sent: Monday, Aug 20, 2005 5:14 PM
To: Amelie
Cc: Vera, Chris
Subject: wow !
http://optimum.atw.hu
Tristan Wibberley wrote:
Mark Mitchell wrote:
However, there's demonstrable interest in this feature for GNU/Linux as
well, from the lists, and for Java on all operating systems.
Please don't use '@filename' on Linux, use a normal switch with an
argument. The problems of '-' being used
but I don't think DJ and I are yet seeing eye-to-eye on (b).
I think it's a bad idea to choose a solution that requires each
application (we have many) to be modified to call an extra function.
It would be far better to have the OS manage it transparently.
However, I don't see a way to do that
Snapshot gcc-4.0-20050825 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050825/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050825
You'll find
Can you recommend a solution for compiling Windows DLLs on any
variation of UNIX?
We currently do this with Cygwin/Windows, but would like to go one
step further and do the builds on a UNIX machine that produces
Windows DLLs.
Thanks for any advice,
Ivan
On Aug 25, 2005, at 5:09 PM, Ivan Novick wrote:
Can you recommend a solution for compiling Windows DLLs on any
variation of UNIX?
Yes, just use cygwin, see the cygwin folks for details.
Yes understood, but thats the whole point, cygwin runs on a windows
machine... I would like to use a UNIX machine to compile the Windows
DLL.
From a system admin point of view, we would like to have a UNIX
compile host to produce the DLL, since we primarily only deal with
UNIX anyway.
On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote:
Yes understood, but thats the whole point, cygwin runs on a windows
machine... I would like to use a UNIX machine to compile the
Windows DLL.
You can cross compile to cygwin using gcc.
An old link from google with cross compiler cygwin is
Ivan Novick [EMAIL PROTECTED] wrote:
Can you recommend a solution for compiling Windows DLLs on any variation of
UNIX?
You want mingw, I think. The doc for this is somewhat scanty.
See e.g.
http://www.mingw.org/mingwfaq.shtml#faq-cross
On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote:
Yes understood, but thats the whole point, cygwin runs on a windows
machine...
Odd, I was running it on a solaris machine not windows. Maybe you
forgot to recompile it on a UNIX machine?
configure --with-headers=/cygwin/usr/include
I am nearly ready to commit this patch but I went overboard and had it
search in mingw and MSYS locations for the program to run (i.e.,
/bin/sh).
Since there's no MinGW shell, there's no point in looking in there.
Then it occurred to me that maybe this was a little too
product specific for
Attached file tells everything.
On Thu, Aug 25, 2005 at 11:00:50AM -0400, DJ Delorie wrote:
FWIW, I should note that GCJ already has support for @file
style list of input files:
http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
and has had it for quite some time now.
DJGPP and Cygwin hosted programs will
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-25
06:02 ---
Fixed on mainline and the 4.0 branch by Paolo Bonzini's
patch for PR23517.
--
What|Removed |Added
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-25
06:03 ---
DOM also eats a metric ton of memory on this testcase. 900MB with C3(1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-25
06:40 ---
Subject: Bug 23546
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-25 06:40:14
Modified files:
gcc: ChangeLog tree-ssa-loop-im.c
Log
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-25
07:03 ---
FOO! The exact testcase I have been testing for the last couple days has been
#define CL0(a) if (b == a) { foo (); } , so all the work DOM was doing converts
the if's to else if's .
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-25
07:05 ---
Subject: Bug 23546
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-25 07:03:00
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-25
07:38 ---
Subject: Bug 23546
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-25 07:37:22
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-25
08:26 ---
Subject: Bug 23465
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-25 08:26:18
Modified files:
libstdc++-v3 :
--- Additional Comments From pcarlini at suse dot de 2005-08-25 08:27
---
Fixed for 4.0.2.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-25
09:06 ---
Subject: Bug 20817
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-25 09:06:45
Modified files:
gcc/cp : ChangeLog typeck.c
--- Additional Comments From nathan at gcc dot gnu dot org 2005-08-25
09:16 ---
fixed mainline and 4.0
2005-08-25 Nathan Sidwell [EMAIL PROTECTED]
PR c++/20817
* typeck.c (build_x_unary_op): Make sure OFFSET_REF is not for a
-*.
--
What
1 - 100 of 190 matches
Mail list logo
