[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

uweigand added a comment. In https://reviews.llvm.org/D30415#703442, @hfinkel wrote: > In https://reviews.llvm.org/D30415#703398, @echristo wrote: > > > Different suggestion: > > > > Remove the faltivec option. Even gcc doesn't support it anymore afaict. > > > What are you suggesting? Always havi

[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

uweigand added a comment. In https://reviews.llvm.org/D30415#704761, @echristo wrote: > In https://reviews.llvm.org/D30415#703652, @uweigand wrote: > > > I'm a bit confused by this discussion. -faltivec and -maltivec are simply > > aliases, they do exactly the same thing; the clang-internal var

[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

uweigand added a comment. In https://reviews.llvm.org/D30415#705889, @echristo wrote: > In https://reviews.llvm.org/D30415#705196, @uweigand wrote: > > > Well, mainline GCC doesn't have -faltivec at all and never had, I think > > this was only an Apple GCC extension ... Not sure what exactly th

[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

uweigand added a comment. SystemZ parts LGTM. Thanks! https://reviews.llvm.org/D30415 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

uweigand added a comment. This means the implementation now deviates from the documented vector extension syntax, right? I guess it's strictly an extension of the documented syntax, but that may still lead to incompatibilities with other compilers for the platform. If we want to make such a

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

uweigand added a comment. In D102064#2751089 , @ZarkoCA wrote: > In D102064#2751001 , @uweigand > wrote: > >> This means the implementation now deviates from the documented vector >> extension syntax, right? I

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At&t dialect

uweigand added a comment. Herald added a subscriber: pengfei. Hi @hans , we're having some issues with using the AssemblerDialect mechanism to support both the GNU assembler and the IBM HLASM assembler in the SystemZ back-end. See also the discussion started here: https://lists.llvm.org/pip

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At&t dialect

uweigand added a comment. In D82862#2500038 , @pengfei wrote: >> What is the reason for treating this differently in LLVM? > > I'm not sure if it is related to this. I think one difference is that LLVM is > supporting MS inline assembly. Although it uses

[PATCH] D82862: [ThinLTO] Always parse module level inline asm with At&t dialect

uweigand added a comment. In D82862#2500717 , @hans wrote: >> In D82862#2498785 , @hans wrote: >> >>> The motivation for my change was really just to make ThinLTO compiles work >>> the same as non-ThinLTO ones. >>>

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added a comment. SystemZ specific parts LGTM, but it would be good to have someone else review the common code / IR changes as well. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109362/new/ https://reviews.llvm.org/D109362 _

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added a comment. Looking at the common code parts, it seems the behavior of MM_GOFF is actually identical to MM_ELF. Is this correct? If so, do we really need a different format type here? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added a comment. In D109362#3000284 , @anirudhp wrote: > In D109362#2999688 , @uweigand > wrote: > >> Looking at the common code parts, it seems the behavior of MM_GOFF is >> actually identical to MM_EL

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand added inline comments. Comment at: llvm/docs/LangRef.rst:2596 * ``e``: ELF mangling: Private symbols get a ``.L`` prefix. +* ``l``: GOFF mangling: Private symbols get a ``.L`` prefix. * ``m``: Mips mangling: Private symbols get a ``$`` prefix. -

[PATCH] D109362: [SystemZ][z/OS] Add GOFF Support to the DataLayout

uweigand accepted this revision. uweigand added a comment. This LGTM now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109362/new/ https://reviews.llvm.org/D109362 ___ cfe-commits mailing list cfe-commi

<    1   2