gcc/configure handling $host == $target but different $build

[Robert Schiele]

Hi,

I saw incorrect gcc/configure results when building a native compiler
with a cross compiler. I think I understand what is going wrong there
but looking for your opinion on my thoughts:

Let's get through the thing with an example.

Assume:
$build == i686-pc-linux-gnu
$host == $target == arm-linux-gnu

Let's further assume my build system has sys/sdt.h, while my target does not.

In this scenario gcc/configure incorrectly concludes that my target
has sys/sdt.h.

This seems to happen like this:

Since $host == $target and there is no $TARGET_SYSTEM_ROOT set (The
compiler I am building that way will operate as a native compiler.)
configure concludes target_header_dir=${native_system_header_dir}

This conclusion seems wrong in case $build != $target and because of
that all tests for target headers are done on the build system instead
of the sys-root for the target.

Did I miss something that I should have set for this specific scenario
or do you agree that I should patch the configure to consider in case
of $host == $target the special case of $build != $target, in which
case I should figure out the location of the build system compiler's
sys-root and set target_header_dir to that one?

That means something like:

if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
  [... some other code not of interest here ...]
elif test x$build != x$target; then
  target_header_dir=${sysroot_of_build_cc_header_dir}
else
  target_header_dir=${native_system_header_dir}
fi

assuming that I can figure out sysroot_of_build_cc_header_dir in some way.

Robert

infrastructure to detect whether code originates from macro expansion

[Robert Schiele]

Hi,

in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 Manuel
López-Ibáñez mentioned that starting with gcc 4.7 there is supposed to
be infrastructure to figure out for diagnostics whether the location
of an error was created by macro expansion and that this can be used
to disable a warning in that case.

Can anyone point me to the name of a function/macro I should use to
check that or another example in the code that already does this?

I mean I can see how maybe_unwind_expanded_macro_loc figures out
whether it needs to unwind macro expansions but I am not sure whether
this linemap_lookup/linemap_macro_expansion_map_p stuff is what I am
supposed to use in the place where I check for the diagnostics to emit
or whether there is a higher level abstraction of this functionality.

Additionally I found that the mentioned
linemap_lookup/linemap_macro_expansion_map_p stuff seems to produce
useful information on the gcc 4.8 branch with the example from the bug
report but not on the gcc 4.7 branch. On the latter I actually don't
get the macro unwinding information. Thus it seems that this is not
the infrastructure Manuel was refering to.

Robert