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.129.124]) by sourceware.org (Postfix) with ESMTPS id 1A65C3858C00 for ; Thu, 23 Feb 2023 18:22:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A65C3858C00 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=1677176520; 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=1LRNljS+WZeNZ2h6+/w9YwUoH8zjfnXrM0BFxV+Oht4=; b=ihO39CTXMSixmi8BwBMgtbcX0WaXHEyKNDFs4/l7SFesS3v8q5yd1o9AeeDvOM8rYHSJ0H YZVKjIZCPRzitJb3NtnxaqPBPRdHdU2HvKRgOT1fN4pyqzbk6s0p6g/12cG1vJ8CjCQYbj DAwk57aJ7/kmNGiQ/Z+1pDDujrvOv28= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-511-VeTj24alMMWBwCiBZsyPHA-1; Thu, 23 Feb 2023 13:21:59 -0500 X-MC-Unique: VeTj24alMMWBwCiBZsyPHA-1 Received: by mail-lj1-f200.google.com with SMTP id v14-20020a2e9f4e000000b002934fe0289bso3518394ljk.0 for ; Thu, 23 Feb 2023 10:21:59 -0800 (PST) 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:message-id :reply-to; bh=1LRNljS+WZeNZ2h6+/w9YwUoH8zjfnXrM0BFxV+Oht4=; b=3oXv8ayMO127UwXXpQZbqVkL8GcfgyeZrVmqCq08/g5tjNRs7Tr70qDj0FMPtWGtiK 6nTeKlqjwniWyN2K04YbUhEqqlLOSxJIVK89CiZWfY87EBRqoJJDvYSPN40mOwTYf+Km i7EwSoPj7kMSHPakfFW1UWqAr5jaqVOZ93oe9/r/j7S5dJAzFu6FtnHWfh2T2S4L2Qea aXaqdb80IXRaUJfwLJHs4Oi8QrXiIeRlFqoCr+ZPWu/ZliynCjE0EdC9HJIl0FT/NyQb Y5ybLI5W1IdVyAyitKQibeFz9r5p5zHyweiMfCEyGKe9Jybv6iBiCH7yJKonOSCG0Two zrDA== X-Gm-Message-State: AO0yUKV1zx+Z2rnphrbo96P6jyiBslL/gnaeI/OrObL3cmteGn66NsUA S5FunfPvNUbHFvDvhJ4I2BTWxoA9/HRE3cf6XWYvHHyxluI8PV1odc160ZWbrcLhiJcjO7Y006N ZxxkqidkwTZyQkUJso10zFHEWALplspY63w== X-Received: by 2002:a2e:b548:0:b0:293:2f6e:91bf with SMTP id a8-20020a2eb548000000b002932f6e91bfmr4069230ljn.7.1677176517919; Thu, 23 Feb 2023 10:21:57 -0800 (PST) X-Google-Smtp-Source: AK7set81LjrcijXKrILAXdabaFtX6ZV6VnJSXoqUqA088nsDlvcYHeEfACXVBsPOWLutP52Mzr5/a9zxHPBxICs8AiQ= X-Received: by 2002:a2e:b548:0:b0:293:2f6e:91bf with SMTP id a8-20020a2eb548000000b002932f6e91bfmr4069218ljn.7.1677176517543; Thu, 23 Feb 2023 10:21:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Thu, 23 Feb 2023 18:21:46 +0000 Message-ID: Subject: Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm To: Alexandre Oliva Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, libstdc++@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=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 Thu, 23 Feb 2023 at 17:55, Alexandre Oliva wrote: > > On Feb 22, 2023, Alexandre Oliva wrote: > > >> Just curious, why doesn't the pmf hack work on arm-vxworks7? > > > At first, I thought we were running into this just because we have to > > define __clang__ because of some vxworks system headers aimed at clang. > > But even as I tried to drop the #ifndef, the test still failed; I > > suspected it had to do with ARM's encoding of ptrmemfunc_vbit_in_delta, > > but I did not confirm that this was the case. > > It was much simpler than that: patching locale_facets_nonio.tcc did not > affect the code generated for the tests, even though the modified > definition was present in the preprocessed version, and the patch didn't > cause locale-inst.o to be rebuilt. > > > With a build from scratch, the following patchlet is enough for time_get > tests to pass for us, and I assume we'll have to keep on carrying such > local changes, but I wonder if it would make sense to submit a patch to > adjust all preprocessor tests for __clang__ in libstdc++ to also test > for __clang_major__. > > --- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc > +++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc > @@ -1465,7 +1465,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11 > ctype<_CharT> const& __ctype = use_facet >(__loc); > __err = ios_base::goodbit; > bool __use_state = false; > -#if __GNUC__ >= 5 && !defined(__clang__) > +#if __GNUC__ >= 5 && !(defined(__clang__) && defined(__clang_major__)) > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wpmf-conversions" > // Nasty hack. The C++ standard mandates that get invokes the do_get Yeah, we can do that ... but it would be annoying. We can't rely on __GNUC__ because other compilers pretend to be GCC (and clang now allows you to fake any value of __GNUC__ with the -fgcc-version flag), and we can't use __clang__, because other compilers now pretend to be clang ... where does it end?