From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=a6ap=72=suse.de=schwab@sourceware.org>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29])
	by sourceware.org (Postfix) with ESMTPS id 892E53858D39
	for <libc-alpha@sourceware.org>; Mon,  3 Apr 2023 08:43:06 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 892E53858D39
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
	by smtp-out2.suse.de (Postfix) with ESMTP id B7C571F8B8;
	Mon,  3 Apr 2023 08:43:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1680511385; h=from:from:reply-to: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=FScVrTVv0hrzJFU/5y0qAzskMHGgT0udSyT3i+LzA88=;
	b=uGPrMi0QsM4POXh9wVe7h62JyEEjXiH9dfhjEWTfg6LUddNTdm1/wsQITLBrBxvPlF0g0t
	Km/a05LX2fGHLO8YC76H2tOf5rMr9XQTMw9a1LbOCZxrs9y2JiOf6jYpXgrSj6UQ95pc5/
	DOR0jtpNq4vpghqighjNjXwdf7/Er0g=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1680511385;
	h=from:from:reply-to: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=FScVrTVv0hrzJFU/5y0qAzskMHGgT0udSyT3i+LzA88=;
	b=1UJrLgbST8twEW7ccapvpjLiu4JuzcbrIG97bjn7Z/XIN3iiuq7hLi85vWPIyb8tJ1j8xR
	lGlyvpsHxMAjQHDw==
Received: from hawking.suse.de (unknown [10.168.4.11])
	by relay2.suse.de (Postfix) with ESMTP id AB6352C206;
	Mon,  3 Apr 2023 08:43:05 +0000 (UTC)
Received: by hawking.suse.de (Postfix, from userid 17005)
	id 75CC34A0378; Mon,  3 Apr 2023 10:43:05 +0200 (CEST)
From: Andreas Schwab <schwab@suse.de>
To: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>
Cc: Florian Weimer <fweimer@redhat.com>
Subject: Re: Using glibc headers with non-GCC compilers which define
 _Float32 etc.
References: <87o7o575jl.fsf@oldenburg.str.redhat.com>
X-Yow: Yow!  Am I in Milwaukee?
Date: Mon, 03 Apr 2023 10:43:05 +0200
In-Reply-To: <87o7o575jl.fsf@oldenburg.str.redhat.com> (Florian Weimer via
	Libc-alpha's message of "Mon, 03 Apr 2023 10:07:10 +0200")
Message-ID: <mvmv8idqrty.fsf@suse.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: <libc-alpha.sourceware.org>

On Apr 03 2023, Florian Weimer via Libc-alpha wrote:

> We have a downstream bug that points out that if __GNUC__ is not
> defined, glibc assumes that it's necessary to define _Float32 as a
> typedef to float:
>
>   glibc: _FloatN and _FloatNx problem if _GNUC__ is not defined
>   <https://bugzilla.redhat.com/show_bug.cgi?id=2183212>
>
> That does not work if the compiler already defines _Float32.
>
> What should we do about this?

I don't think we should support that use case.  It's probably not the
only thing that will break in this situation.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."