Sorry for the late response. I spent some time trying to understand
your concerns here, but I'm not sure I got what you are saying:
1) Did you assume this patch would somehow disable these formats during
cross builds, preventing the i386->arm xgcc from correctly using them?
I don't believe that's true. At worst this patch will cause additional
compile warnings.
2) Or is it the additional compile warnings this patch introduces that
are the problem? It seems to me that warnings SHOULD be generated when
encountering platform-specific features from another platform.
Do we really want to try to teach every platform about the
implementation details of all other platforms? While we could try, I'm
not convinced it's even possible. At best, a build could verify the
formats that were active (for the all the platforms supported by gnu) at
the time it got built. But given new formats, new platforms, etc
there's no way to know what's in the code it's trying to compile now.
It seems like a lot of complexity, and an ugly co-mingling of platforms,
all to prevent a few completely understandable warnings that only occur
when building the cross compiler (ie not when actually running the cross
compiler, doing bootstrap builds, etc).
That said, you have a better understanding of the design and vision of
gcc than I do. But if the warnings are your concern, perhaps I can
propose other alternatives for dealing with them?
Or have I completely missed your point?
dw
On 7/28/2014 3:21 PM, Joseph S. Myers wrote:
On Wed, 23 Jul 2014, David Wohlferd wrote:
2014-07-23 David Wohlferd <d...@limegreensocks.com>
* doc/c-family/c-format.c: Add support for target macro
ASM_FPRINTF_TABLE, remove arm-specific formats.
* gcc/config/arm/arm.h: Use ASM_FPRINTF_TABLE for %@ and %r.
* gcc/doc/tm.texi: Document new target macro.
* gcc/doc/tm.texi.in: Ditto.
* gcc/testsuite/gcc.dg/format/asm_fprintf-1.c: Make tests
for %@ and %r arm-specific.
This patch would have the effect that only compilers for ARM target
support the formats in asm_fprintf format checking. That is, when
building GCC, they would only be accepted when building GCC for ARM
*host*. But of course what you want is for them to be accepted when
building GCC for ARM *target* but any host. I.e., the support always
needs to be compiled into c-format.c, and the decision whether to enable
those formats needs to be taken by GCC when it is run, based on whether it
is compiling a copy of GCC for ARM target (as opposed to GCC for some
other target, or some other program altogether).
Existing configuration based on the GCC being compiled is in
init_dynamic_asm_fprintf_info and other such functions. I suppose you
could have a __gcc_asm_fprintf_arm_formats__ identifier declared in some
GCC header when building a compiler for ARM target (I'm supposing these
formats are unlikely to be used in files from which tm.h includes could be
removed any time soon).
