When I build Pd, I get torubles that are probably realated with casting float to int.

[porres]

When I build PD from source on macOS (like the new 0.51-0 test1]), I get this error when I try had the value of 1+e16 for the line number in [text insert]. A related closed issue by thew way: #848

And here's the patch:
test-text.pd.zip

---

I'm just doing what I've been doing in order to compile Pd for a few years now, and I do:

./autogen.sh
./configure
make
make app

[umlaeute]

unable to reproduce in both the current update/0.50 (f5cdf67) and master ( e2ef815) branches.

EDIT: in Debian GNU/Linux

and no, i wouldn't call this version 0.51 already (nor 51)
since this repository holds a few thousand "versions" of Pd, i guess the proper way to reference a given version is by using the commitish, that is the tag name (e.g .0.50-2) if one exists (since we don't have a release right now, there's no tag yet), or the "sha" hash (e.g. e2ef815)

[porres]

yeah, I forgot to say, I'm on macOS

[umlaeute]

well yeah, your screenshot was giving you away :-)

are you sure that you are using the latest and greatest Pd (which commit?)? because there is code in place that is supposed to specifically handle the problem you are mentioning (4f9c85e)

[porres]

are you sure that you are using the latest and greatest Pd (which commit?)?

the last very one. I saw this happening in the branch from [knob], then I downloaded the latest source and saw it happening there too... but things work fine in 0.50-2

[Lucarda]

I can't reproduce on Windows.

master e2ef815 or update/0.50(20/3/2020).

[umlaeute]

the last very one.

so: which one?

[porres]

e2ef815

[porres]

Now that the 0.51-0test is out, I do not see this issue anymore, it seems this is related to the other issue that I was having with one of my externals - see #848

So, the problem seems to be that I'm compiling Pd wrong... I will ask on the pd list what I might be doing wrong

thanks

[Spacechild1]

-2147483647 is a typical result of signed integer overflow being undefined behavior. BUT the code of [text insert] has the following line

pure-data/src/x_text.c

Line 1018 in 15761e5

lineno = (x->x_f1 > (double)0x7fffffff ? 0x7fffffff : x->x_f1);

which is supposed to prevent the potential overflow issue... TBH, I have to no idea what's going on... Do you get the same result for [text set]?

[porres]

Ok, I edited my 1st comment and title, so all comments prior to yours can be deleted.

Do you get the same result for [text set]?

Not sure what kind of test you wanted, but this works fine... what I get is that floats are added in the order I send float values (I'm assuming this is expected).

[claudeha]

x_f1 is float, 0x7fffffff is not representable in float, so the float result of ?: is already out of range, perhaps. I see warnings when compiling, not able to check right now...

[Spacechild1]

x_f1 is float, 0x7fffffff

it's not exactly representable as a float. Floats can certainly be larger than 0x7fffffff. Also note that we cast 0x7fffffff to a double, so x_f1 should be widened appropriately for the comparison.

[Spacechild1]

@porres I need you to compare the behavior of large onset values for both [text set] and [text insert] with the same Pd version (the one you compiled yourself).

[Spacechild1]

Ok, I can reproduce the issue when compiling Pd on a Mac with clang. I think Miller cross compiles from Linux with gcc, that might explain the different outcome. Will have a look. And strangely, it only happens with [text insert] and not with [text set], although the code in question is basically the same. Will investigate.

[Spacechild1]

The bug is gone when changing
lineno = (x->x_f1 > (double)0x7fffffff ? 0x7fffffff : x->x_f1);
to
lineno = (x->x_f1 > (double)0x7fffffff ? 0x7fffffff : (int)x->x_f1);

lineno is already an integer, so one would think that explicitly casting x_f1 would be redundant. To me, this looks like a bug in clang... Compiler bugs are very rare, but they do happen after all...

[Spacechild1]

I pushed this "fix" to develop, also for consistency with [text set], but I would like to understand why this seemingly unnecessary cast does the trick... I probably have to look into the assembly...

[Spacechild1]

@porres please test with latest develop and report back.

[porres]

@porres please test with latest develop and report back.

IT WORKS :)

Ok... we can close this now I guess, but what about #848 ? It's also an issue that only happens when I compile Pd.

[porres]

what about #848 ?

opened a new issue about it... #1046

[claudeha]

x_f1 is float, 0x7fffffff

we cast 0x7fffffff to a double, so x_f1 should be widened appropriately for the comparison.

I meant the other one which was promoted to float by the result type of ?:. Fix looks sensible to me.

[Spacechild1]

I think you're one to something, but I still fail to see where exactly the overflow / undefined behavior occurs...

[claudeha]

x_f1 is float, so 0x7fffffff is promoted from int as ?: has a single result type, but nearest representable float is 0x8000000 which overflows when converted back to int. This is conjecture, looking at assembly would help resolve what is going on.

[Spacechild1]

Hmmm. From what I understand, the mantissa is truncated, so the value is effectively rounded down to the next representable value. But I'll do some reading and look at the disassembly.

[Spacechild1]

oh, you're right! both clang und GCC decide to round up (float)0x7fffffff at compile time:

https://godbolt.org/z/e2mtg2

Things get more interesting for (int)(float)0x7fffffff:

https://godbolt.org/z/DyKj3j

GCC outputs 2147483647 (as I would have expected), while clang outputs whatever value happens to be in esi (probably because it thinks that casting 0x8000000 back to int is undefined behavior).

[Spacechild1]

As a follow-up, here's what happens when converting an int to a float at runtime with cvtsi2ss:

"When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.

https://www.felixcloutier.com/x86/cvtsi2ss