public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r11-10387] i386: Uglify some local identifiers in *intrin.h [PR107748] Date: Mon, 21 Nov 2022 09:35:09 +0000 (GMT) [thread overview] Message-ID: <20221121093509.C43E83853D42@sourceware.org> (raw) https://gcc.gnu.org/g:961f0e1966549b7ce7c1cbce6a4a91f7062816f0 commit r11-10387-g961f0e1966549b7ce7c1cbce6a4a91f7062816f0 Author: Jakub Jelinek <jakub@redhat.com> Date: Mon Nov 21 10:28:27 2022 +0100 i386: Uglify some local identifiers in *intrin.h [PR107748] While reporting PR107748 (where is a problem with non-uglified names, but I've left it out because it needs fixing anyway), I've noticed various spots where identifiers in *intrin.h headers weren't uglified. The following patch fixed those that are related to unions (I've grepped for [a-zA-Z]\.[a-zA-Z] spots). The reason we need those to be uglified is the same as why the arguments of the inlines are __ prefixed and most of automatic vars in the inlines - say a, v or u aren't part of implementation namespace and so users could #define u whatever->something #include <x86intrin.h> and it should still work, as long as u is not e.g. one of the names of the functions/macros the header provides (_mm* etc.). 2022-11-21 Jakub Jelinek <jakub@redhat.com> PR target/107748 * config/i386/smmintrin.h (_mm_extract_ps): Uglify names of local variables and union members. (cherry picked from commit ec8ec09f9414be871e322fecf4ebf53e3687bd22) Diff: --- gcc/config/i386/smmintrin.h | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/gcc/config/i386/smmintrin.h b/gcc/config/i386/smmintrin.h index f8c4c920790..183df7f1833 100644 --- a/gcc/config/i386/smmintrin.h +++ b/gcc/config/i386/smmintrin.h @@ -365,17 +365,18 @@ _mm_insert_ps (__m128 __D, __m128 __S, const int __N) extern __inline int __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_extract_ps (__m128 __X, const int __N) { - union { int i; float f; } __tmp; - __tmp.f = __builtin_ia32_vec_ext_v4sf ((__v4sf)__X, __N); - return __tmp.i; + union { int __i; float __f; } __tmp; + __tmp.__f = __builtin_ia32_vec_ext_v4sf ((__v4sf)__X, __N); + return __tmp.__i; } #else #define _mm_extract_ps(X, N) \ (__extension__ \ ({ \ - union { int i; float f; } __tmp; \ - __tmp.f = __builtin_ia32_vec_ext_v4sf ((__v4sf)(__m128)(X), (int)(N)); \ - __tmp.i; \ + union { int __i; float __f; } __tmp; \ + __tmp.__f = __builtin_ia32_vec_ext_v4sf ((__v4sf)(__m128)(X), \ + (int)(N)); \ + __tmp.__i; \ })) #endif
reply other threads:[~2022-11-21 9:35 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221121093509.C43E83853D42@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).