From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 6215D39318B0 for ; Thu, 8 Dec 2022 19:58:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6215D39318B0 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pg1-x52d.google.com with SMTP id 62so2009129pgb.13 for ; Thu, 08 Dec 2022 11:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=HaCoVFRDnhh8fgXsRJdBO6ITICJJKk8cdprrLSKqTP0=; b=myRiMa9Dtpe7T/mj+I1slUI0i78dNk/JFCqREyba+dfZUio3QG2xT7zzw9EgseBP43 dNZkNQGfSpmz5m0x0ufkFt3ewFgGX4ErXliQZ9EhGCdWKWCMDA1n0WlgJ9nbJtlEjITL wOvUsE+Q2dolzZIzZRZCjz4UTeSZuOkcdUPEF1B8veHFZIr792kmcfaKiDIz+uE42tNg C8gc//bE4a7DVBdlPzpfyzu0jDYGD3Lc/6XUUq2gWbwST+zQS79gaHljkEmmO4XJzf8+ vc9It0MXOHqiGCGGRKrC9aS+I4N/Y7HWYE5CWBr1CPh7gUIFAO69UZYI0pY4WLvDHAyG ERNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HaCoVFRDnhh8fgXsRJdBO6ITICJJKk8cdprrLSKqTP0=; b=dDeRkSyt9nqndT/gKnmE6GZeu2nPsZBu3zUlSzwekqMmRrxZ5dsGfpHoDraXKL6iOt yAqlJQVD387UI/yWBBExrL65nzWplUbCjQVzXtoAgxrrSlbQ8Qkl0KVRVHGx/lURNeLA sRWF5+BOWyHntRSpqQp++LyXORa1Hvz2cRadU05PiKZiPnDCYt8jzdeXC/6iNQnKM2V6 6hjmdnfUtyGppAMu5f/3enyCixUFMoHWoe35GdZWoRghaQajKvwQDtKYdpGJrGY9bCNV uQ2l2fQFkHz8WAH2uH4fthmrfK1UomOY3ZEHNnU+rTRsOHerzJMkYKe+qJwwYM66AsME 4D3g== X-Gm-Message-State: ANoB5pn8thU4z7QzdlE2xNwZYAUBt4dB8ftspMeVGwjHlZORl85uuWdn OD4KI7VIZ2rDJV8CLV4s9Jf7+g== X-Google-Smtp-Source: AA0mqf4+swX+L2XB8wbczbDLDGRSffceaIc4ZgEyCDcGa+n32KlVwNZC/VnY7DdJLWozHgiaZQXI5Q== X-Received: by 2002:a62:5fc1:0:b0:575:fddc:891e with SMTP id t184-20020a625fc1000000b00575fddc891emr35898850pfb.40.1670529517100; Thu, 08 Dec 2022 11:58:37 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id a10-20020a63d40a000000b004771bf66781sm13312134pgh.65.2022.12.08.11.58.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 11:58:36 -0800 (PST) Date: Thu, 08 Dec 2022 11:58:36 -0800 (PST) X-Google-Original-Date: Thu, 08 Dec 2022 11:58:24 PST (-0800) Subject: Re: Behaviour differences on x86 and RISC-V on cos/sin functions In-Reply-To: CC: joseph@codesourcery.com, libc-alpha@sourceware.org From: Palmer Dabbelt To: ludovic@rivosinc.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 08 Dec 2022 11:24:48 PST (-0800), ludovic@rivosinc.com wrote: > Hi Joseph, > > Thank you for the reply. > > So IIUC, RISC-V behavior is expected and it should be up to the user of > libm/libc to handle the platform differences, correct? > > On the value of NaN, the difference is on purpose to lead to the test > failing on RISC-V. And for inspecting the bit-pattern, I only hastily put > together to have a test case passing/failing. Thank you for the pointers > though. > > I'll then figure out with the OpenJDK mailing lists what's the best way > forward. > > Cheers, > Ludovic > > On Thu, Dec 8, 2022 at 3:49 PM Joseph Myers wrote: > >> On Thu, 8 Dec 2022, Ludovic Henry wrote: >> >> > int64_t bitsNaN = 0x7fff800000000000L; >> > double valNaN = *((double*)&bitsNaN); >> > >> > double resD = acos(valNaN); >> > int64_t res = *((int64_t*)&resD); >> > if (!(res == bitsNaN)) { >> > printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res); >> > exit(1); >> >> The particular bit-pattern of a NaN resulting from a libm function is >> almost never specified in ISO C or IEEE floating point (the exceptions >> being fabs / copysign which correspond to IEEE operations that affect only >> the sign bit). On RISC-V, instructions returning a NaN return the >> canonical quiet NaN without regard to what NaN was an input to the >> operation, so you can't expect any kind of NaN propagation there (and the >> above input is not the canonical NaN used on RISC-V so will not be the >> result of most arithmetic instructions on RISC-V). So it's OK to follow the RISC-V rules for library functions? We don't have trig instructions so there's not really anything in the ISA here. Just following the normal rules around floating point seems generally sane, but I always get lost trying to read these specs... In other words: it's safe to call this behavior not a bug? >> The above is also not a safe way of inspecting the bit-pattern of a >> floating-point value (unless you're using -fno-strict-aliasing) because it >> violates standard aliasing rule; use unions or memcpy instead. >> >> -- >> Joseph S. Myers >> joseph@codesourcery.com >>