On Sat, 15 Oct 2016, grischka wrote:

Christian Jullien wrote:
The point is that it compiles ROOTB but then a single line program using only ISO include and std C library fails because of __aligned in a **system** header. I agree that __aligned is a probably a macro or a gcc FreeBSD specific extension, but no one wants to change it source file (or Makefile) when he the switch from gcc to tcc To be more clear, let me start again from scratch (Don’t miss *Linux* in banner with -v and -vv)

Please!  You were clear.  Anyway, maybe this helps:
It is expected that this could break system xyz whatever.

Ugh. TCC doesn't support enough of GNU C to be able to sensibly define __GNUC__. I've privately started to support more of it, but it's nowhere complete. I don't think that's going to work very well.

Christian: you were completely clear in your initial mail. I was trying to make you look into FreeBSDs headers to find out _where_ the __aligned macro is defined, under which conditions. I wanted to know this so that I can suggest an acceptable and least intrusive way for TCC to work around the problem in FreeBSDs standard headers.

Some background research:

- obviously FreeBSD headers expect __GNUC__


- patch for sys/cdefs.h suggested by PCC

- __GNUC__ nowadays seems to mean the C dialect rather than the compiler

Not sure whether we really want to define __GNUC__.  This might
cause all kind of problems.  However if we don't then sys/cdefs.h does
   #define __attribute__(xyz)

So, FreeBSDs problem really. Well, we could add work arounds in TCC of course, and possibly defining __GNUC__ is the most sensible work around. But please, then only for the BSDs, not for all the rest. The other possibility is to define __aligned ourself (also only on *BSD), if that's the only missing thing breaking otherwise standard-conforming programs on FreeBSD. The compat define should come from some header IMHO, e.g. stddef.h, not pre-defined by TCC itself.

Tinycc-devel mailing list

Reply via email to