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

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

 



On Tue 21 Mar 2017, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote:
> > On 20 March 2017 at 18:30, Matt Turner <mattst88@xxxxxxxxx> wrote:
> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux