Hi Ondřej,
On Sat, Apr 27, 2013 at 06:11:06PM +0200, Ondřej Surý wrote:
> Thanks for the breakdown.
>
> >>
> >> I would expect consistent results, even consistent *bad* results would be
> >> ok.
> >
> > Nope, FMA can change the rules of the game in subtle ways. An easy way
> > to check f
Hi Gabriel,
On Sat, Apr 27, 2013 at 5:14 PM, Gabriel Paubert wrote:
> On Fri, Apr 26, 2013 at 01:04:30PM +0200, Ondřej Surý wrote:
>> On Fri, Apr 26, 2013 at 12:43 PM, Bastian Blank wrote:
>> > On Fri, Apr 26, 2013 at 12:27:53PM +0200, Ondřej Surý wrote:
>> >> This code from libgd2:src/gd.c:clip
On Fri, Apr 26, 2013 at 01:04:30PM +0200, Ondřej Surý wrote:
> On Fri, Apr 26, 2013 at 12:43 PM, Bastian Blank wrote:
> > On Fri, Apr 26, 2013 at 12:27:53PM +0200, Ondřej Surý wrote:
> >> This code from libgd2:src/gd.c:clip_1d:
> >> *y1 -= m * (*x1 - mindim);
> >> where
> >> m = (double) -0.05
JFTR I have already fixed the code upstream.
Feel free to close this bug or better mark it upstream+wontfix, so others not
so versed in upstream bugzilla can find it.
Ondřej Surý
On 26. 4. 2013, at 16:27, Matthias Klose wrote:
> Am 26.04.2013 14:37, schrieb Ondřej Surý:
>> I am lowering the s
Am 26.04.2013 14:37, schrieb Ondřej Surý:
> I am lowering the severity and moving the discussion to gcc bugzilla, ok?
no. this will be resolved upstream as a dup for PR323. please fix your code.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
Processing commands for cont...@bugs.debian.org:
> forwarded 706207 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57080
Bug #706207 [gcc-4.6,gcc-4.7] gcc-4.6, gcc-4.7: invalid optimization when doing
double -> int math and conversion (on big endian archs(?))
Set Bug forwarded-to-address to
'http:/
forwarded 706207 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57080
severity 706207 minor
thank you
On Fri, Apr 26, 2013 at 2:09 PM, Bastian Blank wrote:
> On Fri, Apr 26, 2013 at 01:04:30PM +0200, Ondřej Surý wrote:
>> I don't object to this, but somehow I fail to grasp the idea that the
>> resul
On Fri, Apr 26, 2013 at 01:04:30PM +0200, Ondřej Surý wrote:
> I don't object to this, but somehow I fail to grasp the idea that the
> result depends on architecture and optimization level.
There are negative number involved. The result is somewhere within
5.0+-$epsilon depending on order of calcu
On Fri, Apr 26, 2013 at 12:43 PM, Bastian Blank wrote:
> On Fri, Apr 26, 2013 at 12:27:53PM +0200, Ondřej Surý wrote:
>> This code from libgd2:src/gd.c:clip_1d:
>> *y1 -= m * (*x1 - mindim);
>> where
>> m = (double) -0.05
>> *x1 = -200
>> mindim = 0
>> *y1 = 15
>> results in *y1 = 4,
On Fri, Apr 26, 2013 at 12:27:53PM +0200, Ondřej Surý wrote:
> This code from libgd2:src/gd.c:clip_1d:
> *y1 -= m * (*x1 - mindim);
> where
> m = (double) -0.05
> *x1 = -200
> mindim = 0
> *y1 = 15
> results in *y1 = 4, which is incorrect value, since it should be 5.
Nope. The result
Package: gcc-4.6,gcc-4.7
Version: 4.6.3-15
Severity: normal
Dear Maintainer,
this bug manifest itself on ia64, powerpc and s390x where gcc-4.6 is
used and the optmized code (-O2) fails to produce correct math
results.
This code from libgd2:src/gd.c:clip_1d:
*y1 -= m * (*x1 - mindim);
where
11 matches
Mail list logo
