This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR18785: Support non-native execution charsets


On Wed, 22 Dec 2004, Joseph S. Myers wrote:
> > which when compiled on Linux with mainline CVS, using the command line
> > gcc -c -Wall -fexec-charset=IBM1047 warn.c
> >
> > generates the inappropriate/incorrect diagnostics:
> > warn.c: In function `foo':
> > warn.c:5: warning: spurious trailing `%' in format
> > warn.c:5: warning: too many arguments for format
>
> There would seem to be something wrong with the testing if you get "`"
> from mainline as a left quote.
>
> I don't actually see why this patch would affect format diagnostics since
> they don't use c_getstr.  But if it does, I think that would be losing
> diagnostics for the common case of -fexec-charset to avoid wrong ones for
> the uncommon case.

My mistakes;  I pasted the above warnings from the wrong window.  I did
confirm that exactly the same diagnostics (modulo the `) are still
generated by mainline.  I've also checked and confirmed that the
Wformat diagnostic machinery doesn't use c_getstr, so my patch doesn't
fix the above failure, but does provide the necessary infrastructure
to correct it.

Rather than file an new PR for it, I'm currently bootstrapping and
regression testing a variant of my patch that does fix this bug.

> If it does, there should be a testcase - but I think correcting it at
> the expense of more valid messages would be wrong.

The set of character sets supported by iconv is not portable from
system to system, for example -fexec-charset=IBM1047 isn't supported
on cygwin/newlib targets.


> What I do object to is the c_getstr change, which is far more wide-ranging
> than necessary in its disabling of optimizations.  The disabling should be
> done locally in expand_builtin_printf, expand_builtin_fprintf,
> expand_builtin_sprintf, fold_builtin_sprintf which need it.  In addition I
> see that __builtin_nan could be a problem, but is harder to deal with.

The API of c_getstr that returns a "const char*" is inappropriate for
use with non-native character sets.  Any uses of the current c_getstr
that happen to work with -fexec-charset= are accidental and
non-intentional.  For example, the C99 standards statements over
embedded NULs in target strings covers targets who's systems/runtimes
are fully C99 compliant.  Unfortunately, GCC is required to support
many systems who aren't fully C99 compliant (Tru64, HPUX, Darwin,
Windows, etc...) where the compiler can't/shouldn't make such assumptions
about the execution environment.

Or perhaps, perversely, we disable use of c_getstr with -ffree-standing?

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]