Quoting Jan Hubicka [EMAIL PROTECTED]:
If you make FPCTR/MXCSR real registers, you will need to add use to all
the arithmetic and move pattern that would consume quite some memory and
confuse optimizers. I think you can get better around simply using volatile
unspecs inserted by LCM pass
Diego Novillo [EMAIL PROTECTED] writes:
On Wed, May 25, 2005 at 03:37:29PM -0600, Jeffrey A Law wrote:
So, if I wanted to be able to bootstrap Ada, what I do I need
to do? Disable VRP?
Applying the patches in the PRs I mentioned. If that doesn't
work, try with VRP disabled.
Does not
Kaveh R. Ghazi [EMAIL PROTECTED] writes:
|Now we have e.g. XNEW* and all we need is a new -W* flag to catch
|things like using C++ keywords and it should be fairly automatic to
|keep incompatibilities out of the sources.
|
| Why not this?
|
| #ifndef __cplusplus
| #pragma
On 2005-05-25 19:27:21 +0200, Allan Sandfeld Jensen wrote:
Yes. I still don't understand why gcc doesn't do -ffast-math by
default like all other compilers.
No! And I really don't think that other compilers do that.
It would be very bad, would not conform to the C standard[*]
and would make
Allan Sandfeld Jensen wrote:
Yes. I still don't understand why gcc doesn't do -ffast-math by
default like all other compilers.
Vincent Lefevre wrote:
No! And I really don't think that other compilers do that.
It would be very bad, would not conform to the C standard[*]
and would make lots of
On 5/26/05, Scott Robert Ladd [EMAIL PROTECTED] wrote:
Allan Sandfeld Jensen wrote:
Yes. I still don't understand why gcc doesn't do -ffast-math by
default like all other compilers.
Vincent Lefevre wrote:
No! And I really don't think that other compilers do that.
It would be very bad,
On Thu, 26 May 2005, Vincent Lefevre wrote:
On 2005-05-25 19:27:21 +0200, Allan Sandfeld Jensen wrote:
Yes. I still don't understand why gcc doesn't do -ffast-math by
default like all other compilers.
No! And I really don't think that other compilers do that.
Have you looked, or are you
Scott Robert Ladd [EMAIL PROTECTED] wrote:
May I be so bold as to suggest that -funsafe-math-optimizations be
reduced in scope to perform exactly what it's name implies:
transformations that may slightly alter the meanding of code. Then move
the use of hardware intrinsics to a new -fhardware-math
On Thursday 26 May 2005 14:25, Scott Robert Ladd wrote:
Scott Robert Ladd [EMAIL PROTECTED] wrote:
May I be so bold as to suggest that -funsafe-math-optimizations be
reduced in scope to perform exactly what it's name implies:
transformations that may slightly alter the meanding of code. Then
Paul Brook [EMAIL PROTECTED] writes:
| On Thursday 26 May 2005 14:25, Scott Robert Ladd wrote:
| Scott Robert Ladd [EMAIL PROTECTED] wrote:
| May I be so bold as to suggest that -funsafe-math-optimizations be
| reduced in scope to perform exactly what it's name implies:
| transformations that
Paul Brook wrote:
I thought the x86 sin/cos intrinsics were unsafe. ie. they don't gave
accurate
results in all cases.
If memory serves, Intel's fsin (for example) has an error 1 ulp for
value flose to multiples of pi (2pi, for example).
Now, I'm not certain this is true for the K8 and
Let's consider the accuracy of sice and cosine. I've run tests as
follows, using a program provided at the end of this message.
On the Opteron, using GCC 4.0.0 release, the command lines produce these
outputs:
-lm -O3 -march=k8 -funsafe-math-optimizations -mfpmath=387
generates:
fsincos
Scott Robert Ladd writes:
The program used is below. I'm very open to suggestions about this
program, which is a subset of a larger accuracy benchmark I'm writing
(Subtilis).
Try this:
public class trial
{
static public void main (String[] argv)
{
Andrew Haley wrote:
Try this:
public class trial
{
static public void main (String[] argv)
{
System.out.println(Math.sin(Math.pow(2.0, 90.0)));
}
}
zapata:~ $ gcj trial.java --main=trial -ffast-math -O
zapata:~ $ ./a.out
1.2379400392853803E27
zapata:~ $ gcj trial.java
Andrew Haley wrote
zapata:~ $ gcj trial.java --main=trial -ffast-math -O
^^
Ok, maybe those people that are accusing the Free Software philosophy of
being akin to communisn are wrong, but it looks like revolutionaries are
lurking around, at least... ;) ;)
Paolo.
Scott Robert Ladd writes:
Andrew Haley wrote:
Try this:
public class trial
{
static public void main (String[] argv)
{
System.out.println(Math.sin(Math.pow(2.0, 90.0)));
}
}
zapata:~ $ gcj trial.java --main=trial -ffast-math -O
zapata:~ $ ./a.out
Richard Henderson wrote:
On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
static const double range = PI; // * 2.0;
static const double incr = PI / 100.0;
The trig insns fail with large numbers; an argument
reduction loop is required with their use.
Yes, but
Scott == Scott Robert Ladd [EMAIL PROTECTED] writes:
Scott Richard Henderson wrote:
On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
static const double range = PI; // * 2.0; static const double
incr = PI / 100.0;
The trig insns fail with large numbers; an
Paul Koning wrote:
Scott Yes, but within the defined mathematical ranges for sine and
Scott cosine -- [0, 2 * PI) -- the processor intrinsics are quite
Scott accurate.
Huh? Sine and consine are mathematically defined for all finite
inputs.
Defined, yes. However, I'm speaking as a
Original Message
From: Scott Robert Ladd
Sent: 26 May 2005 17:32
Paul Koning wrote:
Scott Yes, but within the defined mathematical ranges for sine and
Scott cosine -- [0, 2 * PI) -- the processor intrinsics are quite
Scott accurate.
Huh? Sine and consine are mathematically
Dave Korn wrote:
Identities such as
sin(x)^2 + cos(x)^2 === 1
are only valid when 0 = x = 2*PI
It's been a while since I studied math, but isn't that particular
identity is true for any x real or complex?
David Daney,
Dave Korn wrote:
It's difficult to tell from that quote, which lacks sufficient context,
but you *appear* at first glance to be conflating the fundamental
trignometric *functions* with the trignometric *identities* that are
generally built up from those functions. That is to say, you
Kevin == Kevin Handy [EMAIL PROTECTED] writes:
Kevin But, you are using a number in the range of 2^90, only have 64
Kevin bits for storing the floating point representation, and some
Kevin of that is needed for the exponent.
Fair enough, so with 64 bit floats you have no right to expect an
Yes, but within the defined mathematical ranges for sine and cosine --
[0, 2 * PI) -- the processor intrinsics are quite accurate.
If you were to look up a serious math book like AbramowitzStegun1965
you would see a definition like
sin z = ((exp(iz)-exp(-iz))/2i [4.3.1]
I'm pleased to announce that GCC 3.3.6 has been released.
This version is a minor release, fixing regressions in GCC 3.3.5
with respect to previous versions of GCC. It can be downloaded from
the FTP serves listed here
http://www.gnu.org/order/ftp.html
The list of
Original Message
From: David Daney
Sent: 26 May 2005 18:23
Dave Korn wrote:
Identities such as
sin(x)^2 + cos(x)^2 === 1
are only valid when 0 = x = 2*PI
It's been a while since I studied math, but isn't that particular
identity is true for any x real or
Morten Welinder wrote:
If you were to look up a serious math book like AbramowitzStegun1965
you would see a definition like
sin z = ((exp(iz)-exp(-iz))/2i [4.3.1]
Very true. However, the processor doesn't implement intrinsics for
complex functions -- well, maybe some
Scott == Scott Robert Ladd [EMAIL PROTECTED] writes:
Scott Dave Korn wrote:
It's difficult to tell from that quote, which lacks sufficient
context, but you *appear* at first glance to be conflating the
fundamental trignometric *functions* with the trignometric
*identities* that are
Original Message
From: Scott Robert Ladd
Sent: 26 May 2005 18:36
I am simply lobbying for the separation of hardware intrinsics from
-funsafe-math-optimizations.
Well, as long as they're under the control of a flag that also makes it
clear that they are *also* unsafe math
Paul Koning wrote:
I'm really puzzled by that comment, partly because the text book quote
you gave doesn't match any math I ever learned. Does knowing your
math translates to believing that trig functions should be applied
only to arguments in the range 0 to 2pi? If so, I must object.
I'll
After some off-line exchanges with Dave Korn, it seems to me that part
of the problem is that the documentation for
-funsafe-math-optimizations is so vague as to have no discernable
meaning.
For example, does the wording of the documentation convey the
limitation that one should only invoke math
On May 26, 2005, at 2:12 PM, Paul Koning wrote:
What does (b) mean? What if anything are its limitations? Is
returning 1.2e27 as the result for a sin() call authorized by (b)? I
would not have expected that, but I can't defend that expectation
based on a literal reading of the text...
b)
Original Message
From: Scott Robert Ladd
Sent: 26 May 2005 19:09
Dave Korn wrote:
Well, as long as they're under the control of a flag that also makes it
clear that they are *also* unsafe math optimisations, I wouldn't object.
But they are *not* unsafe for *all* applications.
Andrew Pinski wrote:
b) means that (-a)*(b-c) can be changed to a*(c-b) and other reassociation
opportunities.
This is precisely the sort of transformation that, in my opinion, should
be separate from the hardware intrinsics. I mentioned this specific case
earlier in the thread (I think; maybe
On Thu, 26 May 2005, Paul Koning wrote:
Kevin == Kevin Handy [EMAIL PROTECTED] writes:
Kevin But, you are using a number in the range of 2^90, only have 64
Kevin bits for storing the floating point representation, and some
Kevin of that is needed for the exponent.
Fair enough, so
On Thursday 26 May 2005 10:15, Vincent Lefevre wrote:
On 2005-05-25 19:27:21 +0200, Allan Sandfeld Jensen wrote:
Yes. I still don't understand why gcc doesn't do -ffast-math by
default like all other compilers.
No! And I really don't think that other compilers do that.
I can't speak of all
Allan Sandfeld Jensen wrote:
Basically any compiler that cares about benchmarks have it enabled by default.
Many of them however have multiple levels of relaxed floating point. The
lowest levels will try to be as accurate as possible, while the higher will
loosen the accuracy and just try
Scott Robert Ladd [EMAIL PROTECTED] writes:
| Richard Henderson wrote:
| On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
|
| static const double range = PI; // * 2.0;
| static const double incr = PI / 100.0;
|
|
| The trig insns fail with large numbers; an
Gabriel Dos Reis wrote:
Scott Robert Ladd [EMAIL PROTECTED] writes:
| I've never quite understood the necessity for performing trig operations
| on excessively large values, but perhaps my problem domain hasn't
| included such applications.
The world is flat; I never quite understood the
On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote:
I've never quite understood the necessity for performing trig operations
on excessively large values, but perhaps my problem domain hasn't
included such applications.
Whether you think it necessary or not, the ISO C functions
Scott Robert Ladd [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Scott Robert Ladd [EMAIL PROTECTED] writes:
| | I've never quite understood the necessity for performing trig operations
| | on excessively large values, but perhaps my problem domain hasn't
| | included such
Hello!
Fair enough, so with 64 bit floats you have no right to expect an
accurate answer for sin(2^90). However, you DO have a right to expect
an answer in the range [-1,+1] rather than the 1.2e+27 that Richard
quoted. I see no words in the description of
-funsafe-math-optimizations to lead
Uros == Uros Bizjak [EMAIL PROTECTED] writes:
Uros Hello!
Fair enough, so with 64 bit floats you have no right to expect an
accurate answer for sin(2^90). However, you DO have a right to
expect an answer in the range [-1,+1] rather than the 1.2e+27 that
Richard quoted. I see no words
Uros Bizjak [EMAIL PROTECTED] writes:
[...]
| Out of curiosity, where could sin(2^90) be needed? It looks rather
| big angle to me.
If it was and angle! Not everything that is an argument to sin or cos
is an angle. They are just functions! Suppose you're evaluating an
approximation of a
On Friday 27 May 2005 00:26, Gabriel Dos Reis wrote:
Uros Bizjak [EMAIL PROTECTED] writes:
[...]
| Out of curiosity, where could sin(2^90) be needed? It looks rather
| big angle to me.
If it was and angle! Not everything that is an argument to sin or cos
is an angle. They are just
Uros,
However, the argument to fsin can be reduced to an
acceptable range by using fmod builtin. Internally, this
builtin is implemented as a very tight loop that check for
insufficient reduction, and could reduce whatever finite
value one wishes.
Keep in mind that x87
Richard Henderson wrote:
On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote:
I've never quite understood the necessity for performing trig operations
on excessively large values, but perhaps my problem domain hasn't
included such applications.
Whether you think it necessary
Gabriel Dos Reis wrote:
Yeah, the problem with people who work only with angles is that they
tend to forget that sin (and friends) are defined as functions on
*numbers*, not just angles or whatever, and happen to appear in
approximations of functions as series (e.g. Fourier series) and
Scott,
For a wide variety of applications, the hardware intrinsics
provide both faster and more accurate results, when compared
to the library functions.
This is not true. Compare results on an x86 systems with those on an x86_64 or
ppc. As I said before, shortcuts were taken in x87
Scott Robert Ladd [EMAIL PROTECTED] writes:
| Richard Henderson wrote:
| On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote:
|
| I've never quite understood the necessity for performing trig operations
| on excessively large values, but perhaps my problem domain hasn't
|
Snapshot gcc-4.0-20050526 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050526/
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-20050526
You'll find
Scott Robert Ladd [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Yeah, the problem with people who work only with angles is that they
| tend to forget that sin (and friends) are defined as functions on
| *numbers*, not just angles or whatever, and happen to appear in
| approximations
Menezes, Evandro wrote:
This is not true. Compare results on an x86 systems with those on an
x86_64 or ppc. As I said before, shortcuts were taken in x87 that
sacrificed accuracy for the sake of speed initially and later of
compatibility.
It *is* true for the case where the argument is in
Scott,
This is not true. Compare results on an x86 systems with
those on an
x86_64 or ppc. As I said before, shortcuts were taken in x87 that
sacrificed accuracy for the sake of speed initially and later of
compatibility.
It *is* true for the case where the argument is in the
Gabriel Dos Reis wrote:
Scott Robert Ladd [EMAIL PROTECTED] writes:
| Then, as someone else said, why doesn't the compiler enforce -ansi
| and/or -pedantic by default?
Care submitting a ptach?
Would a strictly ansi default be accepted on principle? Given the
existing code base of
Menezes, Evandro wrote:
Besides, you're also comparing 80-bit calculations with 64-bit
calculations, not only the accuracy of sin and cos. Try using
-ffloat-store along with -mfpmath=387 and see yet another set of
results. At the end of the day, which one do you trust? I wouldn't
trust my
On 2005-05-23, at 08:15, Gabriel Dos Reis wrote:
Sixth, there is a real mess about name spaces. It is true that
every C programmers knows the rule saying tags inhabit different name
space than variable of functions. However, all the C coding standards
I've read so far usually suggest
On 2005-05-24, at 09:09, Zack Weinberg wrote:
Gabriel Dos Reis [EMAIL PROTECTED] writes:
[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument. Also,
rearranging paragraphs a bit so as not to have to repeat myself]
On 2005-05-24, at 06:00, Andrew Pinski wrote:
On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike. Patches to add 'static' to such functions (AND
On 2005-05-24, at 18:06, Diego Novillo wrote:
On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
So, if various components maintainers (e.g. C and C++, middle-end,
ports, etc.) are willing to help quickly reviewing patches we can
have this done for this week (assuming
On 2005-05-25, at 08:06, Christoph Hellwig wrote:
On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
I'm not sure what the above may imply for your ongoing
discussion, tough...
Well, if I were running the show, the 'clock' would only start
running
when it was consensus
On 2005-05-26, at 21:34, Scott Robert Ladd wrote:
For many practical problems, the world can be considered flat. And
I do
plenty of spherical geometry (GPS navigation) without requiring the
sin
of 2**90. ;)
Yes right. I guess your second name is ignorance.
On 2005-05-27, at 00:00, Gabriel Dos Reis wrote:
Yeah, the problem with people who work only with angles is that they
tend to forget that sin (and friends) are defined as functions on
*numbers*,
The problem with people who work only with angles is that they are
without sin.
On 2005-05-26, at 22:39, Gabriel Dos Reis wrote:
Scott Robert Ladd [EMAIL PROTECTED] writes:
| Richard Henderson wrote:
| On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
|
| static const double range = PI; // * 2.0;
| static const double incr = PI / 100.0;
|
|
I did a checkin using ../ in one of the files and cvs screwed up.
The ChangeLog file came out ok, but, all the others were created
someplace else. I'm thinking those ,v files should just be rmed off
the server... but, would rather someone else do that. Thanks.
I was in
Mike Stump [EMAIL PROTECTED] writes:
I did a checkin using ../ in one of the files and cvs screwed up.
The ChangeLog file came out ok, but, all the others were created
someplace else. I'm thinking those ,v files should just be rmed off
the server... but, would rather someone else do that.
On May 26, 2005, at 8:47 PM, Ian Lance Taylor wrote:
I have removed these files from the server.
Much thanks.
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-26
06:08 ---
Some useful tips can be found here:
http://gcc.gnu.org/ml/java-patches/2005-q2/msg00558.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9861
--- Additional Comments From roger at eyesopen dot com 2005-05-26 06:11
---
This should now be fixed on the gcc-3_4-branch (and the same patch has been
applied to mainline to prevent this ever causing problems in future).
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-26
06:26 ---
Subject: Bug 17283
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-26 06:26:18
Modified files:
libgfortran: ChangeLog
This does not appear to be the usual problem where an ambiguous name is
reported
as undefined. The protected data member is unambiguous after being publicly
inherited, but is still reported as undefined.
--
Summary: Fails to find inherited protected member
Product: gcc
--- Additional Comments From igodard at pacbell dot net 2005-05-26 06:27
---
Created an attachment (id=8969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8969action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21763
--- Additional Comments From igodard at pacbell dot net 2005-05-26 06:28
---
Created an attachment (id=8970)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8970action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21763
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-26
06:40 ---
Subject: Bug 17283
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-26 06:40:42
Modified files:
libgfortran:
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-05-26
06:50 ---
This should fix it:
*** rs6000.md.~1.367.~ Sat May 14 22:06:45 2005
--- rs6000.md Wed May 25 23:48:56 2005
***
*** 1672,1678
(const_int 0)))
(set
As per the commentary in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664.
What is desired is to add the visibility attributes to namespace scope, in
addition to class scope.
So, things like:
namespace std __attribute__ ((visibility (default) ));
{
class foo { ... };
}
when compiled with
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-26
07:31 ---
I have now submitted a patch for fixing this bug:
http://gcc.gnu.org/ml/java-patches/2005-q2/msg00570.html
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-26
08:07 ---
Subject: Bug 21716
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-26 08:07:36
Modified files:
gcc: ChangeLog reg-stack.c
Log message:
--
Summary: -free-vrp is undocumented.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-26
08:31 ---
Confirmed. Parse tree output for slightly modified testcase:
$ cat a.f
character*2 a
character*4 b
character*4 c
parameter(a=12)
parameter (b = a)
c = a
write
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-26
08:55 ---
Subject: Bug 21716
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-26 08:55:07
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-26
09:05 ---
Subject: Bug 21716
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-26 09:05:05
Modified files:
gcc:
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-26
09:41 ---
A scalar mask is invalid for unpack, so the error message
is correct.
The memory allocation issue has been fixed for 4.0 and mainline.
Closing this bug.
--
What|Removed
--- Additional Comments From giovannibajo at libero dot it 2005-05-26
10:18 ---
Please, explicitally specify how you would like this to work with nested
namespaces.
Also, whoever implements this should also make sure it works correctly with
namespace:
namespace N
--- Additional Comments From dorit at il dot ibm dot com 2005-05-26 12:02
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02477.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-26
12:05 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
||patches/2005-
|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-26
12:13 ---
Confirmed.
--
What|Removed |Added
CC||pinskia
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-26
12:18 ---
Confirmed, very much related to PR 21614. Changing the undefined class to a
defined class makes the
code work.
--
What|Removed |Added
--
What|Removed |Added
Attachment #8969|application/octet-stream|text/plain
mime type||
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-26
12:23 ---
Please read the changes page for 3.4.0 about dependent names.
--
What|Removed |Added
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From ams at gnu dot org 2005-05-26 12:59 ---
(In reply to comment #3)
Like most POSIX limits PATH_MAX may not be defined if the actual limit is not
fixed.
Correct, and GNU doesn't have such a limit for the length of filenames, the
number of arguments
/cygdrive/c/sf/gcc-build/./gcc/xgcc -B/cygdrive/c/sf/gcc-build/./gcc/
-B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include
-c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc/libiberty/../include
--- Additional Comments From dims at yahoo dot com 2005-05-26 13:54 ---
Environment: latest cygwin on winxp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
--
What|Removed |Added
Component|bootstrap |middle-end
GCC target triplet||i686-pc-cygwin
Keywords|
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
--
What|Removed |Added
BugsThisDependsOn||21767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
if-convert sometimes moves instructions from after to before a conditional
jump. Some REG_EQUAL are no longer true after this transformation, yet
they are not removed.
--
Summary: if-convert leaves invalid REG_EQUAL notes
Product: gcc
Version: 3.4.3
--- Additional Comments From pluto at agmk dot net 2005-05-26 14:40 ---
(In reply to comment #4)
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html
FYI, gcc 3.4 from RH does include this pragma.
this patch ices gcc-4.1-20050522 bootstrap.
1 - 100 of 178 matches
Mail list logo
