One more thing I forgot to mention is that, I am working on a rather old
version of gcc - 2.95.2 for some reasons.
Krishna.
On Sat, 28 May 2005, Ian Lance Taylor wrote:
#N V Krishna [EMAIL PROTECTED] writes:
#
# I am trying to do some modifications to the register allocator and for the
#
R Hill [EMAIL PROTECTED] writes:
| Gerald Pfeifer wrote:
| On Fri, 27 May 2005, R Hill wrote:
|
| a tiny detail, but i figured i would mention it. congratulations.
| Thanks, I just installed your patch.
| Gerald
|
| Just curious, are you guys interested in these types of brain dead
|
On Thu, 26 May 2005, Scott Robert Ladd wrote:
I prefer breaking out the hardware intrinsics from
-funsafe-math-optimizations, such that people can compile to use their
hardware *without* the other transformations implicit in the current
collective.
If someone can explain how this hurts
--- Uros Bizjak wrote:
At this point, I wonder what is wrong with Bugzilla,
that those
programmers don't fill a proper bug report. If there
is a problem with
GCC, that is so annoying to somebody, I think that
at least developers
could be informed about it via their standard
channels of
On Wed, 25 May 2005, Olly Betts wrote:
This page mentions the website :
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=index
while www2.iro.umontreal.ca has no DNS resolution.
It does resolve now; but then the webserver returns a 302 redirect to the
same URI at
Haren Visavadia wrote on 29/05/2005 10:51:00:
You can search Bugzilla as well, so you do not fill in
duplicate bug report.
Unfortunately, this is not 100% correct. Recently I have filed several
duplicates, *after* searching Bugzilla.
1. There are too many ways to phrase a title, and too
Michael Veksler [EMAIL PROTECTED] wrote:
Unfortunately, this is not 100% correct. Recently I have filed several
duplicates, *after* searching Bugzilla.
That is not a problem. Bugmasters are there exactly for that. We realize that
finding duplicates can be very hard (in fact, sometimes
Vincent Lefevre [EMAIL PROTECTED] wrote:
At this point, I wonder what is wrong with Bugzilla, that those
programmers don't fill a proper bug report. If there is a problem
with GCC, that is so annoying to somebody, I think that at least
developers could be informed about it via their standard
--- Michael Veksler wrote:
Unfortunately, this is not 100% correct. Recently I
have filed several
duplicates, *after* searching Bugzilla.
1. There are too many ways to phrase a title, and
too many
times I search for wrong words.
2. The same bug may have several different user
From: Diego Novillo [EMAIL PROTECTED]
On Sat, May 28, 2005 at 12:09:51PM -0400, Paul Schlie wrote:
- Yes thanks; but my point was that the result of comparison should remain
'_Bool' not 'int', and be properly promoted to likely 'char' not 'int'. As
for VRP to be most useful it needs to
On Sun, May 29, 2005 at 08:53:55AM -0400, Paul Schlie wrote:
Only because I perceived it to be necessary to most ideally/optimally
preserve the value-range result of a comparison expression. As it was
unclear if a comparison expression were defined as having an 'int' vs.
'bool' result type,
Giovanni Bajo wrote on 29/05/2005 13:54:39:
Vincent Lefevre [EMAIL PROTECTED] wrote:
Perhaps because GCC developers think that GCC isn't buggy when the
processor doesn't do the job for them? (I'm thinking of bug 323.)
You are mistaken, we think GCC isn't buggy about 323 because the
Giovanni Bajo wrote on 29/05/2005 13:50:59:
Michael Veksler [EMAIL PROTECTED] wrote:
[2] GCC could implement a better error message.
This is a bug, too. You can file a PR in Bugzilla explictly asking for a
more
informative error message.
PR 21808
Michael
In article [EMAIL PROTECTED] you write:
http://csdl.computer.org/dl/mags/co/2005/05/r5091.pdf
An Open Question to Developers of Numerical Software, by
W. Kahan and D. Zuras
Doesn't look publically accessible from my machine...
Gerald Pfeifer [EMAIL PROTECTED] writes:
For example, I could easily create a key for Gabriel Dos Reis
[EMAIL PROTECTED] and upload it to the key servers, or some evil hacker
could do something similar.
And, in fact, people do; this is not just theoretical. There is an extra
(unsigned) key
Gabriel Dos Reis wrote:
yes, if you spot any inconsistency I'm very happy to accept a patch
;-)
I noticed that on http://gcc.gnu.org/install/specific.html#windows it
states:
A port of GCC 2.95.2 and 3.x is included with the Cygwin environment.
However, the Cygwin project had to remove its
William Beebe [EMAIL PROTECTED] writes:
OK, then let me explain it to you. The problem with the GCC Bugzilla
reporting system is that it's a system that only other developers can
tolerate, let alone love.
Setting aside for the moment that GCC is a software package *targetted* at
developers,
Gabriel Dos Reis wrote:
yes, if you spot any inconsistency I'm very happy to accept a patch
;-)
Also, the link GCC Frontend HOWTO on readings.html is 404 compliant.--- readings.html.orig 2005-05-29 11:23:38.405875000 -0700
+++ readings.html 2005-05-29 11:24:03.405875000 -0700
@@ -75,7
On Sun, 29 May 2005, Giovanni Bajo wrote:
You are mistaken, we think GCC isn't buggy about 323 because the C/C++
standards do not tell us to do better than this. If you have higher
expectations about floating point and C/C++, you should file a bugreport
against the C/C++ standards.
This is
Marc Espie wrote:
Sorry for chiming in after all this time, but I can't let this pass.
Scott, where on earth did you pick up your trig books ?
Sorry, too, but why one earth do modern time mathematics scholars
think that sine and cosine are bound to have to do with an equally
modern notion of
Georg Bauhaus [EMAIL PROTECTED] writes:
| Marc Espie wrote:
| Sorry for chiming in after all this time, but I can't let this pass.
| Scott, where on earth did you pick up your trig books ?
|
| Sorry, too, but why one earth do modern time mathematics scholars
| think that sine and cosine are
On Sun, May 29, 2005 at 08:59:00PM +0200, Georg Bauhaus wrote:
Marc Espie wrote:
Sorry for chiming in after all this time, but I can't let this pass.
Scott, where on earth did you pick up your trig books ?
Sorry, too, but why one earth do modern time mathematics scholars
think that sine
I've got my build on OpenBSD-i386 stuck in a loop compiling
stage2/xgcc -Bstage2/ -B/usr/local/i386-unknown-openbsd3.7/bin/ -c -O2 -g
-fomit-frame-pointer -gnatpg -gnata -I- -I. -Iada
-I/spare/ports/lang/gcc/4.1/w-gcc-4.1-20050528/gcc-4.1-20050528/gcc/ada
On May 29, 2005, at 4:08 PM, Marc Espie wrote:
I've got my build on OpenBSD-i386 stuck in a loop compiling
stage2/xgcc -Bstage2/ -B/usr/local/i386-unknown-openbsd3.7/bin/ -c -O2
-g -fomit-frame-pointer -gnatpg -gnata -I- -I. -Iada
On Sun, May 29, 2005 at 01:22:55PM +0300, Michael Veksler wrote:
Haren Visavadia wrote on 29/05/2005 10:51:00:
You can search Bugzilla as well, so you do not fill in
duplicate bug report.
Unfortunately, this is not 100% correct. Recently I have filed several
duplicates, *after*
On Sun, 29 May 2005, Brian Dessent wrote:
Also, the link GCC Frontend HOWTO on readings.html is 404 compliant.
Thanks, I just installed your patch. Keep this patches coming! :-)
Gerald
--
What|Removed |Added
Component|c |rtl-optimization
Keywords||wrong-code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
06:47 ---
Subject: Bug 21639
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 06:47:08
Modified files:
gcc: ChangeLog tree-complex.c
Log
Following PR21639 (and http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02604.html):
there are several places in loop opts that are not GGC-safe (in
particular the tree nodes refered from loop structures are not
seen by garbage collector, and I think there are some other instances).
This PR is an
--- Additional Comments From ismail at kde dot org dot tr 2005-05-29 07:41
---
Will the patch be applied to 4.0 branch too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
--- Additional Comments From aj at gcc dot gnu dot org 2005-05-29 08:44
---
This ICE happens also with one of the SPEC CPU 2005 candidate benchmarks.
I used:
GNU Fortran 95 (GCC 4.0.1 20050529 (prerelease))
on Linux/x86-64.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
12:23 ---
Subject: Bug 20006
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:50
Modified files:
gcc/fortran: ChangeLog io.c
libgfortran
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
12:23 ---
Subject: Bug 20006
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:50
Modified files:
gcc/fortran: ChangeLog io.c
libgfortran
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29
12:40 ---
Configuring with --enable-maintainer-mode fails:
/home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/
-B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem
The bug leads to corruption of program's data. Two objects on the stack overlap
so that the constructor of the second one erases some data of the first one.
I've checked the whole program with valgrind and it didn't report anything
incorrect that I might have done with memory allocation,
Using a host system of Linux 2.6.8.1, binutils version 2.16 and the
aforementioned GCC, I have observed the following gcc segmentation faults:
util-linux-2.12q: -pipe -O2 -mtune=i486 -fomit-frame-pointer (defaults)
fdiskbsdlabel.c: In function 'bselect' (void):
fdiskbsdlabel.c: 164: internal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
14:06 ---
Could you attach the preprocessed source?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
14:09 ---
*** This bug has been marked as a duplicate of 21790 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
14:09 ---
*** Bug 21807 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21790
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
14:16 ---
(In reply to comment #12)
Will the patch be applied to 4.0 branch too?
No because it is too big in that it also changes the inliner to be a CFG aware
inliner.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
14:40 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
14:40 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
Template code that used to work prior to gcc-3.4
fails in very uninformative ways. Diagnostic should
be improved.
For example:
$ cat t.cpp
template class T struct A { T t; };
// Swap following 2 functions to get conforming C++
template class T void foo(const AT data)
{
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:02 ---
The testcase really boils down to:
template typename T int foo ();
int i = foo(1);
OR
template typename T struct f{};
template typename T int foo (fT);
int i = foo(1);
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
16:02 ---
Subject: Bug 17193
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11
Modified files:
gcc/fortran: trans-array.c trans-expr.c
Log
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:02 ---
*** Bug 21808 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:02 ---
If you called a different function name instead of a template one, I get the
following error:
t.cc: In function void foo(const AT):
t.cc:7: error: there are no arguments to foo1 that depend on a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
16:02 ---
Subject: Bug 17192
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11
Modified files:
gcc/fortran: trans-array.c trans-expr.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
16:02 ---
Subject: Bug 16939
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11
Modified files:
gcc/fortran: trans-array.c trans-expr.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
16:02 ---
Subject: Bug 18689
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11
Modified files:
gcc/fortran: trans-array.c trans-expr.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
16:02 ---
Subject: Bug 17202
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11
Modified files:
gcc/fortran: trans-array.c trans-expr.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
16:02 ---
Subject: Bug 18890
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11
Modified files:
gcc/fortran: trans-array.c trans-expr.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
16:02 ---
Subject: Bug 21297
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11
Modified files:
gcc/fortran: trans-array.c trans-expr.c
Log
This problems occurs with GCC 3.4.4, gcc-4.0-20050521 snapshot and
gcc-4.1-20050528 snapshot.
test-case.c:
#include assert,h
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}
This case (test-case.c) works with gcc -O0 without a problem.
But with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:24 ---
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:24 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:39 ---
Note every GCC from 2.95.3 gives the same result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
16:44 ---
x and a should be identical, so assertion should not fail at all.
since a is assigned to x, it has *SAME* rounding precision.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
17:04 ---
This is a target problem, as the RTL is correct.
Looks like there is a forgotten rounding back to float.
--
What|Removed |Added
--- Additional Comments From mark at codesourcery dot com 2005-05-29 17:18
---
Subject: Re: [3.4 regression] local classes as template argument
Geoffrey Keating wrote:
Hi Mark,
Consider this code:
struct Attribute { };
template class T void fun (const Attribute attr, const T
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
17:58 ---
This also occurs with double, using test-case.c but with float replaced with
double, so code fragment looks like:
test-case.c:
#include assert,h
volatile double x = 3;
int main()
{
double a = 1 / x;
x =
--
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21695
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
18:27 ---
(In reply to comment #5)
Should I put this as separate PR?
Actually this is all a dup of bug 323. The problem is excessive pression,
which most non fp
developers will not know about, read the full PR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
18:27 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:01 ---
It should be logical equivalent regardless of how it stored in memory.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:06 ---
when you store it to memory the precission goes down (aka rounding) read 323
and all the rest of the
problems related to it.
*** This bug has been marked as a duplicate of 323 ***
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:06 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:18 ---
Surely assigning a float value to another float variable should not cause any
rounding as they are same data type.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:24 ---
Please go read the papers. Basically x87 is broken in this respect, use either
a different machine or use
SSE.
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:24 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:28 ---
Read the code carefully:
test-case.c:
#include assert,h
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}
Notice x = a before assertion, both of these variables are of the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:31 ---
(In reply to comment #11)
This is *not* related to precission.
This is behaviour, you would expect from a compiler.
For non floating point, yes but floating point is different with respect with
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:32 ---
(In reply to comment #10)
Please go read the papers. Basically x87 is broken in this respect, use
eithera different machine or use
SSE.
It be good idea to do that by default then?
--
What
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29
19:32 ---
To be more precise, on i686-pc-linux-gnu, I created an empty directory, cd'd
into it, and then ran
../gcc-4.0/configure --prefix=$HOME --enable-maintainer-mode
--enable-languages=c,f95
make bootstrap
Same
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:35 ---
(In reply to comment #13)
(In reply to comment #10)
Please go read the papers. Basically x87 is broken in this respect, use
eithera different machine or use
SSE.
It be good idea to do that by
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:35 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:36 ---
It be good idea to do that by default then?
It is on x86_64, remember SSE is not every where.
x86-64 has support for SSE3 so it would use that instead.
--
What|Removed
--- Additional Comments From joseph at codesourcery dot com 2005-05-29
19:37 ---
Subject: Re: New: [3.4/4.0/4.1 Regression]
Floating Optimization Bug
On Sun, 29 May 2005, themis_hv at yahoo dot co dot uk wrote:
This case (test-case.c) works with gcc -O0 without a problem.
But
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:43 ---
(In reply to comment #15)
x86-64 has support for SSE3 so it would use that instead.
Actually that is wrong, the subset which is supported by AMD and Intel (EM64T)
only have SSE, SSE2,
and MMX. AMD's
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:43 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:46 ---
Again just use -ffloat-store as required not get the excessive precision.
This should included in gcc spec file by defaults.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:47 ---
That is not going to change, the assert is allowed to fail by the standard by
the way.
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:47 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:51 ---
(In reply to comment #19)
That is not going to change, the assert is allowed to fail by the standard by
the way.
Yes, assert fails in some cases (I think of a hundred at moment!).
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:56 ---
(In reply to comment #20)
Yes, assert fails in some cases (I think of a hundred at moment!).
See now you did not read my comment, I said it is _ALLOWED by the
standard to ___FAIL___.
How much
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:56 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--
What|Removed |Added
GCC build triplet|powerpc-unknown-linux-gnu |
GCC host triplet|powerpc-unknown-linux-gnu |
GCC target triplet|powerpc-unknown-linux-gnu
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
20:09 ---
You seem like someone who does not want to do the leg work
of getting your programs fixed so you don't depend on this.
Regardless, other poeple dependant on it.
--
--- Additional Comments From veksler at il dot ibm dot com 2005-05-29
20:33 ---
I disagree.
1. Because it is a template the correct error is supressed.
2. It passes with gcc-3.3, but fails with gcc-3.4.3
This is unlike your example:
template class T struct A { T t; };
// Swap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
20:37 ---
But the problem with the error message is the same which is why I closed it as
a dup. My point is that
being in a template have nothing to do with it here and the error message could
be improved yes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
20:37 ---
*** Bug 21808 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
20:45 ---
Subject: Bug 19933
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-29 20:45:44
Modified files:
gcc:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-29
20:52 ---
Patch backported to 3.4 branch.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 21315 depends on bug 19933, which changed state.
Bug 19933 Summary: Problem with define of HUGE_VAL in math_c99.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
What|Old Value |New Value
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-29
21:27 ---
See:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02777.html
for additional analysis regarding this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
When you compile a program with -pg against libexpat 1.95.8 and you call
XML_ParserCreate() it does crash. this is not happening, if you don't add -pg.
The source I used was distributed with the official MAME source code package
(http://www.mame.net/downmain.html - win32 sourcecode, but the
--- Additional Comments From oliverst at online dot de 2005-05-29 23:38
---
If this is not going to be added any time soon for C++, maybe at least the
manual should reflect, that it is a C-only warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19756
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
23:41 ---
Are you sure that this is not a newlib/cygwin bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
-- Compiler ---
Reading specs from C:/WinAVR/bin/../lib/gcc/avr/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=m:/WinAVR --build=mingw32
--host=mingw32 --target=avr --enable-languages=c,c++ --with-dwarf2
Thread model: single
gcc version 3.4.3
-- Error
1 - 100 of 124 matches
Mail list logo
