--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
In following definition of _cpp_save_parameter of v3.4.6 (It also can be found
in v4.3.0)
1238 bool
1239 _cpp_save_parameter (cpp_reader *pfile, cpp_macro *macro, cpp_hashnode
*node)
1240 {
...
1255 node->flags |= NODE_MACRO_ARG;
1256 len = macro->paramc * sizeof (union _cpp_hashnode_va
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 07:37 ---
Related to PR 37737.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfi
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 07:31 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #21 from pinskia at gcc dot gnu dot org 2008-12-29 07:30
---
local-alloc will likely be removed for 4.4, do you know if IRA has the same
issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-29 07:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-29 07:23 ---
*** Bug 38605 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 07:23 ---
*** This bug has been marked as a duplicate of 31827 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 07:12 ---
Is this still true in newer GCC releases? Also this was removed in 4.3 and
above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-12-29 06:59 ---
This was most likely fixed for 4.4 by the removal of DECL_INLINE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-29 06:56 ---
A patch was posted to http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00850.html
Maybe some other cgraph changes in 4.4 fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29202
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 06:53 ---
*** This bug has been marked as a duplicate of 37093 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-29 06:53 ---
*** Bug 35268 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 06:51 ---
Fixed in 4.3.0 at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-29 06:50 ---
I think this is a dup of bug 35294.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 06:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 06:41 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35302
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-29 06:36 ---
Note the 4.2 branch is closing soon.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-12-29 06:34
---
Isn't this fixed now? There was a new newlib release last week:
http://sourceware.org/ml/newlib/2008/msg00754.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 06:30 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 06:25 ---
This was truely fixed by the patches to fix PR 18754/34223. We now iterate
after unrolling.
(tree_unroll_loops_completely): Re-structure to iterate over
innermost loops with intermediate CFG cleanup
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 06:15 ---
Hmm:
MEM[symbol: b, index: ivtmp.27, step: 4, offset: 4294967292]
Why do we produce a step and an offset when they cancel?
If we change the store to a[i+1] to be unconditional, predictive commoning does
the correct
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33738
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 04:29 ---
Can you give the output of:
g++ -maix64 a.cpp -v
Also can you try a newer version of GCC, like 4.3?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 04:21 ---
libgcj is known to work on 11.11, see PR 37264.
Does this happen now?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-29 04:18
---
(In reply to comment #9)
> Can we fix this at expansion time? Thus, move the VIEW_CONVERT_EXPR from the
> rhs to the lhs? This might be a target dependent optimization.
Yes but then we have to fix fwprop to forw
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 04:13 ---
Confirmed, a regression from at least 3.3 which gave:
t.cc: In constructor `C::C(B&)':
t.cc:14: error: `A' is an inaccessible base of `B'
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-29 04:07 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 04:06 ---
You just want:
struct A::B
{
B()
{
cout << __PRETTY_FUNCTION__ << endl;
}
};
Since you already specialized A, you don't need to specialize
A::B.
--
pinskia at gcc dot gn
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-29 03:54 ---
Confirmed, -march=i386 -mtune=i686 is needed to confirm the bug in general.
GCC is producing a "conditional move" for the code even though it is invalid to
produce such a thing.
--
pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 03:51 ---
In fact it is the same as PR 35764.
*** This bug has been marked as a duplicate of 35764 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 03:51 ---
*** Bug 35762 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35764
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 03:50 ---
>The output is not correct, it unconditionally returns the value from g_13.
No, it does not.
You missed:
setle %al
movzbl %al, %eax
subl$1, %eax
Now it unconditionally reads from g_
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 03:46 ---
Actually this comes down to optimizing:
int f(int a)
{
if (a)
return a +4;
return 0;
}
Into the sequence which is mentioned, that is using subtract with borrow and
such.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 03:44 ---
I get a branchless form with -march=i686 -O2:
testl %edx, %edx
leal4(%edx), %ecx
cmovne %ecx, %eax
Also in your case if d is NULL, then b has to be NULL. Nothing to do with
anything
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 03:38 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-12-29 03:34
---
*** This bug has been marked as a duplicate of 38153 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 03:34 ---
This works on the trunk now. Closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-12-29 03:34
---
*** Bug 38154 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38153
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-12-29 03:22
---
*** Bug 36116 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-12-29 03:22
---
Instead of a segfault I see a crash in fold_binary, at fold-const.c:9278
Reduced testcase that crashes already with "-O -ftree-loop-distribution":
==
extern void *malloc (_
--- Comment #21 from lucier at math dot purdue dot edu 2008-12-29 03:06
---
Thanks for your comments.
So, to get back to basics, how do I build a compiler on darwin that has a
64-bit gcc/cc1/etc., but compiles to 32-bit binaries by default?
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-12-29 02:42
---
>/Users/lucier/programs/gcc/objdirs/mainline/./gcc/as: line 76: exec: : not
found
That means as was not found in the first place.
>--target=powerpc-apple-darwin9.6.0
Since build == host != target, you are build
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 02:35 ---
*** This bug has been marked as a duplicate of 34999 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #21 from pinskia at gcc dot gnu dot org 2008-12-29 02:35
---
*** Bug 37058 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 02:38 ---
IIRC libgcc_eh.a is only needed for shared targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35857
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
GCC ta
--- Comment #9 from reichelt at gcc dot gnu dot org 2008-12-29 02:32
---
*** Bug 33981 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33361
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-12-29 02:32
---
With a little tweaking the testcase compiles under GCC 4.3.x or even GCC 4.4.0.
It compiles fine without crash using "-O -fopenmp" and "-O3 -fopenmp".
So the bug is really fixed in GCC 4.3.0 and up.
This looks rea
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-29 02:31 ---
volatile here means noreturn.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-29 02:28 ---
If you are using the specific intrinsics, you need to use a literal n here.
Try:
template < typename T> inline
T rot_veci( T v, const int n ) __atrribute__((always_inline))
template < typename T> inline
T rot_veci
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-29 02:18 ---
Subject: Bug 36610
Author: pinskia
Date: Mon Dec 29 02:16:45 2008
New Revision: 142945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142945
Log:
2008-12-28 Andrew Pinski
PR libobjc/36610
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-29 01:50 ---
You would think that but I think no C++ compiler does that optimization at all.
They might get rid of empty final's but not throw catches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38658
--- Comment #19 from lucier at math dot purdue dot edu 2008-12-29 01:30
---
Maybe you could offer a few more details; I just tried
% cat ../../mainline/build-and-check-gcc-64-32
#!/bin/tcsh
/bin/rm -rf *; ../../mainline/configure CC='/usr/bin/gcc-4.0 -mcpu=970 -m64'
--build=powerpc64-a
--- Comment #4 from bkorb at gnu dot org 2008-12-29 01:24 ---
If GNU Make is only required for the GCC build, then the configure script
for the gcc piece is the only place where such code would be needed.
Anyway, my basic point is that it would be very helpful to not force folks
to find
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gmail dot com 2008-12-29 00:49 ---
Subject: Re: toplevel configure script does not test for GNU Make
On Sun, Dec 28, 2008 at 6:01 PM, bkorb at gnu dot org
wrote:
>
>
> --- Comment #2 from bkorb at gnu dot org 2008-12-28 23:01 ---
> It would seem
I would expect a C++ compiler to generate optimal and equivalently efficient
code for both of the functions below. gcc 4.3 generates much worse code for
bar() than for foo() even at -O3.
int foo () { return 1; }
int bar () { try { throw 1; } catch (int i) { return i; } }
--
Summary:
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-12-29 00:16
---
Yes, it's indeed a duplicate.
The bug has been fixed for GCC 4.4.0.
*** This bug has been marked as a duplicate of 36460 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-12-29 00:16
---
*** Bug 35497 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-12-29 00:04
---
Even complete garbage like the following is accepted:
=
template struct A;
template<> struct A<+/-.../+/-.../+/-.../+> {};
=
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-12-28 23:43
---
Simpler testcase:
===
struct A
{
template A(T);
};
struct B
{
void foo();
};
A a = B().*(&B::foo);
===
This is invalid use of a bound non-static membe
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-12-28 23:08
---
Confirmed.
Btw, the following is accepted:
template struct X {};
X 2))> x;
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
$cat test3.f90
MODULE TEST3
PRIVATE
CHARACTER(LEN=80) :: TESTCHAR
INTEGER :: TESTINT
REAL :: TESTREAL
COMMON /TESTCOMMON1/ TESTCHAR
COMMON /TESTCOMMON2/ TESTINT
COMMON /TESTCOMMON3/ TESTREAL
END MODULE TEST3
$cat test2.f90
MODULE TEST2
USE TEST3
PRIVATE
CHARACTER(LEN=80)
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-12-28 23:00
---
Might be related to PR35828.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bkorb at gnu dot org 2008-12-28 23:01 ---
It would seem to me that requiring one to read through installation
documentation is unreasonable when a trivial change to the configure script can
tell the hapless builder what is wrong. You are correct in that it is
documen
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-12-28 22:53
---
Removing error-recovery because the first testcase crashes without previous
error message.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-12-28 22:39
---
Confirmed.
The behavior changed between 2008-10-18 and 2008-11-02.
Looking at the patches in the relevant timeframe,
the following patch might be the cause:
2008-10-20 Manuel López-Ibáñez
PR c++/37
--- Comment #65 from reichelt at gcc dot gnu dot org 2008-12-28 22:16
---
Janis, Manuel, is this fixed now?
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from kargl at gcc dot gnu dot org 2008-12-28 22:14 ---
(In reply to comment #12)
> Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
>
> > See libm on FreeBSD.
> >
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_roundf.c
>
> So, the ceilf imp
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-12-28 22:11
---
Confirmed. Reduced testcase for comment #1:
=
template struct A;
template class = A> void foo();
void bar()
{
foo();
}
==
--- Comment #4 from amylaar at gcc dot gnu dot org 2008-12-28 22:07 ---
(In reply to comment #3)
> Is this still an issue with current trunk, or
> with 4.3?
I had a look at the current trunk and the diffs leading up to it, and I can
confirm that the issue has not been fixed.
However, I
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-12-28 21:55
---
Even shorter testcase:
=
template struct A;
template struct B;
template struct B, A >
{
static int i;
};
B, A > b1;
B, A<> > b2;
==
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-28
21:48 ---
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
> See libm on FreeBSD.
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_roundf.c
So, the ceilf implementation was changed to a
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-12-28 21:38 ---
THis is not a bug as explained, the compiler needs to decide what kind of
method needs to be called including the return value. So the compiler is guess
it returns an int instead of the float one.
--
pinskia at
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-12-28 21:34
---
You have to set CC to begin with if you are bootstrapping.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
A broken diagnostic is issued for the following code snippet since GCC 4.3.0:
template int foo();
template void bar(F f)
{
f((foo<0>()=0)...);
}
bug.cc: In function 'void bar(F)':
bug.cc:5: error: expansion patte
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-28 21:33
---
I think the issue was info/.texi files were not generated in that package.
Does this work in a newer release of GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-28 21:31 ---
Well the requirement to use GNU make is documented.
http://gcc.gnu.org/install/prerequisites.html
GNU make version 3.80 (or later)
You must have GNU make installed to build GCC.
So I am going to close this as inv
A broken diagnostic is issued for the following code snippet since GCC 4.3.0:
==
__decltype(0r)* p = 1;
==
bug.cc:1: error: invalid conversion from 'int' to '#'fixed_point_type' not
supported by dump_type_prefix#*#'fixed_point_type' not
supp
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-28 21:30 ---
SHELL is set by make which is always set to a semi borne compatible shell so
the configuration of make is incorrect.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-12-28 21:28 ---
You should disable libmudflap and libssp (in newer gcc's) if you want to build
a cross compiler to start stage1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from domob at gcc dot gnu dot org 2008-12-28 21:27 ---
Created an attachment (id=16998)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16998&action=view)
Number parsing routines
Sorry for the spam, but this is the parser-code for numbers I promised; it's
just a part
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 21:24 ---
You can rerun fixincludes after install glibc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-28 21:25 ---
Is this still true?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28561
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-28 21:23 ---
libjava is not designed to run in single threads mode at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-28 21:22 ---
make install should not be rebuilding anything.
Does this work for you with 4.3.x?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-28 21:13 ---
Suspend as m68k-*-coff is now obsolete will most likely be removed soon.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-28 21:19 ---
g77 has since been removed and the way bootstrap works now in 4.2 and above is
different. Does this work now in 4.3.x and above?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 21:17 ---
This part of the Makefile.in has since been removed from 4.3.x and above. Do
you know if this issue still exists?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-28 21:15 ---
mklibgcc.in has since been removed in 4.3.x, is this still an issue in 4.3?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-28 21:13 ---
Confirm to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|U
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-28 21:02
---
Created an attachment (id=16997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16997&action=view)
Patch that splits formatted read and write
This is the patch mentioned in comment 0. This patch touches so
--- Comment #11 from kargl at gcc dot gnu dot org 2008-12-28 21:02 ---
(In reply to comment #9)
>
> I think the tests in roundf need to be revised to minimize rounding
> issues. Patch attached. This fixes the test on hppa2.0w-hp-hpux11.11.
>
See libm on FreeBSD.
http://www.freebsd.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-28 20:55
---
Daniel, it can't hurt to look.
Also, I have a format data hashing/caching patch in the works. This avoids
re-parsing format strings if they have already been parsed once such as in a
loop containing I/O statemen
1 - 100 of 136 matches
Mail list logo
