[PATCH] D70157: Align branches within 32-Byte boundary

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In D70157#1776424 , @skan wrote:

> > What if I insert explicit align(8) right *after* the sequence?
>
> If your insert explicit `.align 8` after the sequence, and the sequence 
> doesn't has any branch to be aligned, the current solution won't change the 
> sequence.


Well, I kinda figure that from the code behavior right now, however is it 
really by design or just happens to work now?
Seeing that assembler becomes very intelligent now I would rather have a strict 
guarantee similar to "hardcode" thing that you have here that protects my 
sequence
rather than relying on a fact that in current settings moving my label by 8 
does not appear to be profitable to assembler.


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In D70157#1775016 , @annita.zhang 
wrote:

> > The point is that we have explicit requirement at the start and we have a 
> > lowering into 16-byte sequence that we need to be preserved exactly as it 
> > is.
> >  Essentially what we need is  a "protection" for this sequence from any 
> > changes by machinery that generates the binary code.
> >  How can we protect a particular byte sequence from being changed by this 
> > branch aligner?
>
> No, in general we can't. The current solution is based on assembler to insert 
> prefix or nop before the cross (or against) boundary branches. It can only 
> ensure the explicit alignment specified by directive, but not any implicit 
> alignment. I don't think any fixup based on assembler can do it. On the other 
> hand, any code sequence after the alignment directive or even just in a 
> function has some kind of implicit alignment. It's hard for assembler to tell 
> which implicit alignment to preserve. The preferred way is to use explicit 
> alignment directive to specify it.
>
> For your scenario, a NOP padding is more controllable. NOP padding will be 
> inserted just before the branch instructions (or macro fusion branch 
> instructions). So if there's no branches (or macro fusion branches) in your 
> code sequence, there will be no NOP inserted.


What if I insert explicit align(8) right *after* the sequence?


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In D70157#1774561 , @skan wrote:

> I could not reproduce the phenomenon that N-byte nop becomes (N+M) bytes with 
> your example. So according to my understanding, I slightly modified your 
> case. (If my understand is wrong, I hope you can point it out :-). )
>
>   .text
>   nop
>   .Ltmp0:
>   .p2align 3, 0x90
>   .rept 16
>   nop
>   .endr
>   .Ltmp3:
>   movl  %eax, -4(%rsp)


In our case it was

  andl $1, %eax

but it does not matter that much.

>   .rept 2
>   nop
>   .endr
>   jmp .Ltmp0
> 
>   The instruction `jmp .Ltmp0` starts at byte 0x1e and ends at byte 0x20.

Again, in our particular case start of the sequence was at xxx8, so 8 + 16(our 
sequence) + 3(andl) + 5(jmp) == 32.

> If we align the jump with preifx, two prefixes will be added to the `.rept2 
> 16 nop .endr`. After prefixes are added, the 16-byte nop becomes 18-byte nop, 
> then the label '.Ltmp3' is not 8-byte aligned any more.

Yes, thats what happened.

> I doubt whether the assumption that '.Ltmp3' is 8-byte aligned is right, 
> since the alignment is not explicitly required.

The point is that we have explicit requirement at the start and we have a 
lowering into 16-byte sequence that we need to be preserved exactly as it is.
Essentially what we need is  a "protection" for this sequence from any changes 
by machinery that generates the binary code.
How can we protect a particular byte sequence from being changed by this branch 
aligner?


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In D70157#1768310 , @skan wrote:

> fix the bug
>
> https://bugs.llvm.org/show_bug.cgi?id=44215


FYI: I did close the bug as fixed after verifying that the fix works for me.


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev requested changes to this revision.
fedor.sergeev added a comment.
This revision now requires changes to proceed.

In D70157#1767212 , @fedor.sergeev 
wrote:

> Working on getting upstream reproducer


Hangs on a moderately small piece  (~150 lines) of x86 assembly, filed a bug on 
it here:

https://bugs.llvm.org/show_bug.cgi?id=44215


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

Just FYI for now as I'm trying to dig futher...
I have been trying this fix in our downstream environment and managed to get a 
hang with this backtrace:

#0 needPadding (BoundarySize=, Size=, 
StartAddr=) at ./llvm/lib/MC/MCAssembler.cpp:1028
#1 llvm::MCAssembler::relaxMachineDependent (this=, Layout=..., 
MF=...) at ./llvm/lib/MC/MCAssembler.cpp:1077
#2 0x71adc8b6 in llvm::MCAssembler::layoutSectionOnce 
(this=this@entry=0x7fff90580580, Layout=..., Sec=...) at 
./orca/llvm/lib/MC/MCAssembler.cpp:1213
...

Working on getting upstream reproducer


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

https://reviews.llvm.org/D70157



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

[PATCH] D65975: [NewPM][PassInstrumentation] IR printing support from clang driver

[Fedor Sergeev via Phabricator via cfe-commits]

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

LGTM.
Thanks for addressing this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65975



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

[PATCH] D65975: [NewPM][PassInstrumentation] IR printing support from clang driver

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In D65975#1621892 , @twoh wrote:

> @fedor.sergeev @yamauchi I saw your discussions over llvm-dev mailing list 
> regarding IR printing with the new pass manager, and though this might be the 
> reason why IR printing is not supported under new PM with clang. I would 
> appreciate if you can take a look.


Yep, you are right, standard instrumentation needs to be passed into 
PassBuilder for printing and time-passes to work.
Main changes are fine, just a small note on the test below.




Comment at: clang/test/Misc/printer.c:1
+// RUN: %clang_cc1 -emit-llvm -O2 -fexperimental-new-pass-manager -mllvm 
-print-before-all %s -o %t 2>&1 | FileCheck %s --check-prefix=CHECK-BEFORE
+// RUN: %clang_cc1 -emit-llvm -O2 -fexperimental-new-pass-manager -mllvm 
-print-after-all %s -o %t 2>&1 | FileCheck %s --check-prefix=CHECK-AFTER

Can this test avoid using -O2 and check for some generic always-present pass 
like ModuleVerifier?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65975



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

[PATCH] D57835: Fix -ftime-report with -x ir

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev requested changes to this revision.
fedor.sergeev added a comment.
This revision now requires changes to proceed.

just to make the comments visible :)


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

https://reviews.llvm.org/D57835



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

[PATCH] D57835: Fix -ftime-report with -x ir

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added inline comments.



Comment at: test/Frontend/ftime-report-bitcode.ll:1
+; RUN: %clang_cc1 -triple x86_64-apple-darwin10 -ftime-report -emit-obj -o 
/dev/null %s 2>&1 | FileCheck %s
+

Can you, please, test -fexperimental-new-pass-manager mode as well?
Implementation of time-passes is different between legacy and newpm.


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

https://reviews.llvm.org/D57835



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

[PATCH] D57835: Fix -ftime-report with -x ir

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In D57835#1387622 , @arsenm wrote:

> I partially solved the problem with double printing the reports.  It's from 
> this in cc1_main:
>
>   // If any timers were active but haven't been destroyed yet, print theirp
>   // results now.  This happens in -disable-free mode.
>   llvm::TimerGroup::printAll(llvm::errs());
>   
>
> On a source file, -ftime-report  -disable-free prints one report. 
> -ftime-report without disable-free prints 2. For the IR file, both happen 
> either way and it double prints. The printing destructor can still be called 
> from the ManagedStatic in PassTimingInfo


I dont quite understand what clang is doing in terms of timers (and what 
-disable-free is/how does it interact with -ftime-report).
However if after doing printAll() you expect that there wont be any other 
reports then you should call clearAll() immediately after.


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

https://reviews.llvm.org/D57835



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

[PATCH] D57265: [PM/CC1] Add -f[no-]split-cold-code CC1 options to toggle splitting

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In D57265#1393453 , @vsk wrote:

> > I'd prefer not adding this kind of state to PassBuilder. SplitColdCode is 
> > soemthing that refers to the construction of one particular pipeline, not 
> > to pipeline-building in general. It should be an argument passed down 
> > through the build*Pipeline calls.
>
> I'm not sure I understand the distinction being made here -- could you 
> elaborate? Isn't enabling a pass related to pipeline-building in general? If 
> not, I don't see how arguments to build*Pipeline //do// become related to 
> pipeline-building in general.
>
> For context, I've modeled the addition of the SplitColdCode member to 
> PassBuilder on PGOOpt (c.f. PGOOptions::RunProfileGen). One thing I like 
> about this approach is that it doesn't require changing IR, or changing very 
> many different APIs. But if it's really not reasonable, I'm happy to take 
> another shot at it.


I cant say for PGOOpt in particular, but overall idea of PassBuilder is that, 
well, it is not "builder" as per "builder pattern".
You do not fill it with parts of a complex pipeline object and then press a 
magical "build" button.
Instead you ask it to build various "named" pipelines, or just parse it from 
text.
If you compare with PassManagerBuilder, which contains a dozen of various data 
members that seem to drive the pipeline construction,
PassBuilder contains only a few. And the purpose of PassBuilder members is to 
be used during individual *pass*es creation.

Say, you wont find OptLevel there. Instead it is being passed as an argument to 
build*Pipeline functions.

As for PGOOpts - it seems to be the only member that stands out.
And to me it looks like we should remove it from PassBuilder either, and start 
passing it to build*Pipeline functions as well.
But honestly, this is the first time I really looked through the PGOOpts code, 
so I might be well mistaken.


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

https://reviews.llvm.org/D57265



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

[PATCH] D52814: [PassManager/Sanitizer] Enable usage of ported AddressSanitizer passes with -fsanitize=address

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev accepted this revision.
fedor.sergeev added a comment.

LGTM.


Repository:
  rC Clang

https://reviews.llvm.org/D52814



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

[PATCH] D52814: [PassManager/Sanitizer] Enable usage of ported AddressSanitizer passes with -fsanitize=address

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added inline comments.



Comment at: lib/CodeGen/BackendUtil.cpp:1031-1038
+  MPM.addPass(AddressSanitizerModulePass());
+
+  // Add Function Pass
+  CGSCCPassManager MainCGPipeline(CodeGenOpts.DebugPassManager);
+  MainCGPipeline.addPass(createCGSCCToFunctionPassAdaptor(
+  buildAddressSanitizerPipeline(CodeGenOpts.DebugPassManager)));
+  MPM.addPass(

I dont believe CGSCC is appropriate here.

I would expect to see a simple ModuleToFunction adapter, something like this:

MPM.addPass(AddressSanitizerModulePass());
MPM.addPass(createModuleToFunctionPassAdaptor(AddressSanitizerFunctionPass())

Also, it seems that legacy runs Function sanitizer first and then Module 
sanitizer after it.
This sequence does it backwards. Is it intentional?


Repository:
  rC Clang

https://reviews.llvm.org/D52814



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

[PATCH] D41241: [Solaris] Only define _REENTRANT if -pthread

[Fedor Sergeev via Phabricator via cfe-commits]

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

LGTM


Repository:
  rC Clang

https://reviews.llvm.org/D41241



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

[PATCH] D41240: [Solaris] __float128 is supported on Solaris/x86

[Fedor Sergeev via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rC Clang

https://reviews.llvm.org/D41240



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

[PATCH] D41242: [Solaris] Silence -pthread warning on Solaris

[Fedor Sergeev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC324344: [Solaris] Silence -pthread warning on Solaris 
(authored by fedor.sergeev, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D41242

Files:
  lib/Driver/ToolChains/Solaris.cpp


Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -71,6 +71,11 @@
   CmdArgs.push_back(
   Args.MakeArgString(getToolChain().GetFilePath("ld.so.1")));
 }
+
+// libpthread has been folded into libc since Solaris 10, no need to do
+// anything for pthreads. Claim argument to avoid warning.
+Args.ClaimAllArgs(options::OPT_pthread);
+Args.ClaimAllArgs(options::OPT_pthreads);
   }
 
   if (Output.isFilename()) {


Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -71,6 +71,11 @@
   CmdArgs.push_back(
   Args.MakeArgString(getToolChain().GetFilePath("ld.so.1")));
 }
+
+// libpthread has been folded into libc since Solaris 10, no need to do
+// anything for pthreads. Claim argument to avoid warning.
+Args.ClaimAllArgs(options::OPT_pthread);
+Args.ClaimAllArgs(options::OPT_pthreads);
   }
 
   if (Output.isFilename()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL323193: [Solaris] gcc toolchain handling revamp (authored by 
fedor.sergeev, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D35755?vs=110194=131043#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D35755

Files:
  cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
  cfe/trunk/lib/Driver/ToolChains/Gnu.h
  cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
  cfe/trunk/lib/Driver/ToolChains/Solaris.h
  cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/sparc-sun-solaris2.11/bits/gthr.h
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/typeinfo
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crt1.o
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtbegin.o
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtend.o
  cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/libatomic.a
  
cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/sparcv9/libatomic.a
  cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/lib/crti.o
  cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/lib/crtn.o
  cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/lib/ld.so.1
  cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crti.o
  cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crtn.o
  cfe/trunk/test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/ld.so.1
  
cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/i386-pc-solaris2.11/bits/gthr.h
  
cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/typeinfo
  
cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/amd64/libatomic.a
  
cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtbegin.o
  
cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtend.o
  
cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtbegin.o
  
cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtend.o
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/libatomic.a
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crt1.o
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crti.o
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crtn.o
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/ld.so.1
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/crt1.o
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/crti.o
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/crtn.o
  cfe/trunk/test/Driver/Inputs/solaris_x86_tree/usr/lib/ld.so.1
  
cfe/trunk/test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
cfe/trunk/test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
cfe/trunk/test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  cfe/trunk/test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crti.o
  cfe/trunk/test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crtn.o
  cfe/trunk/test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/ld.so.1
  cfe/trunk/test/Driver/solaris-header-search.cpp
  cfe/trunk/test/Driver/solaris-ld.c

Index: cfe/trunk/test/Driver/solaris-header-search.cpp
===
--- cfe/trunk/test/Driver/solaris-header-search.cpp
+++ cfe/trunk/test/Driver/solaris-header-search.cpp
@@ -1,11 +1,41 @@
-// Test that the C++ headers are found.
+// Test that the C++ headers are found on Solaris with gcc toolchain detection
 //
-// RUN: %clang -no-canonical-prefixes %s -### 2>&1 \
+// Sparc, 32bit
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
 // RUN: --target=sparc-sun-solaris2.11 \
-// RUN: --gcc-toolchain="" \
-// RUN: --sysroot=%S/Inputs/sparc-sun-solaris2.11 \
-// RUN:   | FileCheck %s
-// CHECK: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
-// CHECK: "-internal-isystem" "{{.*}}/usr/include/c++/v1/support/solaris"
-// CHECK: "-internal-isystem" "{{.*}}/usr/gcc/4.8/include/c++/4.8.2"
-// CHECK: "-internal-isystem" "{{.*}}/usr/gcc/4.8/include/c++/4.8.2/sparc-sun-solaris2.11"
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree 

[PATCH] D42029: [Solaris] Make RHEL devtoolsets handling Linux-specific

[Fedor Sergeev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL323194: [Solaris] Make RHEL devtoolsets handling 
Linux-specific (authored by fedor.sergeev, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D42029?vs=129762=131044#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D42029

Files:
  cfe/trunk/lib/Driver/ToolChains/Gnu.cpp


Index: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
@@ -1788,17 +1788,14 @@
   }
 
   // Non-Solaris is much simpler - most systems just go with "/usr".
-  if (SysRoot.empty()) {
-// Yet, still look for RHEL devtoolsets
-// (should it be done Linux-only??)
+  if (SysRoot.empty() && TargetTriple.getOS() == llvm::Triple::Linux) {
+// Yet, still look for RHEL devtoolsets.
 Prefixes.push_back("/opt/rh/devtoolset-6/root/usr");
 Prefixes.push_back("/opt/rh/devtoolset-4/root/usr");
 Prefixes.push_back("/opt/rh/devtoolset-3/root/usr");
 Prefixes.push_back("/opt/rh/devtoolset-2/root/usr");
-Prefixes.push_back("/usr");
-  } else {
-Prefixes.push_back(SysRoot.str() + "/usr");
   }
+  Prefixes.push_back(SysRoot.str() + "/usr");
 }
 
 /*static*/ void Generic_GCC::GCCInstallationDetector::CollectLibDirsAndTriples(


Index: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
@@ -1788,17 +1788,14 @@
   }
 
   // Non-Solaris is much simpler - most systems just go with "/usr".
-  if (SysRoot.empty()) {
-// Yet, still look for RHEL devtoolsets
-// (should it be done Linux-only??)
+  if (SysRoot.empty() && TargetTriple.getOS() == llvm::Triple::Linux) {
+// Yet, still look for RHEL devtoolsets.
 Prefixes.push_back("/opt/rh/devtoolset-6/root/usr");
 Prefixes.push_back("/opt/rh/devtoolset-4/root/usr");
 Prefixes.push_back("/opt/rh/devtoolset-3/root/usr");
 Prefixes.push_back("/opt/rh/devtoolset-2/root/usr");
-Prefixes.push_back("/usr");
-  } else {
-Prefixes.push_back(SysRoot.str() + "/usr");
   }
+  Prefixes.push_back(SysRoot.str() + "/usr");
 }
 
 /*static*/ void Generic_GCC::GCCInstallationDetector::CollectLibDirsAndTriples(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42029: [Solaris] Make RHEL devtoolsets handling Linux-specific

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

I'm trying!
I had no access to Solaris box, and I finally got one yesterday, though it is 
rather old one and slow.
I plan to resolve it all till the end of this week.


Repository:
  rC Clang

https://reviews.llvm.org/D42029



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

[PATCH] D42029: [Solaris] Make RHEL devtoolsets handling Linux-specific

[Fedor Sergeev via Phabricator via cfe-commits]

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

LGTM


Repository:
  rC Clang

https://reviews.llvm.org/D42029



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

[PATCH] D41242: [Solaris] Silence -pthread warning on Solaris

[Fedor Sergeev via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rC Clang

https://reviews.llvm.org/D41242



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

[PATCH] D39640: [lit] Set shlibpath_var on Solaris

[Fedor Sergeev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL319026: [lit] Set shlibpath_var on Solaris (authored by 
fedor.sergeev).

Changed prior to commit:
  https://reviews.llvm.org/D39640?vs=121626=124363#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D39640

Files:
  cfe/trunk/test/Unit/lit.cfg.py


Index: cfe/trunk/test/Unit/lit.cfg.py
===
--- cfe/trunk/test/Unit/lit.cfg.py
+++ cfe/trunk/test/Unit/lit.cfg.py
@@ -36,7 +36,7 @@
 config.environment[symbolizer] = os.environ[symbolizer]
 
 def find_shlibpath_var():
-if platform.system() in ['Linux', 'FreeBSD', 'NetBSD']:
+if platform.system() in ['Linux', 'FreeBSD', 'NetBSD', 'SunOS']:
 yield 'LD_LIBRARY_PATH'
 elif platform.system() == 'Darwin':
 yield 'DYLD_LIBRARY_PATH'


Index: cfe/trunk/test/Unit/lit.cfg.py
===
--- cfe/trunk/test/Unit/lit.cfg.py
+++ cfe/trunk/test/Unit/lit.cfg.py
@@ -36,7 +36,7 @@
 config.environment[symbolizer] = os.environ[symbolizer]
 
 def find_shlibpath_var():
-if platform.system() in ['Linux', 'FreeBSD', 'NetBSD']:
+if platform.system() in ['Linux', 'FreeBSD', 'NetBSD', 'SunOS']:
 yield 'LD_LIBRARY_PATH'
 elif platform.system() == 'Darwin':
 yield 'DYLD_LIBRARY_PATH'
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev marked an inline comment as not done.
fedor.sergeev added a comment.

In https://reviews.llvm.org/D35755#930030, @ro wrote:

> What's the status here?  This patch is required for my WIP 
> sanitizers-on-Solaris work.


since @tstellar just resolved the only remaining question I will go change the 
questionable part to linux-only and then I consider this ready to go.
Then we just have to find somebody who is willing to press the green button...
Thanks for keeping this topic alive, I kinda stopped pinging it.


https://reviews.llvm.org/D35755



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

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In https://reviews.llvm.org/D34158#836026, @jyknight wrote:

> In https://reviews.llvm.org/D34158#827178, @joerg wrote:
>
> > I had a long discussion with James about this on IRC without reaching a 
> > clear consensus. I consider forcing this behavior on all targets to be a 
> > major bug. It should be opt-in and opt-in only:
> >
> > (1) The header name is not mandated by any standard. It is not in any 
> > namespace generally accepted as implementation-owned.
>
>
> This is a point. I didn't think it was a big deal, but if you want to argue a 
> different name should be used, that's a reasonable argument.
>  If we can get some agreement amongst other libc vendors to use some more 
> agreeable alternative name, and keep a fallback on linux-only for the 
> "stdc-predef.h" name, I'd consider that as a great success.


Perhaps not a big deal yet, but as I have recently described stdc-predef.h idea 
to Oracle Solaris libc/headers/compilers folks, they generally welcomed the 
idea..

>> (3) ...Most other platforms have a single canonical libc, libm and 
>> libpthread implementation and can as such directly define all the relevant 
>> macros directly in the driver.
> 
> I don't think this is accurate. There's many platforms out there, and for 
> almost none of them do we have exact knowledge of the features of the libc 
> encoded into the compiler.

Solaris is a direct example of that...


https://reviews.llvm.org/D34158



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

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev marked an inline comment as not done.
fedor.sergeev added inline comments.



Comment at: lib/Driver/ToolChains/Gnu.h:253
 
+void AddDefaultGCCPrefixes(const llvm::Triple ,
+   SmallVectorImpl ,

aaron.ballman wrote:
> Might as well drop the `llvm::` since the namespace isn't used for 
> `SmallVectorImpl`.
suggested change caused a build failure since Triple resolves into 
Toolchain::Triple data member, not to llvm::Triple.


https://reviews.llvm.org/D35755



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

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev updated this revision to Diff 110194.
fedor.sergeev added a comment.

ugh... reverting back to llvm::Triple, since plain Triple conflicts with 
clang::driver::Toolchain::Triple data member.
Built/tested on Solaris11 x86/SPARC, Linux x86.


https://reviews.llvm.org/D35755

Files:
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Gnu.h
  lib/Driver/ToolChains/Solaris.cpp
  lib/Driver/ToolChains/Solaris.h
  lib/Frontend/InitHeaderSearch.cpp
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/sparc-sun-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/typeinfo
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtend.o
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/sparcv9/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/ld.so.1
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/ld.so.1
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/i386-pc-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/typeinfo
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/amd64/libatomic.a
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtend.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtend.o
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/libatomic.a
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/ld.so.1
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/ld.so.1
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crti.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crtn.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/ld.so.1
  test/Driver/solaris-header-search.cpp
  test/Driver/solaris-ld.c

Index: test/Driver/solaris-ld.c
===
--- test/Driver/solaris-ld.c
+++ test/Driver/solaris-ld.c
@@ -1,33 +1,105 @@
-// Test ld invocation on Solaris targets.
+// General tests that ld invocations on Solaris targets sane. Note that we use
+// sysroot to make these tests independent of the host system.
 
-// Check sparc-sun-solaris2.1
+// Check sparc-sun-solaris2.11, 32bit
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=sparc-sun-solaris2.11 \
-// RUN: --gcc-toolchain="" \
-// RUN: --sysroot=%S/Inputs/sparc-sun-solaris2.11 \
-// RUN:   | FileCheck %s
-// CHECK: "-cc1" "-triple" "sparc-sun-solaris2.11"
-// CHECK: ld{{.*}}"
-// CHECK: "--dynamic-linker" "{{.*}}/usr/lib/ld.so.1"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crt1.o"
-// CHECK: "{{.*}}/usr/lib/crti.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtbegin.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtend.o"
-// CHECK: "{{.*}}/usr/lib/crtn.o"
-// CHECK "-lc"
-// CHECK "-lgcc_s"
-// CHECK "-lgcc"
-// CHECK "-lm"
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32 %s
+// CHECK-LD-SPARC32-NOT: warning:
+// CHECK-LD-SPARC32: {{.*/clang}}" "-cc1" "-triple" "sparc-sun-solaris2.11"
+// CHECK-LD-SPARC32-SAME: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD-SPARC32: {{.*/ld}}"
+// CHECK-LD-SPARC32-SAME: 

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev updated this revision to Diff 110190.
fedor.sergeev added a comment.

auto changed to MultilibSet::IncludeDirsFunc.


https://reviews.llvm.org/D35755

Files:
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Gnu.h
  lib/Driver/ToolChains/Solaris.cpp
  lib/Driver/ToolChains/Solaris.h
  lib/Frontend/InitHeaderSearch.cpp
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/sparc-sun-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/typeinfo
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtend.o
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/sparcv9/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/ld.so.1
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/ld.so.1
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/i386-pc-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/typeinfo
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/amd64/libatomic.a
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtend.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtend.o
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/libatomic.a
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/ld.so.1
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/ld.so.1
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crti.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crtn.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/ld.so.1
  test/Driver/solaris-header-search.cpp
  test/Driver/solaris-ld.c

Index: test/Driver/solaris-ld.c
===
--- test/Driver/solaris-ld.c
+++ test/Driver/solaris-ld.c
@@ -1,33 +1,105 @@
-// Test ld invocation on Solaris targets.
+// General tests that ld invocations on Solaris targets sane. Note that we use
+// sysroot to make these tests independent of the host system.
 
-// Check sparc-sun-solaris2.1
+// Check sparc-sun-solaris2.11, 32bit
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=sparc-sun-solaris2.11 \
-// RUN: --gcc-toolchain="" \
-// RUN: --sysroot=%S/Inputs/sparc-sun-solaris2.11 \
-// RUN:   | FileCheck %s
-// CHECK: "-cc1" "-triple" "sparc-sun-solaris2.11"
-// CHECK: ld{{.*}}"
-// CHECK: "--dynamic-linker" "{{.*}}/usr/lib/ld.so.1"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crt1.o"
-// CHECK: "{{.*}}/usr/lib/crti.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtbegin.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtend.o"
-// CHECK: "{{.*}}/usr/lib/crtn.o"
-// CHECK "-lc"
-// CHECK "-lgcc_s"
-// CHECK "-lgcc"
-// CHECK "-lm"
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32 %s
+// CHECK-LD-SPARC32-NOT: warning:
+// CHECK-LD-SPARC32: {{.*/clang}}" "-cc1" "-triple" "sparc-sun-solaris2.11"
+// CHECK-LD-SPARC32-SAME: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD-SPARC32: {{.*/ld}}"
+// CHECK-LD-SPARC32-SAME: "--dynamic-linker" "[[SYSROOT]]/usr/lib/ld.so.1"
+// CHECK-LD-SPARC32-SAME: 

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In https://reviews.llvm.org/D34158#834298, @mibintc wrote:

> In fact I did have trouble writing the new test case to pass with the 
> gnu/Linux toolchain. In the file lib/Driver/ToolChains/Linux.cpp function 
> AddGnuIncludeArgs checks if GCCInstallation.isValid().


You should not be doing stdc-predef.h under GCCInstallation.isValid().
You are handling interaction with libc, so it has nothing to do with the 
presence or absence of gcc toolchain.


https://reviews.llvm.org/D34158



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

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a reviewer: tstellar.
fedor.sergeev marked 11 inline comments as done.
fedor.sergeev added inline comments.



Comment at: lib/Driver/ToolChains/Gnu.cpp:1840
+// Yet, still look for RHEL devtoolsets
+// (should it be done Linux-only??)
+Prefixes.push_back("/opt/rh/devtoolset-6/root/usr");

aaron.ballman wrote:
> This is a good question to get an answer to before committing. :-) I don't 
> know the answer myself, unfortunately.
So we need somebody that could answer it! :)
Last person who touched these paths was Tom Stellard.
Adding as a reviewer.



Comment at: lib/Driver/ToolChains/Solaris.cpp:208
   if (GCCInstallation.isValid()) {
-GCCVersion Version = GCCInstallation.getVersion();
-addSystemInclude(DriverArgs, CC1Args,
- getDriver().SysRoot + "/usr/gcc/" +
- Version.MajorStr + "." +
- Version.MinorStr +
- "/include/c++/" + Version.Text);
-addSystemInclude(DriverArgs, CC1Args,
- getDriver().SysRoot + "/usr/gcc/" + Version.MajorStr +
- "." + Version.MinorStr + "/include/c++/" +
- Version.Text + "/" +
- GCCInstallation.getTriple().str());
+const auto  = Multilibs.includeDirsCallback();
+if (Callback) {

aaron.ballman wrote:
> Shouldn't use `auto` here because the type is not spelled out in the 
> initialization.
I believe this is the case described in LLVM coding standard as "when the type 
would have been abstracted away anyways". It would be 
MultilibSet::IncludeDirsFunc, which IMO does not add anything to readability.


https://reviews.llvm.org/D35755



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

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev updated this revision to Diff 109593.
fedor.sergeev added a comment.

Corrected comments as suggested by Aaron.
Will be replying on other suggestions inline.


https://reviews.llvm.org/D35755

Files:
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Gnu.h
  lib/Driver/ToolChains/Solaris.cpp
  lib/Driver/ToolChains/Solaris.h
  lib/Frontend/InitHeaderSearch.cpp
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/sparc-sun-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/typeinfo
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtend.o
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/sparcv9/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/ld.so.1
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/ld.so.1
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/i386-pc-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/typeinfo
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/amd64/libatomic.a
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtend.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtend.o
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/libatomic.a
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/ld.so.1
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/ld.so.1
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crti.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crtn.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/ld.so.1
  test/Driver/solaris-header-search.cpp
  test/Driver/solaris-ld.c

Index: test/Driver/solaris-ld.c
===
--- test/Driver/solaris-ld.c
+++ test/Driver/solaris-ld.c
@@ -1,33 +1,105 @@
-// Test ld invocation on Solaris targets.
+// General tests that ld invocations on Solaris targets sane. Note that we use
+// sysroot to make these tests independent of the host system.
 
-// Check sparc-sun-solaris2.1
+// Check sparc-sun-solaris2.11, 32bit
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=sparc-sun-solaris2.11 \
-// RUN: --gcc-toolchain="" \
-// RUN: --sysroot=%S/Inputs/sparc-sun-solaris2.11 \
-// RUN:   | FileCheck %s
-// CHECK: "-cc1" "-triple" "sparc-sun-solaris2.11"
-// CHECK: ld{{.*}}"
-// CHECK: "--dynamic-linker" "{{.*}}/usr/lib/ld.so.1"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crt1.o"
-// CHECK: "{{.*}}/usr/lib/crti.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtbegin.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtend.o"
-// CHECK: "{{.*}}/usr/lib/crtn.o"
-// CHECK "-lc"
-// CHECK "-lgcc_s"
-// CHECK "-lgcc"
-// CHECK "-lm"
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32 %s
+// CHECK-LD-SPARC32-NOT: warning:
+// CHECK-LD-SPARC32: {{.*/clang}}" "-cc1" "-triple" "sparc-sun-solaris2.11"
+// CHECK-LD-SPARC32-SAME: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD-SPARC32: {{.*/ld}}"
+// CHECK-LD-SPARC32-SAME: "--dynamic-linker" "[[SYSROOT]]/usr/lib/ld.so.1"
+// CHECK-LD-SPARC32-SAME: 

[PATCH] D34158: For standards compatibility, preinclude if the file is available

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added inline comments.



Comment at: test/Driver/stdc-predef.c:15
+  /* In this test, the file stdc-predef.h is missing from the installation */
+#if _STDC_PREDEF_H
+  #error "stdc-predef.h should not be included"

I would rather see a real check on include file inclusion (say, checking -H 
output) than a check for a macro.
Exact macro guard name is not a public interface at all. You might be lucky 
with current stdc-predef.h on Linux, but on other platforms it could be named 
differently.


Repository:
  rL LLVM

https://reviews.llvm.org/D34158



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

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

ping?


https://reviews.llvm.org/D35755



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

[PATCH] D34158: For standards compatibility, preinclude if the file is available

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

In https://reviews.llvm.org/D34158#824079, @jyknight wrote:

> In https://reviews.llvm.org/D34158#823316, @fedor.sergeev wrote:
>
> > Hmm... I tried this patch and now the following worries me:
> >
> > - it passes -finclude-if-exists stdc-predef.h on all platforms (say, 
> > including my Solaris platform that has no system stdc-predef.h)
>
>
> Right, but Solaris probably _ought_ to add one as well, to define those 
> macros.


Point taken, started internal discussion with Solaris header folks.

> +1 for using a <> include -- that does seem better.

This is the only remaining issue that I would like to see fixed here.


Repository:
  rL LLVM

https://reviews.llvm.org/D34158



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

[PATCH] D34158: For standards compatibility, preinclude if the file is available

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

Hmm... I tried this patch and now the following worries me:

- it passes -finclude-if-exists stdc-predef.h on all platforms (say, including 
my Solaris platform that has no system stdc-predef.h)
- it searches all the paths, not just "system include" ones

That essentially disallows user to have stdc-predef.h include in my own 
project, since there is a chance that this user header
will be accidentally included by this hidden machinery.

  ] cat stdc-predef.h
  #error I was not expecting to see that
  ] bin/clang hello-world.c
  In file included from :2:
  ./stdc-predef.h:1:2: error: I was not expecting to see this!
  #error I was not expecting to see this!
   ^
  1 error generated.
  ]


Repository:
  rL LLVM

https://reviews.llvm.org/D34158



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

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev created this revision.

General idea is to utilize generic (mostly Generic_GCC) code
and get rid of Solaris-specific handling as much as possible.

In particular:

- scanLibDirForGCCTripleSolaris was removed, relying on generic 
CollectLibDirsAndTriples

- findBiarchMultilibs is now properly utilized to switch between m32 and m64 
include & lib paths on Solaris

- C system include handling copied from Linux (bar multilib hacks)

Fixes PR24606.


https://reviews.llvm.org/D35755

Files:
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Gnu.h
  lib/Driver/ToolChains/Solaris.cpp
  lib/Driver/ToolChains/Solaris.h
  lib/Frontend/InitHeaderSearch.cpp
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/sparc-sun-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/include/c++/4.8.2/typeinfo
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crt1.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtbegin.o
  
test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/sparcv9/crtend.o
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/gcc/4.8/lib/sparcv9/libatomic.a
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/ld.so.1
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crti.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/crtn.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/sparcv9/ld.so.1
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/i386-pc-solaris2.11/bits/gthr.h
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/include/c++/4.9.4/typeinfo
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/amd64/libatomic.a
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/amd64/crtend.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtbegin.o
  
test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/gcc/i386-pc-solaris2.11/4.9.4/crtend.o
  test/Driver/Inputs/solaris_x86_tree/usr/gcc/4.9/lib/libatomic.a
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/amd64/ld.so.1
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crt1.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crti.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/crtn.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/ld.so.1
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crt1.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtbegin.o
  
test/Driver/Inputs/sparc-sun-solaris2.11/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/crtend.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crti.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/crtn.o
  test/Driver/Inputs/sparc-sun-solaris2.11/usr/lib/ld.so.1
  test/Driver/solaris-header-search.cpp
  test/Driver/solaris-ld.c

Index: test/Driver/solaris-ld.c
===
--- test/Driver/solaris-ld.c
+++ test/Driver/solaris-ld.c
@@ -1,33 +1,105 @@
-// Test ld invocation on Solaris targets.
+// General tests that ld invocations on Solaris targets sane. Note that we use
+// sysroot to make these tests independent of the host system.
 
-// Check sparc-sun-solaris2.1
+// Check sparc-sun-solaris2.11, 32bit
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=sparc-sun-solaris2.11 \
-// RUN: --gcc-toolchain="" \
-// RUN: --sysroot=%S/Inputs/sparc-sun-solaris2.11 \
-// RUN:   | FileCheck %s
-// CHECK: "-cc1" "-triple" "sparc-sun-solaris2.11"
-// CHECK: ld{{.*}}"
-// CHECK: "--dynamic-linker" "{{.*}}/usr/lib/ld.so.1"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crt1.o"
-// CHECK: "{{.*}}/usr/lib/crti.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtbegin.o"
-// CHECK: "{{.*}}/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2{{/|}}crtend.o"
-// CHECK: "{{.*}}/usr/lib/crtn.o"
-// CHECK "-lc"
-// CHECK "-lgcc_s"
-// CHECK "-lgcc"
-// CHECK "-lm"
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32 %s
+// CHECK-LD-SPARC32-NOT: 

[PATCH] D35337: [Solaris] gcc runtime dropped support for .ctors, switch to .init_array

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

Can anybody commit this for me, please? :-/


https://reviews.llvm.org/D35337



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

[PATCH] D35337: [Solaris] gcc runtime dropped support for .ctors, switch to .init_array

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added inline comments.



Comment at: lib/Driver/ToolChains/Gnu.cpp:2467
   const Generic_GCC::GCCVersion  = GCCInstallation.getVersion();
   bool UseInitArrayDefault =
   getTriple().getArch() == llvm::Triple::aarch64 ||

davide wrote:
> this is really a mess.
Any suggestions on how to improve? :)


https://reviews.llvm.org/D35337



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

[PATCH] D35337: [Solaris] gcc runtime dropped support for .ctors, switch to .init_array

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev updated this revision to Diff 106392.
fedor.sergeev added a comment.

Added Solaris targets to clang driver test checking for -fuse-init-array.


https://reviews.llvm.org/D35337

Files:
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Solaris.cpp
  lib/Driver/ToolChains/Solaris.h
  test/Driver/constructors.c


Index: test/Driver/constructors.c
===
--- test/Driver/constructors.c
+++ test/Driver/constructors.c
@@ -74,3 +74,11 @@
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target arm64-none-none-eabi \
 // RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
+//
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1\
+// RUN: -target sparc-sun-solaris2.11 \
+// RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
+//
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1\
+// RUN: -target i386-pc-solaris2.11 \
+// RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
Index: lib/Driver/ToolChains/Solaris.h
===
--- lib/Driver/ToolChains/Solaris.h
+++ lib/Driver/ToolChains/Solaris.h
@@ -50,7 +50,7 @@
 
 namespace toolchains {
 
-class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_GCC {
+class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_ELF {
 public:
   Solaris(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList );
Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -126,7 +126,7 @@
 
 Solaris::Solaris(const Driver , const llvm::Triple ,
  const ArgList )
-: Generic_GCC(D, Triple, Args) {
+: Generic_ELF(D, Triple, Args) {
 
   GCCInstallation.init(Triple, Args);
 
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -2471,7 +2471,8 @@
(!V.isOlderThan(4, 7, 0) || getTriple().isAndroid())) ||
   getTriple().getOS() == llvm::Triple::NaCl ||
   (getTriple().getVendor() == llvm::Triple::MipsTechnologies &&
-   !getTriple().hasEnvironment());
+   !getTriple().hasEnvironment()) ||
+  getTriple().getOS() == llvm::Triple::Solaris;
 
   if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
  options::OPT_fno_use_init_array, UseInitArrayDefault))


Index: test/Driver/constructors.c
===
--- test/Driver/constructors.c
+++ test/Driver/constructors.c
@@ -74,3 +74,11 @@
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target arm64-none-none-eabi \
 // RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
+//
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1\
+// RUN: -target sparc-sun-solaris2.11 \
+// RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
+//
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1\
+// RUN: -target i386-pc-solaris2.11 \
+// RUN:   | FileCheck --check-prefix=CHECK-INIT-ARRAY %s
Index: lib/Driver/ToolChains/Solaris.h
===
--- lib/Driver/ToolChains/Solaris.h
+++ lib/Driver/ToolChains/Solaris.h
@@ -50,7 +50,7 @@
 
 namespace toolchains {
 
-class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_GCC {
+class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_ELF {
 public:
   Solaris(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList );
Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -126,7 +126,7 @@
 
 Solaris::Solaris(const Driver , const llvm::Triple ,
  const ArgList )
-: Generic_GCC(D, Triple, Args) {
+: Generic_ELF(D, Triple, Args) {
 
   GCCInstallation.init(Triple, Args);
 
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -2471,7 +2471,8 @@
(!V.isOlderThan(4, 7, 0) || getTriple().isAndroid())) ||
   getTriple().getOS() == llvm::Triple::NaCl ||
   (getTriple().getVendor() == llvm::Triple::MipsTechnologies &&
-   !getTriple().hasEnvironment());
+   !getTriple().hasEnvironment()) ||
+  getTriple().getOS() == llvm::Triple::Solaris;
 
   if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
  options::OPT_fno_use_init_array, UseInitArrayDefault))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D35337: [Solaris] gcc runtime dropped support for .ctors, switch to .init_array

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

Note, that LLVM has already been changed to honor use-init-array on Solaris:

  https://reviews.llvm.org/rL305948

(before that change setting Options.UseInitArray in clang would not matter).


https://reviews.llvm.org/D35337



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

[PATCH] D35337: [Solaris] gcc runtime dropped support for .ctors, switch to .init_array

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev created this revision.

crtbegin.o from gcc toolchain as configured on latest Solaris
(with --enable-initfini-array) does not have support for .ctors.

Clang needs to switch to .init_array. Doing it unconditionally
is fine since older Solaris configurations do support .init_array.


https://reviews.llvm.org/D35337

Files:
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Solaris.cpp
  lib/Driver/ToolChains/Solaris.h


Index: lib/Driver/ToolChains/Solaris.h
===
--- lib/Driver/ToolChains/Solaris.h
+++ lib/Driver/ToolChains/Solaris.h
@@ -50,7 +50,7 @@
 
 namespace toolchains {
 
-class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_GCC {
+class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_ELF {
 public:
   Solaris(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList );
Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -126,7 +126,7 @@
 
 Solaris::Solaris(const Driver , const llvm::Triple ,
  const ArgList )
-: Generic_GCC(D, Triple, Args) {
+: Generic_ELF(D, Triple, Args) {
 
   GCCInstallation.init(Triple, Args);
 
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -2471,7 +2471,8 @@
(!V.isOlderThan(4, 7, 0) || getTriple().isAndroid())) ||
   getTriple().getOS() == llvm::Triple::NaCl ||
   (getTriple().getVendor() == llvm::Triple::MipsTechnologies &&
-   !getTriple().hasEnvironment());
+   !getTriple().hasEnvironment()) ||
+  getTriple().getOS() == llvm::Triple::Solaris;
 
   if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
  options::OPT_fno_use_init_array, UseInitArrayDefault))


Index: lib/Driver/ToolChains/Solaris.h
===
--- lib/Driver/ToolChains/Solaris.h
+++ lib/Driver/ToolChains/Solaris.h
@@ -50,7 +50,7 @@
 
 namespace toolchains {
 
-class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_GCC {
+class LLVM_LIBRARY_VISIBILITY Solaris : public Generic_ELF {
 public:
   Solaris(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList );
Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -126,7 +126,7 @@
 
 Solaris::Solaris(const Driver , const llvm::Triple ,
  const ArgList )
-: Generic_GCC(D, Triple, Args) {
+: Generic_ELF(D, Triple, Args) {
 
   GCCInstallation.init(Triple, Args);
 
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -2471,7 +2471,8 @@
(!V.isOlderThan(4, 7, 0) || getTriple().isAndroid())) ||
   getTriple().getOS() == llvm::Triple::NaCl ||
   (getTriple().getVendor() == llvm::Triple::MipsTechnologies &&
-   !getTriple().hasEnvironment());
+   !getTriple().hasEnvironment()) ||
+  getTriple().getOS() == llvm::Triple::Solaris;
 
   if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
  options::OPT_fno_use_init_array, UseInitArrayDefault))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34158: to support gcc 4.8 (and newer) compatibility on Linux, preinclude

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

> can you recommend someone to review the extra test changes?

I'm rather new to the project and thus rather bad at finding reviewers.
Also generally I do not consider myself qualified enough to be the only 
reviewer, though in this particular case I believe I spent enough time on the 
toolchain code for my own Solaris work.
I feel less qualified for the tests section...

I will take a look at the final version tomorrow.


Repository:
  rL LLVM

https://reviews.llvm.org/D34158



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

[PATCH] D34158: to support gcc 4.8 (and newer) compatibility on Linux, preinclude

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

LGTM wrt your update to sources.
And sorry, I'm not that qualified to answer your question on failing tests.

Probing existence of this header would make a sense, yet you are including it 
w/o a full path, so how are you going to find it for this probe?


Repository:
  rL LLVM

https://reviews.llvm.org/D34158



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

[PATCH] D34158: to support gcc 4.8 (and newer) compatibility on Linux, preinclude

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

> docs are rather clear that this functionality is Linux-only

Oh, well, gcc implementation is rather generic, it relies on gcc's config.gcc 
to detect glibc and then it adds a hook that unconditionally provides 
stdc-predef.h (TARGET_C_PREINCLUDE).
Currently config.gcc does that for the following pattern of triples:
*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* | 
*-*-kopensolaris*-gnu)

I'm not sure how far into that do you really want to dive :-/


https://reviews.llvm.org/D34158



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

[PATCH] D34158: to support gcc 4.8 (and newer) compatibility on Linux, preinclude

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added inline comments.



Comment at: lib/Driver/ToolChains/Gnu.h:219-220
 
+void AddGnuIncludeArgs(const llvm::opt::ArgList ,
+  llvm::opt::ArgStringList ) const;
+

To me this does not belong to GCC-Installation-Detector at all, as it does not 
have anything to do with detection.

As I see the only reason for adding it here is to check Version vs 4.8.0.
If thats true then adding getVersion() here and using it elsewhere seems a 
better solution.


https://reviews.llvm.org/D34158



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

[PATCH] D34158: to support gcc 4.8 (and newer) compatibility on Linux, preinclude

[Fedor Sergeev via Phabricator via cfe-commits]

fedor.sergeev added a comment.

There is no /usr/include/stdc-predef.h on Solaris and I see no sense in adding 
this -include for anything except Linux
(as docs are rather clear that this functionality is Linux-only).

Checked gcc on Solaris11/12 both SPARC and X86 - none are doing stdc-predef.h 
inclusion
(checking with

  gcc  - -dI https://reviews.llvm.org/D34158



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