--- Comment #27 from manu at gcc dot gnu dot org 2010-02-24 13:10 ---
It should be FIXED for GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from manu at gcc dot gnu dot org 2010-02-24 13:09 ---
Subject: Bug 43128
Author: manu
Date: Wed Feb 24 13:09:37 2010
New Revision: 157040
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157040
Log:
2010-02-24 Manuel López-Ibáñez
PR c/43128
*
--- Comment #25 from manu at gcc dot gnu dot org 2010-02-24 10:39 ---
PATCH: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00969.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
--- Comment #24 from manu at gcc dot gnu dot org 2010-02-23 17:33 ---
OK, I get it. Thanks for the explanation. Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
--- Comment #23 from joseph at codesourcery dot com 2010-02-23 16:38
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Tue, 23 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #21 from manu at gcc dot gnu dot org 2010-02-23 10:23 ---
> (In r
--- Comment #22 from joseph at codesourcery dot com 2010-02-23 16:32
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Tue, 23 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #20 from manu at gcc dot gnu dot org 2010-02-23 08:39 ---
> (In r
--- Comment #21 from manu at gcc dot gnu dot org 2010-02-23 10:23 ---
(In reply to comment #19)
>
> The present logic is: convert (with convert_and_check) both operands to a
> common type, which may have excess precision; then, later, after producing
> the tree for the result of the o
--- Comment #20 from manu at gcc dot gnu dot org 2010-02-23 08:39 ---
(In reply to comment #19)
>
> The proposed logic is the same, *except* that the conversion to a common
> type goes via the semantic type, *if* there is excess precision involved
> *and* the operand being converted h
--- Comment #19 from joseph at codesourcery dot com 2010-02-23 00:29
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Mon, 22 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #18 from manu at gcc dot gnu dot org 2010-02-22 23:56 ---
> (In r
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org
|dot org
--- Comment #18 from manu at gcc dot gnu dot org 2010-02-22 23:56 ---
(In reply to comment #17)
> suggest having a c_ep_convert_and_check or similar function that handles
> excess precision: it would take the result type, the semantic result type
> (the type that gets used eventually t
--- Comment #17 from joseph at codesourcery dot com 2010-02-21 18:32
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 ---
> (In r
--- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 ---
(In reply to comment #15)
>
> With the intended semantics, we should warn; there would be an actual
> conversion from integer to float there, that could change the value.
Great. Any hints where could be the problem
--- Comment #15 from joseph at codesourcery dot com 2010-02-21 18:15
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote:
> Sorry I do not understand completely your answer. Shouldn't we warn at all? If
> the s
--- Comment #14 from hjl dot tools at gmail dot com 2010-02-21 18:00
---
That is true that the previous release didn't have proper excess
precision semantics. But from the user perspective, the previous
release handles
--
float f5(float x, int y)
{
return x * y;
}
--
correctly with
--- Comment #13 from manu at gcc dot gnu dot org 2010-02-21 17:57 ---
(In reply to comment #12)
> Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
> work
Sorry I do not understand completely your answer. Shouldn't we warn at all? If
the semantics were implemented as intend
--- Comment #12 from joseph at codesourcery dot com 2010-02-21 17:43
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
There is a technical bug here, in that the semantics I intended to
implement and said I was implementing were that implicit conversions from
in
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-21 17:25 ---
I may have miscompared the bootstrap results to miss this because I do test
-m32.
Yes, the excess precision stuff changes the common type to long double in
build_binary_op in C and -m32 (but not in C++!).
Joseph, is
--- Comment #10 from hjl dot tools at gmail dot com 2010-02-21 16:47
---
[...@gnu-6 gcc]$ cat /tmp/x.i
float f5(float x, int y)
{
return x * y;
}
[...@gnu-6 gcc]$ gcc -S /tmp/x.i -Wconversion -m32 -std=c99
/tmp/x.i: In function f5:
/tmp/x.i:3: warning: conversion to float from in
--- Comment #9 from hjl dot tools at gmail dot com 2010-02-21 16:46 ---
On Linux/ia32, -std=c99 changes silently float to long double
and we don't get a warning. It is a regression from gcc 4.4.
--
hjl dot tools at gmail dot com changed:
What|Removed
20 matches
Mail list logo
