Ticket #574 (closed patch: fixed)

Opened 13 years ago

Last modified 11 years ago

Netbsd gets SIGFPE on alpha platform when calculating Inf

Reported by: Infinoid Owned by:
Priority: normal Milestone:
Component: none Version:
Severity: medium Keywords: alpha netbsd sigfpe fp
Cc: Language:
Patch status: applied Platform: netbsd


On alpha (for at least the netbsd OS), our PARROT_FLOATVAL_INF_POSITIVE macro results in SIGFPE, which causes some failing tests.

he++ submitted a patch with two related fixes. The first is to catch SIGFPE properly and ignore it. That's done with a signal() call at parrot init time, but there's a little confusion about the right place to put that. That part of the patch is a work in progress.

The second fix is to use math.h defines for Inf/-Inf/NaN on alpha, rather than trying to calculate the values directly.


netbsd-alpha-sigfpe.patch Download (4.5 KB) - added by Infinoid 13 years ago.
Here's the current patch, contains some redundant code and could use some cleanup.

Change History

Changed 13 years ago by Infinoid

Here's the current patch, contains some redundant code and could use some cleanup.

Changed 13 years ago by heidnes

Actually... The patch to src/main.c in the above can and should be deleted from the patchset, it was only present during initial testing, and I've also tested with it removed, and parrot still passes its test, since the platform misc.c / misc.h was added and does the same job.

I suspect also the patch to datatypes.h is no longer required now after we turned off SIGFPE, but it's an open question whether the NetBSD/alpha part of the patch should not be used universally, since the used constants are, as far as I know, standardized.

And ... This bug is not only related to handling of Inf, BTW, it's also the NaN handling which will in several cases land a SIGFPE, e.g. comparing a number with a NaN will by default trap.

Changed 13 years ago by doughera

Perl 5 uses fpsetmask(0) to avoid SIGFPE. That might be a good choice for parrot as well, though since parrot is also meant to be embedded, I have some hesitation setting such global policies.

In any case, avoiding things likely to generate SIGFPE is probably a good idea. Using the math.h #defines, when available, is almost certainly preferable to using the divide-by-zero trick. I'm sorry I wasn't paying enough attention when this came up earlier.

There are a number of ways to generate Inf and NaN, though different methods are likely needed on different platforms.

Using predefined constants from <math.h> (or similar) certainly is one, and seems to work on NetBSD (and probably other BSDs as well). It works on Linux, if the -std=c99 option is used, though that has other implications.

Using strtod("Infinity", (char **) NULL) or strtod("NaN", (char **)NULL) works on Solaris and Linux.

Using the current divide-by-zero trick seems to work on Linux, Mac, Solaris, and Windows. It's probably a good fallback.

That said, there are very few reasons to actually generate NaN or Inf anyway. I'm not sure why parrot does.

As for testing for NaN or Inf, the functions isnan() and isinf() are pretty widely available (and Parrot_signbit is already availble to test the sign).

In sum, I think this patch is a good step forward. After it is applied, it can probably even be generalized.

Changed 13 years ago by Infinoid

  • status changed from new to closed
  • resolution set to fixed
  • patch changed from new to applied

Thanks, committed as r38279. Some additional generalization sounds good.

Changed 11 years ago by plobsing

I have generalized this behaviour using a config probe to test for the system-provided macros in r49425.

Note: See TracTickets for help on using tickets.