From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 01EC93858D1E for ; Mon, 19 Sep 2022 14:58:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 01EC93858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663599531; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p8yI3mZO7ZRUWUN2vtjdn8WP0rPBKTdbTMI5OEIIf8M=; b=Sa2YWYmF4PoCnnmaV0aitgLlCltVIa3cyyRbJtZu8gBxORNNry6xkzJ5T46UINStTckM3t iQ7723qi7K4+DiNqQyiRaJv9sPoKTtJMz1S1qVp40ZydxSEbUJvszorBQc7d3stLexWbdM 8aH6tG/shFami22Q2Fb2qr6ShNC5OzE= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-126-xJWqEG5oOEepkAFIoyV2GQ-1; Mon, 19 Sep 2022 10:58:50 -0400 X-MC-Unique: xJWqEG5oOEepkAFIoyV2GQ-1 Received: by mail-qv1-f72.google.com with SMTP id g12-20020a0cfdcc000000b004ad431ceee0so1472955qvs.7 for ; Mon, 19 Sep 2022 07:58:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=p8yI3mZO7ZRUWUN2vtjdn8WP0rPBKTdbTMI5OEIIf8M=; b=XOL0eIXkGc/jGQiinMFrVJGxanPCo99PbgvVeEe6SvLle3AEJvMoDv0i5PEGizqZzR JytS5MpvNsbloqt0GOPhT8LL1d56mE2x055xF8FeBrO2eBwdJFHJs268lOgd2kzK91sr f93e22gUti8GigJLZd2VAl6HcV564f34oOwMb5nThHY3ygn5DpWoXjojV6j9BfAy7Cd1 UAH09+Dbto5udC7waJTPRfWFRFkIOAfDme3ScKTHnCNQumcmZEqnySBQDjJFVpcnLWK/ kt01Kyuu9DoviLOW2AXoS57VsVy+OSPxHcho1H6lKsXkq29mwuA1fuSH+oy/eXEu/VwU eIog== X-Gm-Message-State: ACrzQf23riDFghqYOa6H+RmJZq7vUYM7L+CdcuTE0AC33kL/0HQk/0bl jts0j4hkFvF2/5XsFgQMntdrFLASVAMRK9Akn8AUlCzZKnlHS8eakCOlBVMRa5v/OZBJLf2uC6M czYVGNpkdSphGLTIhfVs3pxvjWK5dDdbq2A== X-Received: by 2002:a05:620a:2a0d:b0:6b9:9976:1bf3 with SMTP id o13-20020a05620a2a0d00b006b999761bf3mr13101650qkp.255.1663599529044; Mon, 19 Sep 2022 07:58:49 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5iYrRoE4tYz+UdByv1qmEvXcBKQA90iaNzlsuWYU0/0/jft0X/UOV7JU0UtyC9hE3EsS0HQ3WovONWFepMWO4= X-Received: by 2002:a05:620a:2a0d:b0:6b9:9976:1bf3 with SMTP id o13-20020a05620a2a0d00b006b999761bf3mr13101635qkp.255.1663599528808; Mon, 19 Sep 2022 07:58:48 -0700 (PDT) MIME-Version: 1.0 References: <8f612783-6bfb-30a8-b755-447664a5272d@gjlay.de> In-Reply-To: From: Jonathan Wakely Date: Mon, 19 Sep 2022 15:58:38 +0100 Message-ID: Subject: Re: [patch, avr] Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints. To: Richard Biener Cc: Georg Johann Lay , gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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 Mon, 19 Sept 2022 at 10:06, Richard Biener wrote: > > On Mon, Sep 19, 2022 at 10:57 AM Georg Johann Lay wrote: > > > > > > > > Am 19.09.22 um 09:51 schrieb Richard Biener: > > > On Sun, Sep 18, 2022 at 7:40 PM Georg Johann Lay wrote: > > >> > > >> Hello, > > >> > > >> this patch fixed PR target/99184 which incorrectly rounded during 64-bit > > >> (long) double to 16-bit and 32-bit integers. > > >> > > >> The patch just removes the respective roundings from > > >> libf7-asm.sx::to_integer and ::to_unsigned. Luckily, LibF7 does nowhere > > >> use respective functions internally, the only user is in libf7.c::f7_exp > > >> > > >> which reads > > >> > > >> f7_round (qq, qq); > > >> int16_t q = f7_get_s16 (qq); > > >> > > >> so that f7_get_s16() operates on an already rounded value, and therefore > > >> this code works unaltered with or without rounding in to_integer. > > >> > > >> The patch applies to directory > > >> > > >> ./libgcc/config/avr/libf7/ > > >> > > >> and is the same for all GCC versions v10+. > > >> > > >> Please someone with write permissions commit it to trunk and backport to > > >> v12, v11, and v10 as it is a wrong-code issue. > > >> > > >> The patch will fit without problems (except for ChangeLog) because there > > >> is no traffic on that folder. > > > > > > Thanks, I've pushed the change. Please in future try to send patches > > > that can be applied with git am, thus use git format-patch > > > > > > Richard. > > > > Thanks you so much. The patch I generated with "git diff > file.diff", > > so that is not correct? > > Yes, it's correct, but see below. I would say it's just wrong. > > The only change is that I defined extra hunks > > for asm so that one can see the function like in > > > > @@ -601,9 +601,6 @@ DEFUN to_integer > > > > So git is not prepared to such hunks? Would you point me to some > > documentation on how to do it properly? > > The more useful process is that after changing the code you > do a git commit to your tree and then > > git format-patch --stdout HEAD^ > > to get a git patch. On that I can do 'git am' and that will produce > exactly the commit you produced, including the patch description > and ChangeLog parts. I had to add that manually. > > Indeed https://gcc.gnu.org/contribute.html doesn't mention this, > we should probably improve that. Jonathan, maybe the above > is not the optimal way so can you think of something to add > to the 'Submitting Patches' section to document this? I'll try to come up with something. I agree that format-patch (or just 'git show') is the proper way to generate a patch for submission to the mailing lists. Just doing 'git diff' only works if you haven't committed or staged any part of your work, and frankly if you haven't even got to the point of committing it locally, it's just a rough draft and probably not ready to submit to the mailing list. The current docs do not really represent anything close to best practice when using Git for version control. But last time I tried to improve those docs I gave up because people wanted perfection instead of "good enough" (compared to "quite bad" as we have now).