[cfe-dev] ARM cross fails after recent changes to clang in branch release_30

[Sebastian Pop]

Hi,

Cross compilers using include files different than hosts' system include files
on Linux started failing from the moment we added the case llvm::Triple::Linux
to the following switch:

 void InitHeaderSearch::AddDefaultIncludePaths(const LangOptions &Lang,
                                               const llvm::Triple &triple,
                                             const HeaderSearchOptions
&HSOpts) {
+  // NB: This code path is going away. All of the logic is moving into the
+  // driver which has the information necessary to do target-specific
+  // selections of default include paths. Each target which moves there will be
+  // exempted from this logic here until we can delete the entire pile of code.
+  switch (triple.getOS()) {
+  default:
+    break; // Everything else continues to use this routine's logic.
+
+  case llvm::Triple::Win32:
+    return;
+  }
+

If I replace the return with a break, the code adding the include dirs from
the configure flag --with-c-include-dirs is executed and everything works
as before.

I understand that this code is meant to go away, so how do you recommend
to modify this code to be able to specify the include dirs in the case of cross
compilers?

What do you think about fixing this by moving this code:

  // Add dirs specified via 'configure --with-c-include-dirs'.
  StringRef CIncludeDirs(C_INCLUDE_DIRS);
  if (CIncludeDirs != "") {
    SmallVector<StringRef, 5> dirs;
    CIncludeDirs.split(dirs, ":");
    for (SmallVectorImpl<StringRef>::iterator i = dirs.begin();
         i != dirs.end();
         ++i)
      AddPath(*i, System, false, false, false);
    return;
  }

out of InitHeaderSearch::AddDefaultCIncludePaths and before the driver
starts looking for the system wide include files to respect the semantics of
--with-c-include-dirs

Thanks,
Sebastian

On Wed, Nov 9, 2011 at 2:50 PM, Sebastian Pop <spop at codeaurora.org> wrote:
> On Wed, Nov 9, 2011 at 2:33 PM, Chandler Carruth <chandlerc at google.com> wrote:
>> Eeep! I asked for the output because.. well, I need the output! ;] You've
>> snipped the really important part here: the paths it *didn't* find but tried
>> to find, the target it decided to use, the CC1 invocation, etc. =D
>> Can i have the full output?
>
> # ./clang -v /x/foo.c
> clang version 3.0 (/x/llvm/tools/clang 474341250c818952c314e539f0f53199080a5faf)
> Target: arm-none-linux-gnueabi
> Thread model: posix
>  "/x/build/Debug+Asserts/bin/clang" -cc1 -triple
> armv4t-none-linux-gnueabi -S -disable-free -main-file-name foo.c
> -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
> -target-abi aapcs-linux -target-cpu arm7tdmi -mfloat-abi soft
> -target-feature +soft-float-abi -target-linker-version 2.16.91.0.5
> -momit-leaf-frame-pointer -v -resource-dir
> /x/build/Debug+Asserts/bin/../lib/clang/3.0 -fmodule-cache-path
> /var/tmp/clang-module-cache -ferror-limit 19 -fmessage-length 136
> -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc
> -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
> -fcolor-diagnostics -o /tmp/foo-Axc7do.s -x c /x/foo.c
> clang -cc1 version 3.0 based upon llvm 3.0 default target arm-none-linux-gnueabi
> #include "..." search starts here:
> End of search list.
> /x/foo.c:1:10: fatal error: 'stdio.h' file not found
> #include "stdio.h"
>         ^
> 1 error generated.
>
> Sebastian
> --
> Qualcomm Innovation Center, Inc is a member of Code Aurora Forum


--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum