[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] [PATCH] Don't break compilation process with unknow o

From: Michael Matz
Subject: Re: [Tinycc-devel] [PATCH] Don't break compilation process with unknow option
Date: Wed, 07 Jan 2015 07:08:46 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Am 07.01.2015 um 04:14 schrieb Sergey Korshunoff:

After applying a "disable DTEST" patch to allow "make test"  to pass a
broken tests...
    ./configure --cc=tcc; make; make install; make test
tcc -o tcctest.cc tcctest.c -I.. -I..  -w  -DTCC_TARGET_I386
-std=gnu99 -O0 -fno-omit-frame-pointer
tcc: error: invalid option -- '-std=gnu99'

With a patch apllied a test can be performed with
    make CFLAGS=-Wunsuported test

And your solution?

The makefile (and/or configure) needs to be fixed to not hardcode potentially unknown compiler options.

What you will add to CFLAGS?

Nothing. The only sensible thing that tcc can to with completely unknown options is to error out on them. It can't simply ignore them, not even with a warning as the unknown option in question might have significant effects for code generation for a compiler understanding it (-std=gnu99 is on the border of being such option) and the author might _require_ that effect to happen for his compilations. Ignoring it would either generate unnecessary followup errors or silently generate code with the wrong semantics, which is worse.

There is a case to be made to only warn for unknown options that influence diagnostics only. As it's unknown it's of course hard to know when exactly that is the case. If it starts with -W that might be a good enough heuristic in practice, so I'm with Thomas on this topic.

If you absolutely hate fixing makefiles/configures for trying out tcc, instead of patching tcc to ignore all unkown options you could also simply write a wrapper script that removes _known_ unknown options that you happen to hit when you know they indeed aren't important.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]