[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Chad Versace]

On Tue 21 Mar 2017, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> > On 20 March 2017 at 18:30, Matt Turner <mattst88 at gmail.com> wrote:
> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:

> >>> These projects have been getting closer to upstream and "forcing" the
> >>> extra obstacle is effectively giving them the middle finger.
> >>
> >> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
> >>
> > Can we stop with the GCC thing ? Can we point to a place where we want
> > to use feature A introduced with GCC B and we don't ?
> 
> Are you freaking serious?!
> 
> This happens *all* the time. It happened like two days ago with commit
> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> happened at least once in the previous month, and every month before
> that.

More examples:

    - Jason and I wanted to use C11 generic expressions (that's what the
      C11 spec calls them) in anvil, but old GCC => !C11.

    - I *still* want to use _Generic.

    - If we could use C11, then we could stop using the
      include/c11/thread.h wrapper for the C11 thread features. We could use,
      you know, *real* C11 threads instead of faking it.

    - I want to do this:

          #define let __auto_type

      But __auto_type requires GCC 4.9
      <https://gcc.gnu.org/gcc-4.9/changes.html> or a comparably dated clang.

    - I want to use GCC's builtin overflow arithmetic functions
      <https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html> (such as
      __builtin_mul_overflow(), __builtin_add_overflow) where we currently do overflow checking by hand.
      The builtin functions are more secure (no chance of stupid mistakes) and
      faster (they simply do the arithmetic op then test the overflow flag in the
      CPU's status register).

    - I tend to be guilty occasionally breaking the build in
      anvil code, due to old GCC. I think it happened again again this week:

        freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | vulkan/anv_device.c:697:4: error: initializer element is not constant
        freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
        freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen this? i'm on HEAD
        freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 strikes again?
        freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely using gcc-4.9
        freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that '(VkExtent3D)' looks very much pointless there
        freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it happens, which is the "stable" gcc on gentoo
        freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like chadv broke it