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
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.
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 collateral
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)
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 ;
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.
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 VEC.
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
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
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 find
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 *
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 higher
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
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 it
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
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
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 are
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 defines
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
[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, having super
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
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 understand, were never
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
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
[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;
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 visible
--- Additional Comments From jpr at essi dot fr 2005-05-01 06:10 ---
Subject: Re: Configuring g++ library for various locales
?
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-04-30 21:24
---
For that kind of GNU x86-linux platform
Linux (Fedora Core 3)
Pentium M
GCC 4.0.0
Compiling the following two classes produces error:
p2/B.java:7: error: Method p1.A.f(int) was defined with return type
booleanin class p1.A.
void f( int x ) {}
/// A.java ///
package p1;
public class A
{
boolean f( int x ) { return
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
07:23 ---
Subject: Bug 19579
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2005-05-01 07:23:20
Modified files:
gcc:
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-01 08:00 ---
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
08:08 ---
Subject: Bug 18316
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-01 08:08:14
Modified files:
gcc: ChangeLog tree-scalar-evolution.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
08:08 ---
Subject: Bug 19126
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-01 08:08:14
Modified files:
gcc: ChangeLog tree-scalar-evolution.c
--- Additional Comments From olh at suse dot de 2005-05-01 08:10 ---
gcc-3_4-branch takes only 5 minutes to complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21304
the following code takes more than twice as long to run when compiled with -Os
using gcc-4.0.0 than it does with 3.3.5 or 3.4.3.
#include stdio.h
#include vector
class mytype_A {
public:
int id;
mytype_A():id(0) {}
};
class mytype_B {
public:
mytype_A* A;
mytype_B(mytype_A* p):A(p)
--- Additional Comments From deemkay at gmail dot com 2005-05-01 08:31
---
Created an attachment (id=8780)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8780action=view)
cpptest.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
--- Additional Comments From pcarlini at suse dot de 2005-05-01 09:06
---
That's the point, I do not have these lines (I attach my c++locale.h
from my 4.0.0 by=uild, since it is short).
Therefore, for some reason, the configury decided not to enable the GNU locale
model (there are
--- Additional Comments From pcarlini at suse dot de 2005-05-01 09:15
---
In the 4.0 configure, the relevant tests start at line 5668, corresponding to
the code starting at line 1097 in acinclude.m4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
The typical error message is:
Executing on host: /opt/build/eric/gcc-4_0-branch/gcc/testsuite/../gfortran
-B/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../
/home/eric/cvs/gcc-4_0-branch/gcc/testsuite/gfortran.dg/blockdata_1.f90 -Os
-pedantic-errors
--- Additional Comments From chris at bubblescope dot net 2005-05-01 10:08
---
Woops, false alarm, somehow I'd horribly, horribly messed up something. A clean
OS reinstall seems to
have cleared up this, and another unrelated problem. Sorry
--
What|Removed
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-01 10:10
---
For some reason the patch applied for the 19542 duplicate of this bug has only
been applied to 4.0 branch (although normally all fixes should go on mainline
first).
--
What|Removed
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-01 10:14
---
Appeared on ia64-hpux between 2005-04-13 19:01 UTC and 2005-04-13 19:04 UTC
(regression searching compiling vect-none.c with -O2 -ftree-vectorize). I.e.,
caused by
2005-04-13 Devang Patel [EMAIL
--- Additional Comments From jpr at essi dot fr 2005-05-01 10:16 ---
Subject: Re: Configuring g++ library for various locales
?
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-05-01 09:06
---
That's the point, I do not have these
--- Additional Comments From pcarlini at suse dot de 2005-05-01 10:31
---
Now I installed also the German locale, and everything seems OK.
Excellent!
instead of forcing the German one (which appears to me a little
Süse-oriented ;-)).
What if I tell you that the author of that
--- Additional Comments From pcarlini at suse dot de 2005-05-01 10:33
---
... wanted to add: So after all, you like the German culture and de_DE it's
ok with you ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
10:33 ---
Subject: Bug 11459
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-01 10:33:40
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
10:33 ---
Subject: Bug 18502
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-01 10:33:40
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
10:39 ---
Subject: Bug 20740
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-01 10:39:15
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
10:44 ---
Subject: Bug 21213
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-01 10:44:10
Modified files:
gcc:
--
What|Removed |Added
Target Milestone|4.0.0 |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11459
--
What|Removed |Added
Target Milestone|4.0.1 |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20740
--
What|Removed |Added
Target Milestone|4.0.1 |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21213
--- Additional Comments From jpr at essi dot fr 2005-05-01 11:21 ---
Subject: Re: Configuring g++ library for various locales
?
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-05-01 10:31
---
Now I installed also the German
--- Additional Comments From jpr at essi dot fr 2005-05-01 11:24 ---
Subject: Re: Configuring g++ library for various locales
?
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-05-01 10:33
---
... wanted to add: So after all, you like
--- Additional Comments From ch dot ehrlicher at gmx dot de 2005-05-01
11:28 ---
the patch in comment #5 works for me
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-01 11:32
---
It should be possible to use the existing machinery in the C++ front end which
diagnoses jumps into the scope of initialized or non-POD variables to diagnose
jumps into VLA or VM scope (treating VLA or VM
--- Additional Comments From pcarlini at suse dot de 2005-05-01 11:39
---
OK for the documentation, except ... that this is not the one that you
read when you install gcc from scratch ! Although libstdc++ is now part
of gcc, there is no link from the files in gcc-xxx/INSTALL to the
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
12:04 ---
Investigating.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
12:12 ---
Basically same problem as PR target/19933.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
12:21 ---
GCC does not yet have __builtin_isfinite or __builtin_isnormal functions;
they
would be generically useful additions if they always avoided falling back to
a library function. __builtin_fpclassify
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:07 ---
I really think that Devang's patch exposed a latent bug either in expand or in
the target specific files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21050
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:16 ---
Confirmed.
--
What|Removed |Added
URL|
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:17 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:17 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
The sample code runs 30-50% slower on my machine when compiled with 3.4.3 as
opposed to 3.3.4. It creates some objects and then references them via pointer
lookup, so my best guess is that somehow 3.4.3 binaries have many more cache
misses.
I have noticed the severe regression on AMD Athlon
--- Additional Comments From kpmassey at gmail dot com 2005-05-01 13:23
---
Created an attachment (id=8781)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8781action=view)
source file that illustrates problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
--- Additional Comments From kpmassey at gmail dot com 2005-05-01 13:25
---
Created an attachment (id=8782)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8782action=view)
.ii file from my compilation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
--- Additional Comments From kpmassey at gmail dot com 2005-05-01 13:26
---
Created an attachment (id=8783)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8783action=view)
.s file from my compilation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
Excerpt from the log file:
,.,. C954025 ACATS 2.5 05-05-01 03:33:45
C954025 Check that if the original entry call was a conditional or
timed entry call, the expiration time for a requeue with
abort is the original expiration time.
* C954025 not enough time
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
13:27 ---
By Rainer:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01800.html
--
What|Removed |Added
--
What|Removed |Added
Component|c++ |target
Keywords||missed-optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:34 ---
-Os is compile for size if the size is smaller than there is no bug. We don't
care about runtime speed
really at -Os.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:35 ---
Oh, also I cannot reproduce the slow down that you are getting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:35 ---
Also this is a modified compiler from Gentoo, can you try an unmodified one.
--
What|Removed |Added
--
What|Removed |Added
Component|c++ |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:46 ---
Fixed. Thanks Zdenek.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:48 ---
On PPC, there are two extra mr's in the first case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:49 ---
Oh, I have forgotten to say the IV opt is caught though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
13:50 ---
Confirmed.
--
What|Removed |Added
OtherBugsDependingO||13607
--
What|Removed |Added
Last reconfirmed|2004-11-12 17:12:21 |2005-05-01 13:55:20
date||
Summary|ICE compiling
--
What|Removed |Added
OtherBugsDependingO||346
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18244
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:01 ---
libmudflap does the same thing, see PR 18244.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:01 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:05 ---
Is this true anymore, I built classpath a couple of days ago on powerpc-darwin
with a case-insensitive
file system and it worked for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17845
--
Bug 18883 depends on bug 15164, which changed state.
Bug 15164 Summary: trans-decl.c:411: gfc_finish_var_decl: Assertion failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15164
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:14 ---
Fixed for 4.0.0.
--
What|Removed |Added
Status|NEW
--
Bug 19282 depends on bug 18769, which changed state.
Bug 18769 Summary: gfortran: ICE in gfc_conv_array_initializer with array
initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:17 ---
Fixed for 4.0.0.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:19 ---
Fixed for 4.0.0.
--
What|Removed |Added
Status|NEW
--
Bug 19276 depends on bug 18283, which changed state.
Bug 18283 Summary: gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18283
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:19 ---
Fixed for 4.0.0.
--
What|Removed |Added
Status|NEW
--
Bug 19276 depends on bug 18689, which changed state.
Bug 18689 Summary: Internal compiler error with character pointer association
in module subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:20 ---
Fixed for 4.0.0.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:21 ---
Fixed for 4.0.0.
--
What|Removed |Added
Status|NEW
--- Additional Comments From joseph at codesourcery dot com 2005-05-01
14:24 ---
Subject: Re: Problem with define of HUGE_VAL in math_c99.
On Sun, 1 May 2005, ebotcazou at gcc dot gnu dot org wrote:
In principle all the macros can be defined along the lines of
the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:25 ---
This is a dup of bug 19181.
*** This bug has been marked as a duplicate of 19181 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:25 ---
*** Bug 21300 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
CC||redi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
--- Additional Comments From giovannibajo at libero dot it 2005-05-01
14:26 ---
Yes, mostly we don't care, but it's a two-fold regression so it should be
justified by a significant decrease in size, otherwise it's just a bad
regression. I almost think it's because of Honza's inline
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
14:33 ---
(In reply to comment #2)
I worked around this bug, commenting a line in /mingw/include/math.h (I quote
it
here for reference):
//_CRTIMP double __cdecl cabs (struct _complex);
The end of the
1 - 100 of 199 matches
Mail list logo