[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Maybe these patches need to be reposted to Github as they seem to be ignored 
here now after the swtich from Phabricator.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149867/new/

https://reviews.llvm.org/D149867

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Any news on this? I guess it would be nice to get the remaining m68k patches 
merged before the Phrabricator shutdown.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149867/new/

https://reviews.llvm.org/D149867

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D149867#4612589 , @myhsu wrote:

> In D149867#4603853 , @aaron.ballman 
> wrote:
>
>> In D149867#4544489 , @myhsu wrote:
>>
>>> Sorry I was busy on my phd defense (which I passed!) in the past month. 
>>> I'll get back to this next week.
>>
>> Congratulations!! 
>
> Thank you!

Oh man, I completely missed that.

Congratulations, Min! That must be a huge relieve!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149867/new/

https://reviews.llvm.org/D149867

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Any update on this?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149867/new/

https://reviews.llvm.org/D149867

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D149867: [M68k] Add Clang support for the new M68k_RTD CC

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D149867#4386271 , @jrtc27 wrote:

> I disagree. Being experimental doesn't mean you should do the wrong thing. 
> Reusing stdcall in the frontend is ugly, pollutes non-m68k code paths (doing 
> your own thing _avoids_ that and makes the experimental backend get out of 
> the way, even) and introduces a bug where you can write garbage code and have 
> it compile rather than be rejected like it should be.

Maybe we can get the TLS stuff merged first before dealing with this more 
complex change?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149867/new/

https://reviews.llvm.org/D149867

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D147481: [M68k] Add basic Clang supports for M68881/2

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

@myhsu Can you fix the typo in the commit message?

s/supports/support/


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147481/new/

https://reviews.llvm.org/D147481

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D140695: [M68k] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D140695#4019189 , @brad wrote:

> How come the Clang M68k backend defaults to 68000? GCC defaults to 68020 for 
> all targets.

The Clang M68k is a complete rewrite from scratch, independent of GCC, so it's 
not surprising you may see differences between Clang and GCC.

I'm open to raising the default baseline to 68020 though once the backend has 
matured enough.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140695/new/

https://reviews.llvm.org/D140695

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D140695: [M68k] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz accepted this revision.
glaubitz added a comment.

Tested and works as expected. Thanks a lot for catching this!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140695/new/

https://reviews.llvm.org/D140695

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133405: [Linux] Hack around Linux/sparc

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D133405#3782137 , @nikic wrote:

> In D133405#3782136 , @glaubitz 
> wrote:
>
>> In D133405#3782092 , @nikic wrote:
>>
 I've been using this hack to work around the Linux/sparc64 compile failure 
 described in Issue #47994, especially since the underlying glibc PR 
 build/27558 doesn't seem to be making progress and some fix is required to 
 have LLVM build on sparc64-unknown-linux-gnu at all, as evidenced on the 
 buildbot.
>>>
>>> Didn't this already get fixed by 
>>> https://github.com/bminor/glibc/commit/d0fa09a7701956036ff36f8ca188e9fff81553d8
>>>  upstream? There was also a later fix for the wchar.h header.
>>
>> Seems it has only been fixed for some headers, see: 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=27087
>
> The other issue has also already been fixed in 
> https://github.com/bminor/glibc/commit/c7509d49c4e8fa494120c5ead21338559dad16f5
>  (and these fixes have been backported to glibc 2.34+).
>
> Are you still seeing any issues with a current glibc?

glibc 2.34 currently fails to build from source on sparc64 due to testsuite 
failures. I haven't reported these upstream yet which I will do now.

See: 
https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.34-7=1661614017=0

  FAIL: elf/tst-audit24a
  FAIL: elf/tst-audit24b
  FAIL: elf/tst-audit24c
  FAIL: elf/tst-audit24d
  FAIL: elf/tst-audit25a
  FAIL: elf/tst-audit25b
  FAIL: elf/tst-ptrguard1-static
  FAIL: elf/tst-stackguard1-static
  FAIL: nptl/tst-cancel24-static
  FAIL: nptl/tst-cancel30
  FAIL: nptl/tst-pthread-attr-affinity-fail
  FAIL: nptl/tst-stackguard1-static
  FAIL: socket/tst-socket-timestamp


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133405/new/

https://reviews.llvm.org/D133405

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133405: [Linux] Hack around Linux/sparc

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D133405#3782092 , @nikic wrote:

>> I've been using this hack to work around the Linux/sparc64 compile failure 
>> described in Issue #47994, especially since the underlying glibc PR 
>> build/27558 doesn't seem to be making progress and some fix is required to 
>> have LLVM build on sparc64-unknown-linux-gnu at all, as evidenced on the 
>> buildbot.
>
> Didn't this already get fixed by 
> https://github.com/bminor/glibc/commit/d0fa09a7701956036ff36f8ca188e9fff81553d8
>  upstream? There was also a later fix for the wchar.h header.

Seems it has only been fixed for some headers, see: 
https://sourceware.org/bugzilla/show_bug.cgi?id=27087


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133405/new/

https://reviews.llvm.org/D133405

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133405: [Linux] Hack around Linux/sparc

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Thanks, this is definitely very useful. I have pinged glibc upstream and asked 
them about the progress about this change. Let' see.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133405/new/

https://reviews.llvm.org/D133405

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D130688#3731619 , @ro wrote:

> In D130688#3731611 , @glaubitz 
> wrote:
>
>> 
>
>
>
>> Yeah, someone from the LEON community should comment whether they would be 
>> OK to default to V9 on all Linux targets. I don't really want to omit Gentoo 
>> here which still support Linux on SPARC.
>
> How could they?  LEON is V8 (with extensions) only!

Well, they could patch LLVM locally. I assume they don't use the pristine 
upstream sources anyway in such custom setups.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130688/new/

https://reviews.llvm.org/D130688

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D130688#3731577 , @ro wrote:

> It's almost three weeks since the last comments.  Any suggestions on how to 
> proceed with this patch?  Given that the original issue (atomics not inlined 
> with `-m32`) is now worked around by always linking with `--as-needed 
> -latomic --no-as-needed`, the patch is no longer needed to fix build 
> failures.  However, it still would make a nice and cheap optimization on 
> distros that require v9 CPUs, if we can figure out how to reliably identify 
> them.  Maybe someone from the LEON community could chime in?

Yeah, someone from the LEON community should comment whether they would be OK 
to default to V9 on all Linux targets. I don't really want to omit Gentoo here 
which still support Linux on SPARC.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130688/new/

https://reviews.llvm.org/D130688

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/Sparc.cpp:139
+  if (Triple.getArch() == llvm::Triple::sparc &&
+  (Triple.isOSSolaris() || Distro(D.getVFS(), Triple).IsDebian()))
 return "v9";

Can we do it "IsLinux()" instead of "IsDebian()"?

I think Gentoo should profit from this change as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130688/new/

https://reviews.llvm.org/D130688

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130569: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux [clang-linux-sparc-libatomic.patch, submitted 2022-07-26]

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz accepted this revision.
glaubitz added a comment.
This revision is now accepted and ready to land.

This should address the current CI issues on sparc64 together with D130571 
.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130569/new/

https://reviews.llvm.org/D130569

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130566: [Driver] Default to DWARF 4 on Linux/sparc64

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Interesting and thanks for catching this! How did you discover this issue? Is 
there any particular program that fails to build due to this issue?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130566/new/

https://reviews.llvm.org/D130566

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135
 }
+// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with
+// libatomic as a workaround.

glaubitz wrote:
> ro wrote:
> > ro wrote:
> > > glaubitz wrote:
> > > > ro wrote:
> > > > > glaubitz wrote:
> > > > > > joerg wrote:
> > > > > > > This comment is misleading. It's not so much that LLVM doesn't 
> > > > > > > support them, but that SPARCv8 doesn't have the necessary 
> > > > > > > hardware support. The v8+ support is incomplete, which is a 
> > > > > > > related problem though.
> > > > > > As far as I know, 64-bit atomics are supported if you enable V8+ in 
> > > > > > GCC - without linking against `libatomic`:
> > > > > > 
> > > > > > ```
> > > > > > glaubitz@gcc202:~$ cat atomic.c
> > > > > > #include 
> > > > > > 
> > > > > > int main()
> > > > > > {
> > > > > >   int64_t x = 0, y = 1;
> > > > > >   y = __sync_val_compare_and_swap(, x, y);
> > > > > >   return 0;
> > > > > > }
> > > > > > glaubitz@gcc202:~$ gcc -m32 -mv8plus atomic.c -o atomic
> > > > > > glaubitz@gcc202:~$
> > > > > > ```
> > > > > I know, that's why I referred to my patch to default `clang` on
> > > > > Solaris/sparc to V8+.  I'll update the comment.
> > > > > 
> > > > > I'd tried to actually fix the underlying issue (`clang` not emitting
> > > > > `casx` with `-m32 -mcpu=v9`), but ran into internal errors and
> > > > > areas of LLVM I know nothing about.  I might post a WIP patch
> > > > > for reference since there are several issues there.
> > > > I think @jrtc27 might be able to give advise here having the knowledge 
> > > > on the Tablegen stuff (if my mind serves me right).
> > > > 
> > > > The disassembly shows in any case that `casx` is being emitted as you 
> > > > say:
> > > > 
> > > > ```
> > > > 69c:   c7 f0 50 02 casx  [ %g1 ], %g2, %g3
> > > > ```
> > > Of course it does, thus my reference to `unlike gcc` in the
> > > summary.  What Joerg meant, I believe, is that V8+ support
> > > **in LLVM** is incomplete.
> > Right, `gcc` does all of this correctly.  One LLVM issue, e.g., is
> > that it handles `casx` as 64-bit only (cf. `SparcInstr64Bit.td`)
> > while it should be guarded by `HasV9` instead.
> Interesting. Would `SparcInstr64Bit.td` actually get used when targeting 
> 32-bit SPARC?
> 
> If yes, it looks like replacing the guards `Is64Bit` with `HasV9` should do 
> the trick, shouldn't it?
Ah, the header of `SparcInstr64Bit.td` actually has the following comment:

```
// This file contains instruction definitions and patterns needed for 64-bit
// code generation on SPARC v9.
//
// Some SPARC v9 instructions are defined in SparcInstrInfo.td because they can
// also be used in 32-bit code running on a SPARC v9 CPU.
```

So, I guess move the 64-bit atomics stuff out of `SparcInstr64.td` and guard it 
with `HasV9` instead of `Is64Bit`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118021/new/

https://reviews.llvm.org/D118021

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135
 }
+// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with
+// libatomic as a workaround.

ro wrote:
> ro wrote:
> > glaubitz wrote:
> > > ro wrote:
> > > > glaubitz wrote:
> > > > > joerg wrote:
> > > > > > This comment is misleading. It's not so much that LLVM doesn't 
> > > > > > support them, but that SPARCv8 doesn't have the necessary hardware 
> > > > > > support. The v8+ support is incomplete, which is a related problem 
> > > > > > though.
> > > > > As far as I know, 64-bit atomics are supported if you enable V8+ in 
> > > > > GCC - without linking against `libatomic`:
> > > > > 
> > > > > ```
> > > > > glaubitz@gcc202:~$ cat atomic.c
> > > > > #include 
> > > > > 
> > > > > int main()
> > > > > {
> > > > >   int64_t x = 0, y = 1;
> > > > >   y = __sync_val_compare_and_swap(, x, y);
> > > > >   return 0;
> > > > > }
> > > > > glaubitz@gcc202:~$ gcc -m32 -mv8plus atomic.c -o atomic
> > > > > glaubitz@gcc202:~$
> > > > > ```
> > > > I know, that's why I referred to my patch to default `clang` on
> > > > Solaris/sparc to V8+.  I'll update the comment.
> > > > 
> > > > I'd tried to actually fix the underlying issue (`clang` not emitting
> > > > `casx` with `-m32 -mcpu=v9`), but ran into internal errors and
> > > > areas of LLVM I know nothing about.  I might post a WIP patch
> > > > for reference since there are several issues there.
> > > I think @jrtc27 might be able to give advise here having the knowledge on 
> > > the Tablegen stuff (if my mind serves me right).
> > > 
> > > The disassembly shows in any case that `casx` is being emitted as you say:
> > > 
> > > ```
> > > 69c:   c7 f0 50 02 casx  [ %g1 ], %g2, %g3
> > > ```
> > Of course it does, thus my reference to `unlike gcc` in the
> > summary.  What Joerg meant, I believe, is that V8+ support
> > **in LLVM** is incomplete.
> Right, `gcc` does all of this correctly.  One LLVM issue, e.g., is
> that it handles `casx` as 64-bit only (cf. `SparcInstr64Bit.td`)
> while it should be guarded by `HasV9` instead.
Interesting. Would `SparcInstr64Bit.td` actually get used when targeting 32-bit 
SPARC?

If yes, it looks like replacing the guards `Is64Bit` with `HasV9` should do the 
trick, shouldn't it?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118021/new/

https://reviews.llvm.org/D118021

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:138-139
+if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), true));
+  CmdArgs.push_back("-latomic");
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), false));

ro wrote:
> glaubitz wrote:
> > Note, this will only work when `__atomic_compare_exchange()` is being used 
> > as ``__sync_val_compare_and_swap_8` is not implemented by `libatomic` in 
> > gcc, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 (Unless this 
> > has changed recently).
> True, that the summary said `this patch works around the first of those`.  
> The other part is now D118024.
Ah, sorry. I missed that he was specifically talking about SPARCv8.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118021/new/

https://reviews.llvm.org/D118021

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135
 }
+// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with
+// libatomic as a workaround.

ro wrote:
> glaubitz wrote:
> > joerg wrote:
> > > This comment is misleading. It's not so much that LLVM doesn't support 
> > > them, but that SPARCv8 doesn't have the necessary hardware support. The 
> > > v8+ support is incomplete, which is a related problem though.
> > As far as I know, 64-bit atomics are supported if you enable V8+ in GCC - 
> > without linking against `libatomic`:
> > 
> > ```
> > glaubitz@gcc202:~$ cat atomic.c
> > #include 
> > 
> > int main()
> > {
> >   int64_t x = 0, y = 1;
> >   y = __sync_val_compare_and_swap(, x, y);
> >   return 0;
> > }
> > glaubitz@gcc202:~$ gcc -m32 -mv8plus atomic.c -o atomic
> > glaubitz@gcc202:~$
> > ```
> I know, that's why I referred to my patch to default `clang` on
> Solaris/sparc to V8+.  I'll update the comment.
> 
> I'd tried to actually fix the underlying issue (`clang` not emitting
> `casx` with `-m32 -mcpu=v9`), but ran into internal errors and
> areas of LLVM I know nothing about.  I might post a WIP patch
> for reference since there are several issues there.
I think @jrtc27 might be able to give advise here having the knowledge on the 
Tablegen stuff (if my mind serves me right).

The disassembly shows in any case that `casx` is being emitted as you say:

```
69c:   c7 f0 50 02 casx  [ %g1 ], %g2, %g3
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118021/new/

https://reviews.llvm.org/D118021

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135
 }
+// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with
+// libatomic as a workaround.

joerg wrote:
> This comment is misleading. It's not so much that LLVM doesn't support them, 
> but that SPARCv8 doesn't have the necessary hardware support. The v8+ support 
> is incomplete, which is a related problem though.
As far as I know, 64-bit atomics are supported if you enable V8+ in GCC - 
without linking against `libatomic`:

```
glaubitz@gcc202:~$ cat atomic.c
#include 

int main()
{
  int64_t x = 0, y = 1;
  y = __sync_val_compare_and_swap(, x, y);
  return 0;
}
glaubitz@gcc202:~$ gcc -m32 -mv8plus atomic.c -o atomic
glaubitz@gcc202:~$
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118021/new/

https://reviews.llvm.org/D118021

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:138-139
+if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) {
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), true));
+  CmdArgs.push_back("-latomic");
+  CmdArgs.push_back(getAsNeededOption(getToolChain(), false));

Note, this will only work when `__atomic_compare_exchange()` is being used as 
``__sync_val_compare_and_swap_8` is not implemented by `libatomic` in gcc, see: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 (Unless this has changed 
recently).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118021/new/

https://reviews.llvm.org/D118021

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Ah, I actually ran into this very problem! Thanks for fixing this.

Will test this today on Linux and report back!

Could you maybe have a look at my updated revision here? 
https://reviews.llvm.org/D98575

I think this particular change should be save on Solaris as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118021/new/

https://reviews.llvm.org/D118021

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Could someone land this for me? Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 401953.
glaubitz edited the summary of this revision.
glaubitz added a comment.

Minor improvement to the commit description.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3479,8 +3479,8 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3479,8 +3479,8 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 401951.
glaubitz edited the summary of this revision.
glaubitz added a comment.

Updated the patch as requested and dropped all changes except the removal of 
__sparcv9 and __sparcv9__.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3479,8 +3479,8 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3479,8 +3479,8 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 401950.
glaubitz added a comment.

Made changes according to review and dropped every change except removing 
__sparcv9 and __sparcv9__.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3479,8 +3479,8 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3479,8 +3479,8 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108792: [M68k] Update pointer data layout

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

@ricky26 Could you also get this fix backported in the LLVM fork of Rust?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108792/new/

https://reviews.llvm.org/D108792

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D100148#2881382 , @MaskRay wrote:

> Since @glaubitz is here:
>
> I want to set `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` to on by default so that 
> the libraries for x86-64 will be in 
> `lib/clang/13.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.profile.a` instead 
> of `lib/clang/13.0.0/lib/linux/libclang_rt.profile-x86_64.a`.
> Clang driver supports both paths.

OK, I don't think this will have any ramifications for Debian. But if you want 
me to test a patch, please let me know or pull me into the review.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D100148#2880499 , @hvdijk wrote:

> Updated to use `Triple.isX32()`.
>
> Should we perhaps just merge this as is, ahead of the update to compiler-rt 
> to create x32 objects? For non-x32, this change is NFC, for x32, the change 
> results in a better error message about compiler-rt objects not existing 
> rather than being for the wrong architecture.

Yes, I fully agree on this stance. I've been waiting for this patch for Debian, 
plus the remaining changes to get Rust to build on x32 ;-).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D105457#2874516 , @dblaikie wrote:

> Any ideas what version of the standard library these buildbots are using? 
> This /looks/ a bit like a bug in the standard library in use, perhaps? (also 
> because it's not showing up in lots of other buildbots/developers, I assume?)

I cannot speak for the other builds bots, but the cross-buildbot for m68k which 
I maintain is running openSUSE Leap 15.3 with GCC 7.5.0.

Maybe your change is compatible with newer versions of GCC only?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105457/new/

https://reviews.llvm.org/D105457

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D105457#2873294 , @dyung wrote:

> This change I suspect is causing a build failure on a build bot.
>
> https://lab.llvm.org/buildbot/#/builders/110/builds/4827
>
>   FAILED: /usr/bin/c++  -DCLANG_ROUND_TRIP_CC1_ARGS=ON -DGTEST_HAS_RTTI=0 
> -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
> -D__STDC_LIMIT_MACROS -Itools/clang/unittests/AST 
> -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/unittests/AST
>  
> -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/include
>  -Itools/clang/include -Iinclude 
> -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/include
>  
> -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/utils/unittest/googletest/include
>  
> -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/utils/unittest/googlemock/include
>  -march=broadwell -fPIC -fno-semantic-interposition 
> -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wno-missing-field-initializers -pedantic -Wno-long-long 
> -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment 
> -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
> -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG
> -Wno-variadic-macros -fno-exceptions -fno-rtti -UNDEBUG -Wno-suggest-override 
> -std=c++14 -MD -MT 
> tools/clang/unittests/AST/CMakeFiles/ASTTests.dir/StmtPrinterTest.cpp.o -MF 
> tools/clang/unittests/AST/CMakeFiles/ASTTests.dir/StmtPrinterTest.cpp.o.d -o 
> tools/clang/unittests/AST/CMakeFiles/ASTTests.dir/StmtPrinterTest.cpp.o -c 
> /home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/unittests/AST/StmtPrinterTest.cpp
>   /tmp/cc8Ycpsn.s: Assembler messages:
>   /tmp/cc8Ycpsn.s:11414: Error: symbol 
> `_ZNSt17_Function_handlerIFbPKN5clang4StmtEENS0_UlS3_E2_EE9_M_invokeERKSt9_Any_dataOS3_'
>  is already defined
>   /tmp/cc8Ycpsn.s:11937: Error: symbol 
> `_ZNSt14_Function_base13_Base_managerIN5clangUlPKNS1_4StmtEE2_EE10_M_managerERSt9_Any_dataRKS7_St18_Manager_operation'
>  is already defined
>   ninja: build stopped: subcommand failed.
>
> Can you take a look?

Indeed, it also breaks the cross-build for M68k: 
http://lab.llvm.org:8014/#/builders/180/builds/341


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105457/new/

https://reviews.llvm.org/D105457

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");

hvdijk wrote:
> brad wrote:
> > glaubitz wrote:
> > > glaubitz wrote:
> > > > ro wrote:
> > > > > glaubitz wrote:
> > > > > > jrtc27 wrote:
> > > > > > > This doesn't need changing, we can define more things than GCC to 
> > > > > > > keep it simple.
> > > > > > Well, my original intent was to match GCC to make sure we're 100% 
> > > > > > compatible and I would like to keep it that way.
> > > > > I agree with Jessica here: you're creating a complicated maze for no 
> > > > > real gain.  Besides, have you checked what `gcc` on the BSDs really 
> > > > > does?  They often neglect to get their changes upstream and what's in 
> > > > > the gcc repo doesn't necessarily represent what they actually use.
> > > > Yes, I have verified that GCC behaves the exact same way as this change 
> > > > and I don't see any reason not to mimic the exact same behavior in 
> > > > clang for maximum compatibility.
> > > FWIW, I meant GCC on the various BSDs. I do not think it's a wise idea to 
> > > have clang deviate from what GCC does as only this way we can guarantee 
> > > that everything that compiles with GCC will compile with clang.
> > > Besides, have you checked what `gcc` on the BSDs really does?  They often 
> > > neglect to get their changes upstream and what's in the gcc repo doesn't 
> > > necessarily represent what they actually use.
> > 
> > What is upstream is what we do. There are no local patches that change 
> > behavior in this particular area.
> (Copying here what I had already replied privately a while back) It worries 
> me that this switch statement only handles known operating systems (Linux, 
> FreeBSD, NetBSD, OpenBSD, Solaris) when we also have code to allow 
> SparcV9TargetInfo to be created without an operating system in 
> clang/lib/Basic/Targets.cpp. Either there should be a default case that is 
> properly handled, or if that actually cannot happen, there should be an 
> assert that it doesn't happen.
> 
> I agree with the earlier comments that there should be nothing wrong with 
> defining more macros than GCC, if the macros make sense. For the 
> SparcV9TargetInfo class, my impression is that the macros make sense. For the 
> SparcV8TargetInfo class with a V9 CPU, reading the discussion in D86621, if 
> Oracle say that `__sparcv9` is only for 64-bit mode, GCC also only defines it 
> for 64-bit mode, glibc assumes that `__sparcv9` implies 64-bit mode, etc. 
> then SparcV8TargetInfo should not be defining `__sparcv9`. Your changes to 
> SparcV8TargetInfo should be enough to fix bug 49562, right? If so, would it 
> be okay to update this diff with just that?
> Either there should be a default case that is properly handled, or if that 
> actually cannot happen, there should be an assert that it doesn't happen.

OK, I can enable all definitions by default.

> I agree with the earlier comments that there should be nothing wrong with 
> defining more macros than GCC, if the macros make sense.

My argument is that I don't want to break existing software. We are here 
because I ran into an FTBFS because GCC and Clang were deviating from what they 
are defining.

I fully agree that what GCC does it not necessarily logically correct. But if 
we mimic GCC are making sure that we don't break any existing software.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

@hvdijk I just noticed that the sanitizer defines `SANITIZER_X32` for x32, so I 
assume your patch itself is already correct.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D100148#2683710 , @hvdijk wrote:

> In D100148#2683325 , @glaubitz 
> wrote:
>
>> Hi! Can we get this patch merged as-is or do we need anything else?
>
> Sorry, miscommunication. I was thinking you could use this to update D99988 
>  to actually build the relevant compiler-rt 
> bits for x32, and then once both that and this are ready, both can be 
> submitted at the same time. The reason for that is that this is not useful by 
> itself, and if it turns out that D99988  
> actually requires some other clang change as well that we are not seeing yet, 
> it will be easier to update this if it has not been pushed yet. Do you think 
> it would be better to push this first?

Understood. However, I'm not really sure what else we need. Do we just take the 
architecture definition from here to pass the proper flags to the compiler or 
do we also need to add
some x32-specific code?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Hi! Can we get this patch merged as-is or do we need anything else?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

So, we only need D99988  and this one (D100148 
) now and the LLVM package will finally build 
on Debian without any additional tweaks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz accepted this revision.
glaubitz added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/Driver/sanitizer-ld.c:309
 // CHECK-UBSAN-LINUX: "-lpthread"
 
 // RUN: %clang -fsanitize=undefined -fno-sanitize-link-runtime %s -### -o %t.o 
2>&1 \

glaubitz wrote:
> hvdijk wrote:
> > glaubitz wrote:
> > > Do we need want to run the test for i386 anymore?
> > This test just somewhat arbitrarily distributes the different sanitizer 
> > modules over i386 and x86_64 for testing rather than testing each module 
> > for each arch, so I figured there was no harm in changing one of them to 
> > x86_64-linux-gnux32. i386 is still getting tested elsewhere.
> Do we _not_, not _need_. Sorry.
OK, thanks. Then I will mark this as approved from my side.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/test/Driver/sanitizer-ld.c:309
 // CHECK-UBSAN-LINUX: "-lpthread"
 
 // RUN: %clang -fsanitize=undefined -fno-sanitize-link-runtime %s -### -o %t.o 
2>&1 \

glaubitz wrote:
> Do we need want to run the test for i386 anymore?
Do we _not_, not _need_. Sorry.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/test/Driver/sanitizer-ld.c:309
 // CHECK-UBSAN-LINUX: "-lpthread"
 
 // RUN: %clang -fsanitize=undefined -fno-sanitize-link-runtime %s -### -o %t.o 
2>&1 \

Do we need want to run the test for i386 anymore?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Thanks, this finally fixes the build for me. I wasn't aware that there was a 
`getArchNameForCompilerRTLib()` function in clang.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100148/new/

https://reviews.llvm.org/D100148

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2663247 , @hvdijk wrote:

> In D52050#2663205 , @glaubitz wrote:
>
>> I think, however, we should bump the rest of the paths to 10.2.0 if possible.
>
> I updated all the Linux trees that were on 4.6.0. The only remaining 4.6.0 
> trees are for Hurd, which seems to me like it was just a coincidence that it 
> was on the same version. There are other Linux trees used for tests as well, 
> but they were already on different versions of GCC so we do not introduce any 
> new inconsistencies by leaving those as they are.
>
> I noticed that I left out one of the 4.6.0 directories by mistake in what I 
> put up for review, that did not affect test results. I included that as 
> obvious in what I pushed.

OK. Glad this has been fixed, in any case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2662656 , @hvdijk wrote:

> I have also updated the summary to provide a more complete explanation of the 
> changes, and hope the revised summary will answer @MaskRay's questions.



In D52050#2662648 , @hvdijk wrote:

> In D52050#2662570 , @glaubitz wrote:
>
>> Since I am a big fan of consistency, I would rather leave it as is (4.6) and 
>> then bump to 10.2.0 in a follow-up commit.
>
> You are right that including the bump in this commit would either force an 
> inconsistency with basic_linux_tree, multilib_32bit_linux_tree, and 
> multilib_64bit_linux_tree, or include more changes in here that are not 
> related to x32. However, since we have been testing for x32 support against a 
> pretend installation of GCC 4.6, and GCC 4.6 actually never supported x32 
> (initial support was added in GCC 4.7), leaving it at 4.6.0 means we are 
> testing an impossible scenario. I am aware that we already were doing that 
> before as well, but I do not think that changes much. Personally, I am not 
> very happy with any of the options here.

I was actually wondering which version of GCC introduced x32 support after I 
posted that comment. You're right then, 4.6.0 makes no sense.

I think, however, we should bump the rest of the paths to 10.2.0 if possible.

> I am also a fan of consistency, so to me the least bad option seems to be to 
> update all four at the same time, provided this does not result in an 
> excessively large diff. It looks large-ish but not too bad to me; I will 
> include it in the next update so that we know what sort of size we are 
> dealing with. If you and @MaskRay think it is too large I can easily take it 
> out again.
>
>> Debian actually has a /libx32 folder, but it contains the dynamic loader 
>> only which makes sense because the path to the dynamic loader is baked into 
>> the executable if I remember correctly.
>
> Right, it has a /libx32 directory for exactly that reason. 
> /libx32/ld-linux-x32.so.2 only exists as a compatibility symlink though, the 
> dynamic loader is really stored in /lib/x86_64-linux-gnux32.

Yep, it's just a link - as for the other architectures in Debian as well.

Either way, I'm glad this has finally been approved.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110
+  static const char *const X32Triples[] = {"x86_64-linux-gnux32",
+   "x86_64-unknown-linux-gnux32",
+   "x86_64-pc-linux-gnux32"};

hvdijk wrote:
> MaskRay wrote:
> > Personally I'd defer adding a triplet until it is proven to be used on a 
> > system.
> > 
> > This is not free, for every x86-64 user (even if they don't use multilib or 
> > x32), their clang driver runs need to stat the directory under lib/gcc or 
> > lib/gcc-cross.
> For the first and last I know for a fact they are used as the GCC triple; 
> /usr/lib/gcc/x86_64-linux-gnux32 and /usr/lib/gcc/x86_64-pc-linux-gnux32 
> definitely both exist in the wild. For the middle, 
> x86_64-unknown-linux-gnux32, I do know for a fact this is used as a triple 
> (it is the only valid x32 triple for Rust), but it is possible it is not used 
> as the GCC triple anywhere, so unless someone speaks up that this is already 
> in use somewhere, I will take that one out.
Isn't Rust going to use `x86_64-unknown-linux-gnux32` when invoking the C++ 
compiler itself? I would prefer keeping it for consistency with x86_64 and to 
avoid issues with distributions that may use that triplet.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2662440 , @hvdijk wrote:

> In D52050#2662372 , @MaskRay wrote:
>
>> Mostly looks good.
>>
>>> `clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o`
>>
>> Worth bumping the version. 4.6 is quite old and as a host compiler 
>> llvm-project has stopped supporting it. The distributions having 4.6 are all 
>> end-of-life.
>> Using a new version (matching your reality) can give impression that the 
>> user who contributed the original code may still need it for a while (say 5 
>> years).
>
> Sure, there should be no harm in renaming 4.6.0 to the current version, 
> 10.2.0, will do that and re-test.

Since I am a big fan of consistency, I would rather leave it as is (4.6) and 
then bump to 10.2.0 in a follow-up commit.

>> I still don't quite understand this. Shouldn't a native x32 port use 
>> `x86_64-unknown-linux-gnux32`? Why does it use the multilib style `/x32` 
>> suffix?
>
> Apologies for the confusion, that is my fault. @glaubitz opened this change 
> to make things work for Debian, which uses `lib/x86_64-linux-gnux32`, but I 
> am testing both Debian and non-Debian. Non-Debian uses `libx32`, similarly to 
> how x86_64-linux-gnu uses `lib64` regardless of whether any 32-bit libraries 
> are installed. (Edit: I may have misunderstood your comment. There's also the 
> `/x32` subdirectory inside GCC installs, but these are not used for native 
> x32 systems. This is only used for i*86-linux-gnu and x86_64-linux-gnu 
> compilers with multilib support for x32, both on Debian and on non-Debian 
> systems, and is covered by existing tests.)

Debian actually has a /libx32 folder, but it contains the dynamic loader only 
which makes sense because the path to the dynamic loader is baked into the 
executable if I remember correctly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2660022 , @hvdijk wrote:

> I think the problem is actually the other thing covered before (don't provide 
> un-normalised triples as cmake arguments), though the wrong detection of 
> LLVM_HOST_TRIPLE will cause other issues too. If we would just update 
> config.guess, the default configuration (not specifying either 
> LLVM_HOST_TRIPLE or LLVM_DEFAULT_TARGET_TRIPLE) should work much better; I 
> have created D99625  for that.

Updating `config.guess` fixes the problem for me. Feel free to update the diff 
here with your suggested patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2659654 , @hvdijk wrote:

> I am testing the below, on top of c8e56f394af0b9e32c413d62a0e7aebbba3e6b70 
> , both 
> in a Debian chroot and in my non-Debian system. Initial testing in the Debian 
> chroot suggests that this works for simple cases, clang has no problem 
> finding /usr/lib/gcc/x86_64-linux-gnux32/10, and also picks up the right 
> crt*.o files when using -m32 or -m64. Will do more extensive testing.
>
>   

It does not work for me, unfortunately:

  -- Check for working C compiler: 
/glaubitz/llvm-project/stage1.install/bin/clang - broken
  CMake Error at /usr/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 
(message):
The C compiler
  
  "/glaubitz/llvm-project/stage1.install/bin/clang"
  
is not able to compile a simple test program.
  
It fails with the following output:
  
  Change Dir: /glaubitz/llvm-project/build/CMakeFiles/CMakeTmp
  
  Run Build Command(s):/usr/bin/ninja cmTC_52475 && [1/2] Building C object 
CMakeFiles/cmTC_52475.dir/testCCompiler.c.o
  [2/2] Linking C executable cmTC_52475
  FAILED: cmTC_52475 
  : && /glaubitz/llvm-project/stage1.install/bin/clang   
CMakeFiles/cmTC_52475.dir/testCCompiler.c.o -o cmTC_52475   && :
  /usr/bin/x86_64-linux-gnux32-ld: cannot find crt1.o: No such file or 
directory
  /usr/bin/x86_64-linux-gnux32-ld: cannot find crti.o: No such file or 
directory
  clang-13: error: linker command failed with exit code 1 (use -v to see 
invocation)
  ninja: build stopped: subcommand failed.
  
  
  

  
CMake will not be able to correctly generate this project.
  Call Stack (most recent call first):
CMakeLists.txt:38 (project)
  
  
  -- Configuring incomplete, errors occurred!

Stage1 built with:

  cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=Release 
-DLLVM_ENABLE_ASSERTIONS=True -DLLVM_ENABLE_BINDINGS=OFF -DLLVM_LIT_ARGS="-v" 
-DCMAKE_INSTALL_PREFIX=../stage1.install -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_PARALLEL_LINK_JOBS=4 -DLLVM_TARGETS_TO_BUILD=X86 
-DLLVM_ENABLE_PROJECTS="clang-tools-extra;llvm;compiler-rt;clang" 
-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnux32  ; ninja -v ; ninja install

Stage 2 configured with:

  cmake -G Ninja ../llvm 
-DCMAKE_C_COMPILER=/glaubitz/llvm-project/stage1.install/bin/clang 
-DCMAKE_CXX_COMPILER=/glaubitz/llvm-project/stage1.install/bin/clang++ 
-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=True -DLLVM_LIT_ARGS="-v" 
-DCMAKE_INSTALL_PREFIX=../stage2.install -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_PARALLEL_LINK_JOBS=4 -DLLVM_TARGETS_TO_BUILD=X86 
-DLLVM_ENABLE_PROJECTS="clang-tools-extra;llvm;compiler-rt;clang"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D98574#2654686 , @joerg wrote:

> The NetBSD part looks ok, but also lacks proper testing. I'm not sure anyone 
> but Linux cares at all otherwise as they lack 32bit SPARC support.

Well, there were no tests for NetBSD before, so I didn't change anything in 
this regard. I only changed clang to behave as gcc on SPARC and I
think that's the reasonable thing to do to avoid any compatibility issues when 
building with clang instead of gcc on any SPARC target.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2657952 , @hvdijk wrote:

> I may be missing something, but I do not understand the problem. What 
> systems, other than Debian multi-arch, are you looking to also add support 
> for? My own native x32 system uses `(/usr)/libx32` for x32 libraries. Debian 
> uses `(/usr)/lib/x86_64-linux-gnux32`. I can understand if some people might 
> use `(/usr)/lib` without any `x32` suffix, though I am not aware of anyone 
> doing this. Where does `lib32` come from, though? What other systems are you 
> trying to account for?

I have tried all kinds of variants of this patch on Debian x32 with MultiArch 
and can't get it to work because it uses the wrong search-paths for the 
libraries.
I am still convinced the problem is that LLVM does not understand `x32` as a 
real distinct architecture unlike `i386` which is why we cannot apply the same
logic for `x32` and `i386`.

When the compiler tests `TargetEnvironment == llvm::Triple::GNUX32`, it does 
not know whether it's in a native `x32` environment or just on an `x86_64`
system where the target triplet is set to `x86_64-linux-gnux32` and I think 
that's the problem.

> I may have some spare time soon, I can take a look and do some testing as 
> well.

If you have a working fix for Debian x32, I would be happy to see it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 334071.
glaubitz retitled this revision from "[Driver] Fix architecture triplets and 
search paths for Linux x32" to "WIP: [Driver] Fix architecture triplets and 
search paths for Linux x32".
glaubitz added a comment.

Updated version which unfortunately still fails.

One of the problems is that I don't know how to detect a native x32 system
in getOSLibDir() in clang/lib/Driver/ToolChains/Linux.cpp.

On a native x32 system, libraries are not in /libx32.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -87,6 +87,8 @@
   case llvm::Triple::x86_64:
 if (IsAndroid)
   return "x86_64-linux-android";
+if (D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))
+  return "x86_64-linux-gnux32";
 // We don't want this for x32, otherwise it will match x86_64 libs
 if (TargetEnvironment != llvm::Triple::GNUX32 &&
 D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnu"))
@@ -210,7 +212,10 @@
 
   if (Triple.getArch() == llvm::Triple::x86_64 &&
   Triple.getEnvironment() == llvm::Triple::GNUX32)
-return "libx32";
+if (getDriver().getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))
+  return "lib32";
+else
+  return "libx32";
 
   if (Triple.getArch() == llvm::Triple::riscv32)
 return "lib32";
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2105,8 +2105,10 @@
   "x86_64-redhat-linux","x86_64-suse-linux",
   "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
   "x86_64-slackware-linux", "x86_64-unknown-linux",
-  "x86_64-amazon-linux","x86_64-linux-android"};
-  static const char *const X32LibDirs[] = {"/libx32"};
+  "x86_64-amazon-linux","x86_64-linux-android",
+  "x86_64-linux-gnux32","x86_64-unknown-linux-gnux32",
+  "x86_64-pc-linux-gnux32"};
+  static const char *const X32LibDirs[] = {"/libx32", "/lib"};
   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
   static const char *const X86Triples[] = {
   "i686-linux-gnu","i686-pc-linux-gnu",  "i386-redhat-linux6E",


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -87,6 +87,8 @@
   case llvm::Triple::x86_64:
 if (IsAndroid)
   return "x86_64-linux-android";
+if (D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))
+  return "x86_64-linux-gnux32";
 // We don't want this for x32, otherwise it will match x86_64 libs
 if (TargetEnvironment != llvm::Triple::GNUX32 &&
 D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnu"))
@@ -210,7 +212,10 @@
 
   if (Triple.getArch() == llvm::Triple::x86_64 &&
   Triple.getEnvironment() == llvm::Triple::GNUX32)
-return "libx32";
+if (getDriver().getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))
+  return "lib32";
+else
+  return "libx32";
 
   if (Triple.getArch() == llvm::Triple::riscv32)
 return "lib32";
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2105,8 +2105,10 @@
   "x86_64-redhat-linux","x86_64-suse-linux",
   "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
   "x86_64-slackware-linux", "x86_64-unknown-linux",
-  "x86_64-amazon-linux","x86_64-linux-android"};
-  static const char *const X32LibDirs[] = {"/libx32"};
+  "x86_64-amazon-linux","x86_64-linux-android",
+  "x86_64-linux-gnux32","x86_64-unknown-linux-gnux32",
+  "x86_64-pc-linux-gnux32"};
+  static const char *const X32LibDirs[] = {"/libx32", "/lib"};
   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
   static const char *const X86Triples[] = {
   "i686-linux-gnu","i686-pc-linux-gnu",  "i386-redhat-linux6E",
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Driver/ToolChains/Linux.cpp:90
   return "x86_64-linux-android";
-// We don't want this for x32, otherwise it will match x86_64 libs
-if (TargetEnvironment != llvm::Triple::GNUX32 &&
-D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnu"))
-  return "x86_64-linux-gnu";
+if (TargetEnvironment == llvm::Triple::GNUX32) {
+  if (D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))

MaskRay wrote:
> I have cleaned up the code a bit. You may need to rebase.
Yeah, I have done that but not uploaded my latest diff yet (which doesn't work 
on x32, unfortunately). I will do that now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Gentle ping.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz marked an inline comment as done.
glaubitz added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");

glaubitz wrote:
> ro wrote:
> > glaubitz wrote:
> > > jrtc27 wrote:
> > > > This doesn't need changing, we can define more things than GCC to keep 
> > > > it simple.
> > > Well, my original intent was to match GCC to make sure we're 100% 
> > > compatible and I would like to keep it that way.
> > I agree with Jessica here: you're creating a complicated maze for no real 
> > gain.  Besides, have you checked what `gcc` on the BSDs really does?  They 
> > often neglect to get their changes upstream and what's in the gcc repo 
> > doesn't necessarily represent what they actually use.
> Yes, I have verified that GCC behaves the exact same way as this change and I 
> don't see any reason not to mimic the exact same behavior in clang for 
> maximum compatibility.
FWIW, I meant GCC on the various BSDs. I do not think it's a wise idea to have 
clang deviate from what GCC does as only this way we can guarantee that 
everything that compiles with GCC will compile with clang.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz marked an inline comment as done.
glaubitz added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");

ro wrote:
> glaubitz wrote:
> > jrtc27 wrote:
> > > This doesn't need changing, we can define more things than GCC to keep it 
> > > simple.
> > Well, my original intent was to match GCC to make sure we're 100% 
> > compatible and I would like to keep it that way.
> I agree with Jessica here: you're creating a complicated maze for no real 
> gain.  Besides, have you checked what `gcc` on the BSDs really does?  They 
> often neglect to get their changes upstream and what's in the gcc repo 
> doesn't necessarily represent what they actually use.
Yes, I have verified that GCC behaves the exact same way as this change and I 
don't see any reason not to mimic the exact same behavior in clang for maximum 
compatibility.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Hmm, there recently were quite some changes in the MultiArch and GCC search 
path functionality in the Driver and I can unfortunately no longer get it to 
work on x32.

I had a relatively simple approach but I cannot get it to add the path for the 
crt.o objects and so on. It's always searching in the wrong paths.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Updated as I previously forgot to account for FreeBSD as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 332567.
glaubitz edited the summary of this revision.
Herald added subscribers: arichardson, emaste.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3557,12 +3552,10 @@
 // RUN: -target sparcv9-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
@@ -239,13 +237,25 @@
 void SparcV9TargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
-  // Solaris doesn't need these variants, but the BSDs do.
-  if (getTriple().getOS() != llvm::Triple::Solaris) {
+  switch (getTriple().getOS()) {
+  case llvm::Triple::Linux:
+Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::FreeBSD:
+  case llvm::Triple::NetBSD:
 Builder.defineMacro("__sparc64__");
 Builder.defineMacro("__sparc_v9__");
+Builder.defineMacro("__sparcv9");
+break;
+  case llvm::Triple::OpenBSD:
+Builder.defineMacro("__sparc64__");
 Builder.defineMacro("__sparcv9__");
+Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::Solaris:
+Builder.defineMacro("__sparcv9");
+break;
   }
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3557,12 +3552,10 @@
 // RUN: -target sparcv9-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: 

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 332380.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3557,12 +3552,10 @@
 // RUN: -target sparcv9-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
@@ -239,13 +237,24 @@
 void SparcV9TargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
-  // Solaris doesn't need these variants, but the BSDs do.
-  if (getTriple().getOS() != llvm::Triple::Solaris) {
+  switch (getTriple().getOS()) {
+  case llvm::Triple::Linux:
+Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::NetBSD:
+Builder.defineMacro("__sparcv9");
 Builder.defineMacro("__sparc64__");
 Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::OpenBSD:
+Builder.defineMacro("__sparc64__");
 Builder.defineMacro("__sparcv9__");
+Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::Solaris:
+Builder.defineMacro("__sparcv9");
+break;
   }
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3557,12 +3552,10 @@
 // RUN: -target sparcv9-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- 

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

I have updated the patch now with the result that clang should behave as GCC 
now on Linux, NetBSD and OpenBSD.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 332339.
glaubitz edited the summary of this revision.
Herald added a subscriber: krytarowski.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3558,11 +3553,9 @@
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
@@ -239,13 +237,24 @@
 void SparcV9TargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
-  // Solaris doesn't need these variants, but the BSDs do.
-  if (getTriple().getOS() != llvm::Triple::Solaris) {
+  switch (getTriple().getOS()) {
+  case llvm::Triple::Linux:
+Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::NetBSD:
+Builder.defineMacro("__sparcv9");
 Builder.defineMacro("__sparc64__");
 Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::OpenBSD:
+Builder.defineMacro("__sparc64__");
 Builder.defineMacro("__sparcv9__");
+Builder.defineMacro("__sparc_v9__");
+break;
+  case llvm::Triple::Solaris:
+Builder.defineMacro("__sparcv9");
+break;
   }
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3558,11 +3553,9 @@
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ 

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

For reference, here is what GCC defines on Linux with regards to SPARC:

  glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m32 - |grep arch
  glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m32 - |grep LP
  glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m32 - |grep v9
  #define __sparc_v9__ 1
  glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m64 - |grep arch
  #define __arch64__ 1
  glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m64 - |grep LP
  #define __LP64__ 1
  #define _LP64 1
  glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m64 - |grep v9
  #define __sparc_v9__ 1
  glaubitz@gcc202:~$

And here is what it defines on OpenBSD:

  openbsd# echo | gcc -E -dM -mcpu=v9 -m64 - |grep arch 
  #define __arch64__ 1
  openbsd# echo | gcc -E -dM -mcpu=v9 -m64 - |grep LP   
  #define __LP64__ 1
  #define _LP64 1
  openbsd# echo | gcc -E -dM -mcpu=v9 -m64 - |grep sparc
  #define sparc 1
  #define __sparc__ 1
  #define __sparc 1
  #define __sparc64__ 1
  #define __sparcv9__ 1
  #define __sparc_v9__ 1
  openbsd#



  -m32``` is not supported on OpenBSD at all:

openbsd# echo | gcc -E -dM -m32 -
:0: error: -m32 is not supported by this configuration
openbsd#

  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 332320.
glaubitz edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3558,11 +3553,9 @@
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
@@ -239,13 +237,17 @@
 void SparcV9TargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
-  // Solaris doesn't need these variants, but the BSDs do.
-  if (getTriple().getOS() != llvm::Triple::Solaris) {
-Builder.defineMacro("__sparc64__");
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");
+  Builder.defineMacro("__sparc_v9__");
+  Builder.defineMacro("__sparcv9__");
+}
   }
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3558,11 +3553,9 @@
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 332312.
glaubitz retitled this revision from "[Sparc] Define the same macros for 
-mcpu=v9 as GCC on Linux" to "[Sparc] Define the same macros for -mcpu=v9 as 
GCC on Linux  and the BSDs".
glaubitz edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp
  clang/test/Preprocessor/predefined-arch-macros.c


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3558,11 +3553,9 @@
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,8 +156,6 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
   break;
 }
@@ -239,13 +237,17 @@
 void SparcV9TargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
-  // Solaris doesn't need these variants, but the BSDs do.
-  if (getTriple().getOS() != llvm::Triple::Solaris) {
-Builder.defineMacro("__sparc64__");
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");
+  Builder.defineMacro("__sparc_v9__");
+  Builder.defineMacro("__sparcv9__");
+}
   }
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");


Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3457,11 +3457,8 @@
 // CHECK_SPARC: #define __BIG_ENDIAN__ 1
 // CHECK_SPARC: #define __sparc 1
 // CHECK_SPARC: #define __sparc__ 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
-// CHECK_SPARC-NOT: #define __sparcv9 1
-// CHECK_SPARC-NOT: #define __sparcv9__ 1
+// CHECK_SPARC-NOT: #define __sparc_v9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
@@ -3469,8 +3466,6 @@
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
 // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-sun-solaris \
@@ -3558,11 +3553,9 @@
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCV9
 // CHECK_SPARCV9: #define __BIG_ENDIAN__ 1
 // CHECK_SPARCV9: #define __sparc 1
-// CHECK_SPARCV9: #define __sparc64__ 1
+// CHECK_SPARCV9: #define __arch64__ 1
 // CHECK_SPARCV9: #define __sparc__ 1
 // CHECK_SPARCV9: #define __sparc_v9__ 1
-// CHECK_SPARCV9: #define __sparcv9 1
-// CHECK_SPARCV9: #define __sparcv9__ 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcv9-unknown-linux \
Index: clang/lib/Basic/Targets/Sparc.cpp

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D98574#2624558 , @brad wrote:

> I do not immediately see why the other tests are failing, but at a bare 
> minimum the following test from 
> clang/test/Preprocessor/predefined-arch-macros.c will have to be updated..
>
>   // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
>   // RUN: -target sparc-unknown-linux \
>   // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC-V9
>   // CHECK_SPARC-V9-NOT: #define __sparcv8 1
>   // CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
>   // CHECK_SPARC-V9: #define __sparc_v9__ 1
>   // CHECK_SPARC-V9: #define __sparcv9 1
>   // CHECK_SPARC-V9: #define __sparcv9__ 1

Thanks, I agree these need to be adjusted.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:160-164
+  // Linux doesn't need these variants, but the BSDs do.
+  if (getTriple().getOS() != llvm::Triple::Linux) {
+Builder.defineMacro("__sparcv9");
+Builder.defineMacro("__sparcv9__");
+  }

jrtc27 wrote:
> This is wrong, they should never be defined on any OS for 32-bit SPARC; see 
> https://github.com/gcc-mirror/gcc/blob/master/gcc/config/sparc/netbsd-elf.h#L22
>  for example (FreeBSD only ever had a 64-bit port so isn't interesting to 
> look at). That is, the contents of this `if` should just be deleted, leaving 
> just `__sparc_v9__`.
Agreed although I haven't verified whether ```__sparc_v9__``` is defined for 
NetBSD with ```-m32 -mcpu=v9```.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");

jrtc27 wrote:
> This doesn't need changing, we can define more things than GCC to keep it 
> simple.
Well, my original intent was to match GCC to make sure we're 100% compatible 
and I would like to keep it that way.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98574/new/

https://reviews.llvm.org/D98574

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz created this revision.
glaubitz added reviewers: jrtc27, ro, efriedma, brad, jfb, venkatra, jyknight.
Herald added a subscriber: fedor.sergeev.
glaubitz requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When targeting SPARC V8+ or V9 on Linux, GCC only defines the macro
__sparc_v9__ while clang also defines additional macros such as
__sparcv9 that are used on Solaris and the BSDs only. Make sure,
clang behaves as GCC on Linux and defines __sparc_v9__ only to avoid
compatibility problems.

  

Fixes PR49562


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98574

Files:
  clang/lib/Basic/Targets/Sparc.cpp


Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,9 +156,12 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
+  // Linux doesn't need these variants, but the BSDs do.
+  if (getTriple().getOS() != llvm::Triple::Linux) {
+Builder.defineMacro("__sparcv9");
+Builder.defineMacro("__sparcv9__");
+  }
   break;
 }
   }
@@ -239,13 +242,17 @@
 void SparcV9TargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
-  // Solaris doesn't need these variants, but the BSDs do.
-  if (getTriple().getOS() != llvm::Triple::Solaris) {
-Builder.defineMacro("__sparc64__");
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");
+  Builder.defineMacro("__sparc_v9__");
+  Builder.defineMacro("__sparcv9__");
+}
   }
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");


Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -156,9 +156,12 @@
   Builder.defineMacro("__sparcv8__");
   break;
 case CG_V9:
-  Builder.defineMacro("__sparcv9");
-  Builder.defineMacro("__sparcv9__");
   Builder.defineMacro("__sparc_v9__");
+  // Linux doesn't need these variants, but the BSDs do.
+  if (getTriple().getOS() != llvm::Triple::Linux) {
+Builder.defineMacro("__sparcv9");
+Builder.defineMacro("__sparcv9__");
+  }
   break;
 }
   }
@@ -239,13 +242,17 @@
 void SparcV9TargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
-  // Solaris doesn't need these variants, but the BSDs do.
-  if (getTriple().getOS() != llvm::Triple::Solaris) {
-Builder.defineMacro("__sparc64__");
+  if (getTriple().getOS() == llvm::Triple::Linux) {
 Builder.defineMacro("__sparc_v9__");
-Builder.defineMacro("__sparcv9__");
+  } else {
+Builder.defineMacro("__sparcv9");
+// Solaris doesn't need these variants, but the BSDs do.
+if (getTriple().getOS() != llvm::Triple::Solaris) {
+  Builder.defineMacro("__sparc64__");
+  Builder.defineMacro("__sparc_v9__");
+  Builder.defineMacro("__sparcv9__");
+}
   }
 
   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/test/Driver/m68k-sub-archs.cpp:1
+// RUN: %clang -### -target m68k-unknown-linux -mcpu=68000 %s 2>&1 | FileCheck 
--check-prefix=CHECK-MX00 %s
+// RUN: %clang -### -target m68k-unknown-linux -mcpu=m68000 %s 2>&1 | 
FileCheck --check-prefix=CHECK-MX00 %s

jrtc27 wrote:
> glaubitz wrote:
> > jrtc27 wrote:
> > > jrtc27 wrote:
> > > > Why MX00 etc?
> > > I think you misunderstood my comment. Having CHECK-A, CHECK-B, CHECK-C 
> > > etc is fine. My issue was with the MX00/MX10/MX20 suffix that makes no 
> > > sense to me; it's M68000/M68010/etc, X normally stands for a variable, 
> > > but the 0 is always constant. M00/M10/etc, M000/M010/etc and 
> > > M68000/M68010/M68020 would seem like more sensible names (also without 
> > > the M would be fine), but MX00 looks like it's trying to match 
> > > M000/M100/M200/etc, which is not the case.
> > From what I can see, I would say it's supposed to represent the "680" in 
> > "M68020", for example.
> Yeah, I just don't think it's particularly intuitive, especially when the 
> backend was originally intended to be called M680x0, the use of an X to stand 
> in for different things in very similar situations is confusing.
You're right, it's not very intuitive but I think it's not that important in my 
opinion.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88394/new/

https://reviews.llvm.org/D88394

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added inline comments.



Comment at: clang/test/Driver/m68k-sub-archs.cpp:1
+// RUN: %clang -### -target m68k-unknown-linux -mcpu=68000 %s 2>&1 | FileCheck 
--check-prefix=CHECK-MX00 %s
+// RUN: %clang -### -target m68k-unknown-linux -mcpu=m68000 %s 2>&1 | 
FileCheck --check-prefix=CHECK-MX00 %s

jrtc27 wrote:
> jrtc27 wrote:
> > Why MX00 etc?
> I think you misunderstood my comment. Having CHECK-A, CHECK-B, CHECK-C etc is 
> fine. My issue was with the MX00/MX10/MX20 suffix that makes no sense to me; 
> it's M68000/M68010/etc, X normally stands for a variable, but the 0 is always 
> constant. M00/M10/etc, M000/M010/etc and M68000/M68010/M68020 would seem like 
> more sensible names (also without the M would be fine), but MX00 looks like 
> it's trying to match M000/M100/M200/etc, which is not the case.
From what I can see, I would say it's supposed to represent the "680" in 
"M68020", for example.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88394/new/

https://reviews.llvm.org/D88394

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2576679 , @alsoijw wrote:

> In D52050#2369838 , @dschuff wrote:
>
>> One other question then: do you know if Debian and/or Ubuntu still have the 
>> same support for running x32 programs on the regular x86-64 distribution?
>
> I am not sure that I right understand reason of this question, but there is 
> gentoo x32 profile that allow execute all arch x86, x32, x64.

There are two ways to use x32. Either as a sub-architecture of x86_64 with 
x32-subfolders in /usr/lib/gcc/x86_64-linux-gnu/ (and so on) and as a separate, 
dedicated port.

Debian supports both and I am trying to fix the separate port with this patch.

I think I will resume working on this next week as I would like to finally get 
this fixed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2468424 , @jrtc27 wrote:

>> However, that's not the same as whether we're on an x86_64 system or on an 
>> x32 system determines which GNU triplet to use and which include and library 
>> search paths are our primary ones.
>
> But `Triple.getEnvironment()` will give you `llvm::Triple::GNUX32` that you 
> can check?

Yes, but we have to differentiate four scenarios:

- On x86_64, targeting x86_64
- On x86_64, targeting x32
- On x32, targeting x32
- On x32, targeting x86_64

On x86 it's clear because "x86" is an architecture on its own from clang's 
point of view. But that doesn't apply for x32 (at least for clang) and hence I 
don't know how to differentiate these four scenarios.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2441164 , @glaubitz wrote:

> In D52050#2441141 , @jrtc27 wrote:
>
>> What gets done currently for i386? That suffers potentially the same problem 
>> given both /usr/lib/gcc/x86_64-linux-gnu/$V/32 and 
>> /usr/lib/gcc/i386-linux-gnu/$V are possible locations for an i386 GCC 
>> toolchain.
>
> Very good suggestion. I will look into that tomorrow. Thanks for the pointer!

I have been wrapping my head around this for some time and I have run into one 
problem trying to apply the suggested approach.

The problem is that I don't know how to tell whether I'm on an x86_64 system or 
an x32 system there is no ```case llvm::Triple::x32:``` which would be needed 
here (we have it for x86).

x32 takes the switch case for x86_64, so x32 and x86_64 targeting x32 are 
identical.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2441141 , @jrtc27 wrote:

> What gets done currently for i386? That suffers potentially the same problem 
> given both /usr/lib/gcc/x86_64-linux-gnu/$V/32 and 
> /usr/lib/gcc/i386-linux-gnu/$V are possible locations for an i386 GCC 
> toolchain.

Very good suggestion. I will look into that tomorrow. Thanks for the pointer!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2441094 , @hvdijk wrote:

> I've been able to check what Ubuntu 20.10 offers in terms of x32 support. Its 
> kernel supports x32 binaries, it provides x32 versions of core system 
> libraries in separate packages (e.g. libc6-x32, libx32stdc++6, libx32z1), and 
> it provides a compiler that targets x32 by default (gcc-x86-64-linux-gnux32).

I did that, too. In fact, Ubuntu is ndentical to Debian in this regard as both 
the Ubuntu and the Debian gcc packages are maintained by the same maintainer 
(Matthias Klose whom I also happen to know personally) who first uploads these 
packages to Debian unstable, then syncs to Ubuntu.

However:

> These Ubuntu packages do not use the Debian/Ubuntu multiarch approach: the 
> packages are completely independent of the corresponding x64 and i386 
> versions with separate names, and nothing in Ubuntu installs any libraries 
> into any /lib/x86_64-linux-gnux32-like path. They are intended to allow x32 
> cross compilation on an Ubuntu system, not intended to act as a basis for 
> running an x32 Ubuntu system. This appears to be very different from Debian's 
> x32 support. That said, cross-compiled binaries do run on Ubuntu and it 
> should be possible to build an x32-native LLVM with the Ubuntu-provided 
> toolchain.

Well, Debian has both as - as I already mentioned - the gcc packages in Debian 
and Ubuntu are the same. The only difference is that Ubuntu does not provide an 
x32 port so there is no possibility to install Ubuntu x32 packages in the 
commonly known MultiArch manner.

Since MultiArch and the -cross packages are somewhat redundant, I'm not so sure 
yet which approach to address this issue would be best. I will talk to Matthias 
regarding this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2428743 , @hvdijk wrote:

> In D52050#2428735 , @glaubitz wrote:
>
>> Hmm, I was pretty sure that autoconf can deal with x32 inside an x32 chroot.
>
> Most autoconf-using software won't be dealing with a copy of `config.guess` 
> that was last updated in 2011. Updating that to a more recent version should 
> also work. :)

Ah, yes, that actually explains the problem :). Thanks a lot!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2428709 , @hvdijk wrote:

> `sys::getDefaultTargetTriple()` defaults to `LLVM_DEFAULT_TARGET_TRIPLE`, 
> which in turn defaults to `LLVM_HOST_TRIPLE`, which in turn defaults to 
> `LLVM_INFERRED_HOST_TRIPLE`, which calls `config.guess` which never 
> automatically detects X32. Sorry, forgot to mention that on my system, I also 
> make sure to explicitly specify `LLVM_HOST_TRIPLE` to an X32 triple when 
> building LLVM.

Hmm, I was pretty sure that autoconf can deal with x32 inside an x32 chroot.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

The problem seems to be that `LLVM_HOST_TRIPLE:STRING` is set to 
`x86_64-unknown-linux-gnu` instead of ``x86_64-unknown-linux-gnux32`.

I haven't found the place to fix that yet.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2428685 , @glaubitz wrote:

> I have not found the place yet in clang where to adjust that.

Maybe `sys::getDefaultTargetTriple()` needs to be adjusted. I'll have a look.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2428590 , @hvdijk wrote:

> That sounds like it's one thing in 
> https://lists.llvm.org/pipermail/llvm-dev/2020-October/146049.html I haven't 
> extracted into a separate patch for submission yet: LLVM does not call 
> `Triple::normalize` everywhere it should, and misinterprets 
> x86_64-linux-gnux32 as x86_64-somethingelse when it's set as the default 
> target because of it. For testing this change, it may be easiest to just 
> explicitly specify the triple or `-mx32`.

That doesn't help, unfortunately

The problem is that invoking `clang` on a Debian x32 defaults to `-m64` while 
it should default to `-mx32`. See my test run above.

I have not found the place yet in clang where to adjust that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

I stumbled over one problem with my patch which is that when I run an x32 
version of clang in a x32 environment, it will still default to "-m64" instead 
of "-mx32".

Thus:

  glaubitz@epyc:..llvm-project/build> ./bin/clang hello.c -o hello
  /usr/bin/ld: cannot find crtbegin.o: No such file or directory
  /usr/bin/ld: cannot find -lgcc
  /usr/bin/ld: cannot find -lgcc_s
  clang-12: error: linker command failed with exit code 1 (use -v to see 
invocation)
  glaubitz@epyc:..llvm-project/build> ./bin/clang -mx32 hello.c -o hello
  glaubitz@epyc:..llvm-project/build> file hello
  hello: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0, not stripped
  glaubitz@epyc:..llvm-project/build> file bin/clang-12
  bin/clang-12: ELF 32-bit LSB executable, x86-64, version 1 (GNU/Linux), 
dynamically linked, interpreter /libx32/ld-linux-x32.so.2, 
BuildID[sha1]=6175851930c1e79df16060c731ecda2f596ef05a, for GNU/Linux 3.4.0, 
not stripped
  glaubitz@epyc:..llvm-project/build>

Any idea how it could make clang default to `-mx32` if this condition is met: 
`getToolChain().getTriple().getEnvironment() == llvm::Triple::GNUX32`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Just as a heads-up, I haven't forgotten about this. Freeing up the server just 
takes a little longer as I need to backup files through a DSL line. Should be 
ready by tomorrow.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2423144 , @RKSimon wrote:

> Were you able to compare against GCC and also determine debian/ubuntu's 
> x86_64 current support for x32 executables?

Not yet. Currently freeing up space on my VM host so I can perform a fresh 
Ubuntu installation to make sure I have verified that Debian and Ubuntu don't 
deviate here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88712: [CGBuiltin] Respect asm labels and redefine_extname for builtins with specialized emitting

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Not sure if this is related, but on SPARC, stage2 builds recently started to 
fail with:

  [379/5552] Building CXX object 
projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan.sparc.dir/ubsan_diag.cpp.o
  FAILED: 
projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan.sparc.dir/ubsan_diag.cpp.o
  /home/glaubitz/llvm-project/build/./bin/clang++ -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Iprojects/compiler-rt/lib/ubsan 
-I/home/glaubitz/llvm-project/compiler-rt/lib/ubsan -Iinclude 
-I/home/glaubitz/llvm-project/llvm/include 
-I/home/glaubitz/llvm-project/compiler-rt/lib/ubsan/.. -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wsuggest-override -Wstring-conversion -fdiagnostics-color -Wall -std=c++14 
-Wno-unused-parameter -g  -m32 -fPIC -fno-builtin -fno-exceptions 
-fomit-frame-pointer -funwind-tables -fno-stack-protector 
-fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only 
-Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -nostdinc++ -fno-rtti 
-DUBSAN_CAN_USE_CXXABI -std=c++14 -MD -MT 
projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan.sparc.dir/ubsan_diag.cpp.o 
-MF 
projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan.sparc.dir/ubsan_diag.cpp.o.d 
-o projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan.sparc.dir/ubsan_diag.cpp.o 
-c /home/glaubitz/llvm-project/compiler-rt/lib/ubsan/ubsan_diag.cpp
  In file included from 
/home/glaubitz/llvm-project/compiler-rt/lib/ubsan/ubsan_diag.cpp:25:
  In file included from /usr/include/stdio.h:870:
  /usr/include/bits/stdio-ldbl.h:26:20: error: cannot apply asm label to 
function after its first use
  __LDBL_REDIR_DECL (vfprintf)
  ~~~^
  /usr/include/sys/cdefs.h:467:26: note: expanded from macro '__LDBL_REDIR_DECL'
extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
   ^   
  1 error generated.
  [412/5552] Building CXX object 
lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/MasmParser.cpp.o
  ninja: build stopped: subcommand failed.

See: http://lab.llvm.org:8014/#/builders/134


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88712/new/

https://reviews.llvm.org/D88712

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Yeah, @hvdijk has made multiple other improvements which should finally allow 
the backend to be usable.

We still disagree on the search paths for libraries and headers though if I 
remember correctly.

My goal is to make LLVM and Rust work on an full Debian x32 system which is why 
we need dedicated Multi-Arch search paths such as /usr/lib/x86_64-linux-gnux32/.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Thanks so much! Would you mind pushing that change for me? I don't have commit 
access at the moment.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

I changed it to 4.5 to be consisted with the other Multi-Arch tests for x86, 
MIPS and PowerPC. That's all.

Debian Multi-Arch on sparc/sparc64 behaves the exact same way as it does on 
mips*, powerpc* and x86, so I think it makes sense to use the exact same path 
patterns.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D90524#2393746 , @ro wrote:

> In D90524#2393651 , @glaubitz wrote:
>
>> 
>
>
>
>> Please feel free to reach out to the corresponding debian-$ARCH mailing list 
>> for such questions. Debian-specific layouts are not
>> necessarily obvious at first glance to people not very familiar with the 
>> distribution.
>
> I could have.  However, my only interest in Linux/SPARC was to have a 
> comparison point for my Solaris/SPARC work to determine which test failures 
> occur on all SPARC targets and which ones are Solaris-specific.  I simply 
> don't have to time to dig deeper into Linux issues.

No worries. I'm glad someone is taking care of the Solaris parts and appreciate 
fixes from other parties.

Please don't see my comments as dismissive in any way, they aren't meant that 
way. I appreciate the feedback.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

> ! In D90524#2393635 , @ro wrote:
>
> I had an extremely hard time researching the history of directory layouts for 
> my patch D85582 .  Do as you like, I'm out 
> of this.

Please feel free to reach out to the corresponding debian-$ARCH mailing list 
for such questions. Debian-specific layouts are not
necessarily obvious at first glance to people not very familiar with the 
distribution.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D90524#2393320 , @ro wrote:

> In D90524#2393312 , @glaubitz wrote:
>
>> Ping. It would be nice to get this finally merged so that the testsuite 
>> noise finally goes down on the sparc64 Linux worker.
>
> Please be a little more patient: one ping a week is considered appropriate, 
> but after only two days is a bit over the top.

The problem is that LLVM is a very fast moving target and when waiting long for 
changes to be merged, one constantly runs
into the risk of having to rebase patches.

I would like to move forward with other changes and having unmerged changes 
open takes away attention.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D90524#2393319 , @ro wrote:

> In D90524#2388214 , @glaubitz wrote:
>
>> I think it should be good for merging now. I addressed all remarks. I'm 
>> still convinced that "workaround" is the proper term though.
>
> Quite the contrary: the comment you cited
>
>   // FIXME: This is a bit of a hack. We should really unify this code for
>   // reasoning about oslibdir spellings with the lib dir spellings in the
>   // GCCInstallationDetector, but that is a more significant refactoring.
>
> pretty clearly is about how/where support for that layout is implemented in 
> the `clang` Driver code, not about the layout itself.

I don't understand that argument. I call it "workaround", the source comment 
calls it "hack". It's clearly not to stay forever as it's an ugly
workaround, but until a proper fix comes around, I would like to add "sparc" 
here as well so the testsuite failures drop from over
400 to just below 70.

> Besides, you haven't explained why it's appropriate to no longer test support 
> for the old (pre-Debian 9,I believe) directory layout.  However, as I said I 
> don't feel qualified to review that part, so you'll need another reviewer for 
> that, no matter if only testing the new layout or both old and new ones.

Debian 8 doesn't even support sparc as the port was dropped in this release:

> https://cdimage.debian.org/cdimage/archive/8.0.0/

The last sparc release was 7.11.0 and that's Wheezy which is long out of 
support:

> https://cdimage.debian.org/cdimage/archive/7.11.0/

And, as I said, MultiArch was and is the same for all architectures, including 
sparc/sparc64. It does not make sense to test sparc here differently than the 
other
Debian architectures. There is no special sparc configuration in Debian and I 
think I can make that statement as Debian's primary maintainer for the sparc64
port.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Ping. It would be nice to get this finally merged so that the testsuite noise 
finally goes down on the sparc64 Linux worker.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

I think it should be good for merging now. I addressed all remarks. I'm still 
convinced that "workaround" is the proper term though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 303846.
glaubitz edited the summary of this revision.
glaubitz added a comment.
Herald added subscribers: steven.zhang, jrtc27.

Update as requested in previous review, also merge with D90549 
.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

Files:
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/debian_8_sparc64_tree/lib/sparc64-linux-gnu/.keep
  clang/test/Driver/Inputs/debian_8_sparc64_tree/lib64/.keep
  clang/test/Driver/Inputs/debian_8_sparc64_tree/usr/include/c++/4.9/.keep
  
clang/test/Driver/Inputs/debian_8_sparc64_tree/usr/include/sparc64-linux-gnu/c++/4.9/.keep
  
clang/test/Driver/Inputs/debian_8_sparc64_tree/usr/lib/gcc/sparc64-linux-gnu/4.9/crtbegin.o
  
clang/test/Driver/Inputs/debian_8_sparc64_tree/usr/lib/gcc/sparc64-linux-gnu/4.9/crtend.o
  
clang/test/Driver/Inputs/debian_8_sparc64_tree/usr/lib/sparc64-linux-gnu/crt1.o
  
clang/test/Driver/Inputs/debian_8_sparc64_tree/usr/lib/sparc64-linux-gnu/crti.o
  
clang/test/Driver/Inputs/debian_8_sparc64_tree/usr/lib/sparc64-linux-gnu/crtn.o
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/lib/sparc-linux-gnu/.keep
  clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/lib64/.keep
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/include/c++/4.9/backward/.keep
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/include/sparc-linux-gnu/c++/4.9/64/.keep
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib/gcc/sparc-linux-gnu/4.9/64/crtbegin.o
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib/gcc/sparc-linux-gnu/4.9/64/crtend.o
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib/gcc/sparc-linux-gnu/4.9/crtbegin.o
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib/gcc/sparc-linux-gnu/4.9/crtend.o
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib/sparc-linux-gnu/crt1.o
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib/sparc-linux-gnu/crti.o
  
clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib/sparc-linux-gnu/crtn.o
  clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib64/crt1.o
  clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib64/crti.o
  clang/test/Driver/Inputs/debian_8_sparc_multilib_tree/usr/lib64/crtn.o
  clang/test/Driver/Inputs/debian_multiarch_tree/lib/sparc-linux-gnu/.keep
  clang/test/Driver/Inputs/debian_multiarch_tree/lib/sparc64-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/include/c++/4.5/sparc-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/include/c++/4.5/sparc64-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/include/sparc-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/include/sparc64-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/lib/gcc/sparc-linux-gnu/4.5/crtbegin.o
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/lib/gcc/sparc64-linux-gnu/4.5/crtbegin.o
  clang/test/Driver/Inputs/debian_multiarch_tree/usr/lib/sparc-linux-gnu/.keep
  clang/test/Driver/Inputs/debian_multiarch_tree/usr/lib/sparc64-linux-gnu/.keep
  clang/test/Driver/linux-header-search.cpp
  clang/test/Driver/linux-ld.c

Index: clang/test/Driver/linux-ld.c
===
--- clang/test/Driver/linux-ld.c
+++ clang/test/Driver/linux-ld.c
@@ -1282,67 +1282,32 @@
 // CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5/../../.."
 // CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/lib"
 // CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib"
-//
-// Check linker paths on Debian 8 / Sparc
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=sparc-linux-gnu -rtlib=platform \
 // RUN: --gcc-toolchain="" \
-// RUN: --sysroot=%S/Inputs/debian_8_sparc_multilib_tree \
-// RUN:   | FileCheck --check-prefix=CHECK-DEBIAN-SPARC32 %s
-// CHECK-DEBIAN-SPARC32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
-// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../sparc-linux-gnu{{/|}}crt1.o"
-// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../sparc-linux-gnu{{/|}}crti.o"
-// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9{{/|}}crtbegin.o"
-// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9"
-// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../sparc-linux-gnu"
-// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../lib"
-// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/lib/sparc-linux-gnu"
-// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/sparc-linux-gnu"
-// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/lib"
-// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib"
-// CHECK-DEBIAN-SPARC32: 

[PATCH] D90549: [Driver] Switch CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Merged into D90524 .


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90549/new/

https://reviews.llvm.org/D90549

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Hi Rainer!

Thanks for your review.

In D90524#2382555 , @ro wrote:

> As it happens, I'd arrived at exactly the same patch when I tried a build on 
> a Debian/sparc64 system in the GCC compile farm (gcc202), submitted as D85582 
> .
>
> A couple of questions/caveats:
>
> - I wouldn't call this patch a workaround, as you do in the summary: if 
> `clang` cannot find the 32-bit libs, it's broken and needs to be fixed.

I'm calling it a workaround because it's already called like that in the 
existing code comment (well, they call it "hack"):

> // FIXME: This is a bit of a hack. We should really unify this code for
> // reasoning about oslibdir spellings with the lib dir spellings in the
> // GCCInstallationDetector, but that is a more significant refactoring.



> - Please reformat `Linux.cpp` as the pre-merge check requested.

OK.

> - I'd be willing to accept this patch, but for one I'm not certain about LLVM 
> policy about who may or may not do so.
> - Besides, I believe it's a mistake to split the bug fix and the testsuite 
> change into to different patches.  More about that in D90549 
> .

OK.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90549: [Driver] Switch CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90549/new/

https://reviews.llvm.org/D90549

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90524/new/

https://reviews.llvm.org/D90524

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2369838 , @dschuff wrote:

> One other question then: do you know if Debian and/or Ubuntu still have the 
> same support for running x32 programs on the regular x86-64 distribution? 
> (presumably yes, since you aren't changing the existing behavior).
> AFAIK clang's current support was developed against Ubuntu, but I haven't 
> tried it in a long time and to my knowledge nobody has submitted any patches 
> for x32 in a while either.

I have seen the testsuite failures and I have to verify that. What I know is 
that Ubuntu 14.04, against this was tested, is no longer supported.

I have to admit that I don't fully understand yet why the tests fail. I will 
verify what GCC does but I assume we have to update the other tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz updated this revision to Diff 302404.
glaubitz added a comment.

Regenerated with more context (using git format-patch -W).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/debian_multiarch_tree/lib/x86_64-linux-gnux32/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/include/c++/4.5/x86_64-linux-gnux32/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/include/x86_64-linux-gnux32/.keep
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/lib/gcc/x86_64-linux-gnux32/4.5/crtbegin.o
  
clang/test/Driver/Inputs/debian_multiarch_tree/usr/lib/x86_64-linux-gnux32/.keep
  clang/test/Driver/linux-header-search.cpp
  clang/test/Driver/linux-ld.c

Index: clang/test/Driver/linux-ld.c
===
--- clang/test/Driver/linux-ld.c
+++ clang/test/Driver/linux-ld.c
@@ -1170,6 +1170,19 @@
 // CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/lib"
 // CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/usr/lib"
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-linux-gnux32 -rtlib=platform \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-DEBIAN-X32 %s
+// CHECK-DEBIAN-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-DEBIAN-X32: "{{.*}}/usr/lib/gcc/x86_64-linux-gnux32/4.5{{/|}}crtbegin.o"
+// CHECK-DEBIAN-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnux32/4.5"
+// CHECK-DEBIAN-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnux32/4.5/../../../x86_64-linux-gnux32"
+// CHECK-DEBIAN-X32: "-L[[SYSROOT]]/usr/lib/x86_64-linux-gnux32"
+// CHECK-DEBIAN-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnux32/4.5/../../.."
+// CHECK-DEBIAN-X32: "-L[[SYSROOT]]/lib"
+// CHECK-DEBIAN-X32: "-L[[SYSROOT]]/usr/lib"
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=powerpc-linux-gnu -rtlib=platform \
 // RUN: --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
Index: clang/test/Driver/linux-header-search.cpp
===
--- clang/test/Driver/linux-header-search.cpp
+++ clang/test/Driver/linux-header-search.cpp
@@ -224,7 +224,23 @@
 // CHECK-DEBIAN-X86-64: "-internal-isystem" "[[RESOURCE_DIR]]{{/|}}include"
 // CHECK-DEBIAN-X86-64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/x86_64-linux-gnu"
 // CHECK-DEBIAN-X86-64: "-internal-externc-isystem" "[[SYSROOT]]/include"
-// CHECK-DEBIAN-X86-64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
+// CHECK-DEBIAN-X86-64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
+// RUN: -target x86_64-linux-gnux32 -stdlib=libstdc++ \
+// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=CHECK-DEBIAN-X32 %s
+// CHECK-DEBIAN-X32: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
+// CHECK-DEBIAN-X32: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
+// CHECK-DEBIAN-X32: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-DEBIAN-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnux32/4.5/../../../../include/c++/4.5"
+// CHECK-DEBIAN-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnux32/4.5/../../../../include/c++/4.5/x86_64-linux-gnux32"
+// CHECK-DEBIAN-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnux32/4.5/../../../../include/c++/4.5/backward"
+// CHECK-DEBIAN-X32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
+// CHECK-DEBIAN-X32: "-internal-isystem" "[[RESOURCE_DIR]]{{/|}}include"
+// CHECK-DEBIAN-X32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/x86_64-linux-gnux32"
+// CHECK-DEBIAN-X32: "-internal-externc-isystem" "[[SYSROOT]]/include"
+// CHECK-DEBIAN-X32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
 // RUN: -target powerpc-linux-gnu -stdlib=libstdc++ \
 // RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -87,10 +87,13 @@
   case llvm::Triple::x86_64:
 if (IsAndroid)
   return "x86_64-linux-android";
-// We don't want this for x32, otherwise it will match x86_64 libs
-if (TargetEnvironment != llvm::Triple::GNUX32 &&
-D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnu"))
-  return "x86_64-linux-gnu";
+if (TargetEnvironment == llvm::Triple::GNUX32) {
+  if (D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))
+return "x86_64-linux-gnux32";
+} else {
+  if 

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D52050#2369581 , @dschuff wrote:

> Can you upload the diff with full context (e.g. use `diff -U ` or use 
> arcanist to upload)?
>
> I'm a bit confused; the commit message talks about X32 being a separate 
> architecture, but you're not adding any new architecture triples here (it 
> still uses x86_64 as the architecture and selects the ABI via the 
> environment). AFAICS what really changes is that the structure of the include 
> and lib directories is now multi-arch style with the x32 headers alongside 
> the x86_64 base headers?

Updated diff coming in a bit.

As for the term architecture: It's a separate architecture in Debian which can 
also mean just a different ABI. In Debian terms, an architecture can be a 
different ABI, different real architecture or different kernel.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D52050/new/

https://reviews.llvm.org/D52050

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits