--- Comment #2 from jakub at gcc dot gnu dot org 2006-01-04 08:05 ---
Subject: Bug 25562
Author: jakub
Date: Wed Jan 4 08:05:29 2006
New Revision: 109315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109315
Log:
PR debug/25562
* function.c (instantiate_expr): N
--- Comment #4 from jakub at gcc dot gnu dot org 2006-01-04 08:07 ---
Subject: Bug 25559
Author: jakub
Date: Wed Jan 4 08:07:09 2006
New Revision: 109316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109316
Log:
PR c/25559
* c-common.c (handle_vector_size_attri
Conversion from 128-bit long double to float goes via double. This means the
conversions suffers from double rounding, and incorrect results may be
calculated for long double values near the midpoint of two adjacent float
values.
For example, f and g should have different values in the following.
--- Comment #2 from jakub at gcc dot gnu dot org 2006-01-04 08:15 ---
Subject: Bug 25554
Author: jakub
Date: Wed Jan 4 08:15:06 2006
New Revision: 109317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109317
Log:
PR target/25554
* config/i386/i386.md (testqi_ext
The following testcase works on PPC with gcc-3.4, but fails with >=4.0.
__extension__ typedef unsigned long long guint64;
typedef int gint;
typedef gint gboolean;
typedef struct
{
guint64 rte;
} mainwindow;
mainwindow *mainw;
static int bg_gen_to_start;
gboolean weed_playback_gen_start (void
--- Comment #4 from bonzini at gnu dot org 2006-01-04 08:50 ---
H.J., can we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
--- Comment #5 from bonzini at gnu dot org 2006-01-04 08:57 ---
Janis, can you confirm this is fixed on 4.0?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-01-04 09:14 ---
Subject: Bug 25562
Author: jakub
Date: Wed Jan 4 09:13:56 2006
New Revision: 109319
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109319
Log:
PR debug/25562
* function.c (instantiate_expr): N
The following is rejected now as of a change between r109062 and r109079
with "error: invalid declarator" on the 2nd last line.
template
struct ScalarCode
{
ScalarCode(const T&);
template
void operator()(const A&, const B&);
};
template
struct CflFunctor
{
CflFunctor(bool omrot, bool vis_f)
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-01-04 09:15
---
*** This bug has been marked as a duplicate of 23541 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-01-04 09:15
---
*** Bug 25602 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-01-04 09:16
---
*** This bug has been marked as a duplicate of 23541 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-01-04 09:16
---
*** Bug 25200 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from jakub at gcc dot gnu dot org 2006-01-04 09:17 ---
Subject: Bug 25554
Author: jakub
Date: Wed Jan 4 09:17:16 2006
New Revision: 109321
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109321
Log:
PR target/25554
* config/i386/i386.md (testqi_ext
--- Comment #17 from philb at filmlight dot ltd dot uk 2006-01-04 09:17
---
It's live in the 4.0.2 installed by a Fedora Core 4 yum update right now (4.0.2
20051125 (Red Hat 4.0.2-8)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25364
--- Comment #5 from jakub at gcc dot gnu dot org 2006-01-04 09:16 ---
Subject: Bug 25559
Author: jakub
Date: Wed Jan 4 09:16:09 2006
New Revision: 109320
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109320
Log:
PR c/25559
* c-common.c (handle_vector_size_attri
--- Comment #3 from halcy0n at gentoo dot org 2006-01-04 09:23 ---
I'm seeing the same 4.0 regression on mainline as well.
--
halcy0n at gentoo dot org changed:
What|Removed |Added
---
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-01-04 09:37
---
Changing this to a more descriptive title.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-01-04 09:56
---
OK, all this mess comes from the following lines in /usr/include/locale.h:
#if (__STDC__ - 0 == 0 && \
!defined(_XOPEN_SOURCE) && !defined(_POSIX_C_SOURCE)) || \
defined(__EXTENSIONS__)
#include
> For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
> be sufficient to use a record containing a
> System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an
> alignement clause (I don't know if C or GNU C allows to retrieve the alignment
> of a struc
--- Comment #12 from charlet at adacore dot com 2006-01-04 09:58 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
> For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
> be sufficient to use a record containing
gcj -v:
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/../../../libgcj.spec
rename spec lib to liborig
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/
I'm trying to bootstrap GCC trunk on a "Linux 2.6.5-7.97-pseries64 #1 SMP Fri
Jul 2 14:21:59 UTC 2004 ppc64", and after configure by:
../gcc/configure --enable-languages=c,fortran --with-gmp=[...]
--enable-bootstrap
I get the following error:
/tmp/debug/ibin/./prev-gcc/xgcc -B/tmp/debug/ibin/./p
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.3 |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25637
This is a spin-off for the diagnostic issue from PR 25638:
=
struct A { ~A(); };
struct B
{
template friend A::~A();
};
=
For the above code we get the error message:
bug.cc:5: error: prototype for 'A::~A()' d
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-01-04 11:18
---
Thanks for the quick fixes, Mark!
The diagnostic issue is now PR 25666.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from reichelt at gcc dot gnu dot org 2006-01-04 11:43
---
> It's live in the 4.0.2 installed by a Fedora Core 4 yum update right now
> (4.0.2 20051125 (Red Hat 4.0.2-8)).
This is not the official FSF 4.0.2 release.
Redhat's 4.0.2-8 version contains some patches from the
--- Comment #13 from laurent at guerby dot net 2006-01-04 11:45 ---
(In reply to comment #12)
> > Arnaud, do you remember non opaque C types in s-osinte?
>
> I do not understand your question, could you clarify ?
"opaque" means that the Ada runtime never access an internal C record
com
--- Comment #6 from laurent at guerby dot net 2006-01-04 11:48 ---
(In reply to comment #5)
> There seems to be an optimisation issue. I rebuilt the runtime
> at -O0. The test passes when compiled at -O0 and -O1, but fails at
> -O2.
Hmm less likely to be fixed on 4.0 then. Could you t
> So my question is wether the record+storage array+align will work for all
> the C types in s-osinte* or is there an exception (ie a non opaque C type)?
Now I understand your question ;-)
The answer is no, this approach can't be applied blindly to all C types.
This approach could most likely be
--- Comment #14 from charlet at adacore dot com 2006-01-04 11:54 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
> So my question is wether the record+storage array+align will work for all
> the C types in s-osinte* or is there an except
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-01-04 12:07
---
Confirmed.
The call to operator() is not the problem, though, as the following shorter
testcase shows:
==
template struct A
{
A(int);
};
void foo()
{
A<0>(A<0>(0));
}
=
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-04 12:10 ---
Using
(ScalarCode >(CflFunctor<3>(omrot, vis_f)))(x, y);
was a workaround for me, so I thought it indeed was the issue... maybe there
are two issues actually.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-01-04 12:11 ---
Adding Mark in CC, because he caused this regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-01-04 12:14
---
Moving to "target" component. This bug is still present and it prevents
building gfortran on mips-sgi-irix6.5.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-01-04 12:16
---
With newer binutils (2.16.1), what happens is:
[EMAIL PROTECTED]:/tmp/debug/ibin/stage2-gcc$
/home/users/c/co/coudert/ppc64-linux/gfortran/gfortran_libs/ppc64-linux/bin/ld
--eh-frame-hdr -V -Qy -m elf64ppc -dynam
--- Comment #2 from bonzini at gnu dot org 2006-01-04 12:21 ---
Subject: Bug 24252
Author: bonzini
Date: Wed Jan 4 12:21:27 2006
New Revision: 109325
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109325
Log:
2006-01-04 Paolo Bonzini <[EMAIL PROTECTED]>
PR bootstrap/
--- Comment #2 from bonzini at gnu dot org 2006-01-04 12:21 ---
Patch committed, also fixes race conditions in bootstrap.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-01-04 12:21
---
> Using
>
> (ScalarCode >(CflFunctor<3>(omrot, vis_f)))(x, y);
>
> was a workaround for me, so I thought it indeed was the issue...
Adding parens in my example also makes the bug go away:
(A<0>(A<0>(0)));
We
--- Comment #6 from jakub at gcc dot gnu dot org 2006-01-04 12:27 ---
Subject: Bug 25559
Author: jakub
Date: Wed Jan 4 12:27:48 2006
New Revision: 109326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109326
Log:
PR c/25559
* c-common.c (handle_vector_size_attri
--- Comment #4 from jakub at gcc dot gnu dot org 2006-01-04 12:29 ---
Subject: Bug 25554
Author: jakub
Date: Wed Jan 4 12:29:14 2006
New Revision: 109327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109327
Log:
PR target/25554
* config/i386/i386.md (testqi_ext
--- Comment #11 from jakub at gcc dot gnu dot org 2006-01-04 12:32 ---
Subject: Bug 25294
Author: jakub
Date: Wed Jan 4 12:31:59 2006
New Revision: 109329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109329
Log:
PR c++/25294
* directives.c (do_pragma): If prag
--- Comment #4 from jakub at gcc dot gnu dot org 2006-01-04 12:33 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jakub at gcc dot gnu dot org 2006-01-04 12:33 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2006-01-04 12:34 ---
Fixed on 4.0/4.1 branches and trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jakub at gcc dot gnu dot org 2006-01-04 12:35 ---
Fixed even on 4.0 branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 12:40 ---
(In reply to comment #3)
> I'm seeing the same 4.0 regression on mainline as well.
Are you sure?
I don't see it on "4.2.0 20060103" unless it happens after that.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-04 12:45 ---
/usr/bin/ld: warning: powerpc:common architecture of input file
`../build-powerpc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is
incompatible with powerpc:common64 output
/usr/bin/ld: warning: powerpc:commo
Hi,
I am trying to install gcc-3.0.4 on my Itanium 2 linux machine,
these are the detailed os info:
Distribution: Red Hat Linux
Operating System: Linux
Distribution Version: Red Hat Linux Advanced Server release 2.1AS
(Derry)
Operating System Version: #
See http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01815.html. New libgcc2.c
code results in a couple of functions that are well over twice as slow.
--
Summary: libgcc2.c __floattisf code quality regression
Product: gcc
Version: 4.2.0
Status: UNCONFIRM
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 13:31 ---
Why are you trying to install 3.0.4? This version (3.0.x series) of GCC has
not been updated since 2002.
The only thing I can say is use a newer gcc instead of 3.0.x series GCC.
--
pinskia at gcc dot gnu dot org
subroutine foo (a)
real a(*)
call bar (a, LBOUND(a),2)
end subroutine foo
subroutine bar (b, i, j)
real b(i:j)
print *, i, j
print *, b(i:j)
end subroutine bar
real x(10)
x = 0.0
call foo (x)
end
???
This runs fine with other brand compilers but gfortran, patched or not, gives:
tobi.f90: In fu
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 13:34 ---
This actually might be related to PR 19777.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-04 13:35 ---
Actually assumed sized is not the full issue, see PR 18003.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from stener at univ dot trieste dot it 2006-01-04 13:44
---
(In reply to comment #1)
> Why are you trying to install 3.0.4? This version (3.0.x series) of GCC has
> not been updated since 2002.
> The only thing I can say is use a newer gcc instead of 3.0.x series GCC.
>
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-04 13:47 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Why are you trying to install 3.0.4? This version (3.0.x series) of GCC has
> > not been updated since 2002.
> > The only thing I can say is use a newer gcc in
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last r
--- Comment #17 from chris at bubblescope dot net 2006-01-04 13:53 ---
Just as a quick note, I've personally got code using the non-void return value
of generate_n (because I'm going along a list, and didn't want to have to
incremement n steps after filling the list, as that would cost).
--- Comment #18 from pcarlini at suse dot de 2006-01-04 13:58 ---
(In reply to comment #17)
>Not that
> I'm
> saying that means the code should stay, just at least one data point of
> someone
> who is using the current
I've configured with:
./configure --prefix=.../install --disable-nls --disable-libgcj
--enable-languages=c
Executed:
make all-gcc
Output:
...
make[2]: Leaving directory `.../intl'
cat: stage_last: No such file or directory
make: invalid option -- a
Usage: make [options] [target] ...
...
It app
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
Severity|major
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-04 14:10
---
(In reply to comment #9)
> At this moment, I guess the most important thing is that how to "make"
> is clarified and Paolo is willing to fix any problem that might
> result from his change. I'm doing what Daniel J
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-04 14:11
---
And there needs to be a way to do the old way of "make all" without having to
reconfiguring as it means rebuilding the support libraries which is too slow as
it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-01-04
14:25 ---
(In reply to comment #2)
> Actually assumed sized is not the full issue, see PR 18003.
You are right about this. Turn the declaration for a into an explicit
full-array, rather than assumed size.
I have
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-01-04
14:26 ---
(In reply to comment #2)
> Actually assumed sized is not the full issue, see PR 18003.
You are right about this. Turn the declaration for a into an explicit
full-array, rather than assumed size.
I have
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 14:37 ---
This works on the mainline as of today but failed with 4.2.0 20051219.
Confirmed. Though I should note this is really weird as DOM is messing up in
that version of GCC and we still have 1 << -1 which is not being f
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-04 14:50
---
Confirmed.
I get the warning with 4.2.0 20060104.
The preprocessed file triggers the warning also with the 4.1 branch.
It looks like Paolo's patch
2006-01-02 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 14:51 ---
*** This bug has been marked as a duplicate of 24958 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-04 14:51 ---
*** Bug 25660 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 14:51 ---
Reduced testcase:
nullify(i%e)
end program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24958
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 15:00 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-01-04 15:01
---
Looks like the culprit is the following part of Paolo's patch:
+ operator>>(int& __n)
+ {
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 118. basic_istream uses nonexistent num_get member functions.
--- Comment #14 from alex at milivojevic dot org 2006-01-04 15:03 ---
Benjamin:
You are not alone. I hit that bug too ;-)
Andrew:
I can reproduce the bug on my system. I haven't done anything fancy. And I
made sure only standard Solaris header files/libraries were visible while
boots
--- Comment #4 from pcarlini at suse dot de 2006-01-04 15:08 ---
(In reply to comment #3)
> We really don't set __n in all cases here.
And indeed we do *not* want to set __n in all cases: if for some reason the
extraction fails __n *must* be left untouched. Per the standard, there isn'
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-01-04 15:15
---
(In reply to comment #4)
> (In reply to comment #3)
>
> > We really don't set __n in all cases here.
>
> And indeed we do *not* want to set __n in all cases: if for some reason the
> extraction fails __n *m
--- Comment #6 from pcarlini at suse dot de 2006-01-04 15:17 ---
(In reply to comment #5)
> Hmm, if I understood correctly, this means that the variable is not set if the
> reading operation fails. That sounds plausible, and in this case the warning
> is
> perfectly OK and should not b
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 15:17 ---
Hmm, actually there is no rounding from TF to DF except for the fact that upper
potion of the TF mode is taken only.
I am thinking this testcase is invalid for 128bit IBM long double format.
IBM 128bit long double
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-04 15:20 ---
But the warning is obviously bogus as you can check the errors after a couple
readings and still be able to be catch error. This is in a way like
(void)read(a, xx, y) issue that was filed but in reality it was a gli
the code
int test_bit(unsigned long *words, int bit)
{
int wsize = (sizeof *words) * 8;
return (words[bit / wsize] & (1 << (bit % wsize))) != 0;
}
can compile to
xor %rax, %rax
bt %rsi, (%rdi)
setc %al
but instead compiles to a much longer sequence, using many more register
--- Comment #8 from pcarlini at suse dot de 2006-01-04 15:26 ---
(In reply to comment #7)
> But the warning is obviously bogus as you can check the errors after a couple
> readings and still be able to be catch error.
Well, I disagree: in my opinion, the compiler is correct that >> does
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 15:33 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bonzini at gnu dot org 2006-01-04 15:56 ---
Accepting this, but it is not a blocker as all-gcc is not even documented
anywhere.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-01-04 16:01
---
> Hmmm... If in dgettext.c I simply change the order the files are included,
> would that solve the problem? Or the fix is going to be more complex?
Both in dgettext.c and dngettext.c at a minimum as far as I
I'm configuring gcc with:
./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--bindir=/usr/bin --libdir=/usr/lib --libexecdir=/usr/lib --disable-shared
--disable-threads --enable-languages=c,c++ --enable-c99 --enable-long-long
--disable-nls --with-gnu-as --with-gnu-ld --wi
--- Comment #11 from law at gcc dot gnu dot org 2006-01-04 16:29 ---
Subject: Bug 24994
Author: law
Date: Wed Jan 4 16:29:32 2006
New Revision: 109335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109335
Log:
PR ada/24994
* tree-cfg.c (bsi_replace): Remove the
--- Comment #25 from paolo dot bonzini at lu dot unisi dot ch 2006-01-04
16:29 ---
Subject: Re: [4.1/4.2 Regression] Massive performance
regression for -ffast-math due to the recip tree pass
>For PowerPC, it is effective to use the instruction if
>there are multiple divides, such as
--- Comment #12 from law at redhat dot com 2006-01-04 16:36 ---
Fixed by attached patch. Would appreciate it if folks could verify ada is
bootstrapping again on PPC, HPUX and any other platform reported as failing.
--
law at redhat dot com changed:
What|Removed
--- Comment #5 from bonzini at gnu dot org 2006-01-04 16:38 ---
Patch posted. Andrew suggested another approach, but it is more complex and
I'm not going to work on it until more important issues are sorted out.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 16:41 ---
Resummaryizing to make clearer.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joseph at codesourcery dot com 2006-01-04 16:47 ---
Subject: Re: Wrong long double to float conversion
On Wed, 4 Jan 2006, pinskia at gcc dot gnu dot org wrote:
> Hmm, actually there is no rounding from TF to DF except for the fact that
> upper
> potion of the TF
--- Comment #8 from uttamp at us dot ibm dot com 2006-01-04 16:50 ---
This has been fixed with todays mainline tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
--- Comment #4 from uttamp at us dot ibm dot com 2006-01-04 16:50 ---
This has been fixed with todays mainline tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
--- Comment #9 from uttamp at us dot ibm dot com 2006-01-04 16:51 ---
*** This bug has been marked as a duplicate of 25578 ***
--
uttamp at us dot ibm dot com changed:
What|Removed |Added
--
--- Comment #9 from uttamp at us dot ibm dot com 2006-01-04 16:51 ---
*** Bug 25657 has been marked as a duplicate of this bug. ***
--
uttamp at us dot ibm dot com changed:
What|Removed |Added
---
--- Comment #5 from uttamp at us dot ibm dot com 2006-01-04 16:52 ---
*** This bug has been marked as a duplicate of 25578 ***
--
uttamp at us dot ibm dot com changed:
What|Removed |Added
--
--- Comment #10 from uttamp at us dot ibm dot com 2006-01-04 16:52 ---
*** Bug 25656 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-04 17:04 ---
http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/128bit_long_double_floating-point_datatype.htm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25661
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 17:13 ---
>From that page:
The 128-bit implementation differs from the IEEE standard for long double in
the following ways:
Supports only round-to-nearest mode. If the application changes the rounding
mode, results are undefi
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-04 18:48
---
Subject: Bug 24782
Author: mmitchel
Date: Wed Jan 4 18:48:38 2006
New Revision: 109342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109342
Log:
PR c++/24782
* parser.c (cp_parser_nested_
1 - 100 of 129 matches
Mail list logo
