From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id B7C37395BC18 for ; Tue, 10 Aug 2021 13:02:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7C37395BC18 Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17AD2nPE134841; Tue, 10 Aug 2021 09:02:56 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3ab8kka92n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Aug 2021 09:02:55 -0400 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 17AD2slS135337; Tue, 10 Aug 2021 09:02:54 -0400 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 3ab8kka8pg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Aug 2021 09:02:54 -0400 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 17ACv7vw012481; Tue, 10 Aug 2021 13:02:27 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma05wdc.us.ibm.com with ESMTP id 3a9htbt72n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Aug 2021 13:02:27 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 17AD2RpJ10879690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Aug 2021 13:02:27 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DE159AC064; Tue, 10 Aug 2021 13:02:26 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7CC28AC066; Tue, 10 Aug 2021 13:02:25 +0000 (GMT) Received: from Bills-MacBook-Pro.local (unknown [9.211.91.192]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 10 Aug 2021 13:02:25 +0000 (GMT) Reply-To: wschmidt@linux.ibm.com Subject: Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, willschm@linux.ibm.com References: <5394facbf34d21fab7944808ccb27dca74f6f51f.1627562851.git.wschmidt@linux.ibm.com> <20210807000158.GZ1583@gate.crashing.org> <9842d456-9003-8cbf-0e13-40821ae4217c@linux.ibm.com> <20210808202710.GC1583@gate.crashing.org> <3b2a741c-5e94-3689-833a-6bb2be366adf@linux.ibm.com> <0175e9b9-d0a7-f0c2-89b3-230251a1bf80@linux.ibm.com> <20210809234458.GF1583@gate.crashing.org> <188d0a99-4382-39cd-fb4e-3ccacd63c010@linux.ibm.com> <20210810124806.GH1583@gate.crashing.org> From: Bill Schmidt Message-ID: <031c85bf-a022-a2e2-ac76-4030c6241cc8@linux.ibm.com> Date: Tue, 10 Aug 2021 08:02:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210810124806.GH1583@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-GCONF: 00 X-Proofpoint-GUID: B5WSL3Dm6PQKYYfHWlO9ArIMjQqW0Go0 X-Proofpoint-ORIG-GUID: PPXX0yQnzZIXdNlWgEZmTF0QIyHu9rRc X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-10_05:2021-08-10, 2021-08-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0 phishscore=0 spamscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108100084 X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 13:02:59 -0000 On 8/10/21 7:48 AM, Segher Boessenkool wrote: > On Tue, Aug 10, 2021 at 07:17:54AM -0500, Bill Schmidt wrote: >> On 8/9/21 6:44 PM, Segher Boessenkool wrote: >>> This is not a documented GCC extension either, and it might even >>> conflict with the existing void * extension (allowing arithmetic on it, >>> by defining sizeof(void)). In either case it is not currently defined. >>> >> I'm not sure how you get to this, but all we're doing here is standard C. > Arithmetic on void* is the GCC extension. sizeof(void) is 1 as GCC > extension, instead of being undefined. Pointer arithmetic is only > defined for arrays of the type being pointed to, and you cannot have an > array of void. You can do this as GCC extension though, it behaves as > if it was a char* instead. > >> x.c: >> >> char >> foo (const void *x) >> { >> const char *y = (const char *) x; >> return *y; >> } > And this behaves exactly the same if you do s/const void/void/ . The > const qualifier is meaningless on things of type void, since you cannot > have an lvalue of that type anyway. And all type qualifiers can be cast > away (or cast into existence). > >> y.c: >> >> void >> foo (const void *x, char c) >> { >> const char *y = (const char *) x; >> *y = c; >> } >> >> wschmidt@rain6p1:~/src$ gcc -c x.c >> wschmidt@rain6p1:~/src$ gcc -c y.c >> y.c: In function 'foo': >> y.c:5:6: error: assignment of read-only location '*y' >> *y = c; >> ^ > Yes, *y is an lvalue. *x is not: *x is an error. > > > It *is* allowed to have a "const void", but it means exactly the same as > just "void" (you cannot assign to either!) And, they are compatible > types, too, (they are the *same* type in fact!), so if you ever would > treat them differently it would be mightily confusing :-) The whole point is that this data type is only used for interfaces, as shown in the example code.  Nobody wants to define const void as anything.  The const serves only as a contract that the pointed-to object, no matter what it is cast to, will not be modified. I think you're over-thinking this. :-) Bill > > > Segher