Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-04-26 Thread Christian Biesinger via Gcc-patches
On Mon, Apr 26, 2021 at 2:32 PM Joseph Myers wrote: > > On Mon, 26 Apr 2021, Nick Clifton via Gcc-patches wrote: > > > Hi Guys, > > > > Given that gcc, gdb and now binutils are all now requiring C99 as a > > minimum version of C, are there any objections to updating > > configure.ac to

Re: V3 [PATCH 5/5] gnulib: Support variables from the top level Makefile

2021-01-05 Thread Christian Biesinger via Gcc-patches
On Fri, Jan 1, 2021 at 1:07 AM H.J. Lu via Gdb-patches wrote: > > On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers wrote: > > > > On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote: > > > > > Work around what appears to be a GNU make bug handling MAKEFLAGS > > > values defined in terms of make

Re: [PATCH] Don't override various Makefile variables for gnulib et al

2020-02-12 Thread Christian Biesinger via gcc-patches
Ping On Wed, Jan 29, 2020 at 8:07 AM Christian Biesinger wrote: > > Ping > > On Sat, Nov 23, 2019 at 12:30 AM Christian Biesinger > wrote: > > > > Normally the toplevel Makefile will pass various CC=foo and other > > flags down to subdir Makefiles. However, for Gnulib this is a problem > >

Re: [PATCH] Don't override various Makefile variables for gnulib et al

2020-01-29 Thread Christian Biesinger via gcc-patches
Ping On Sat, Nov 23, 2019 at 12:30 AM Christian Biesinger wrote: > > Normally the toplevel Makefile will pass various CC=foo and other > flags down to subdir Makefiles. However, for Gnulib this is a problem > because Gnulib's configure specifically sets CC to something that > includes a

[PATCH] Don't override various Makefile variables for gnulib et al

2019-11-22 Thread Christian Biesinger via gcc-patches
Normally the toplevel Makefile will pass various CC=foo and other flags down to subdir Makefiles. However, for Gnulib this is a problem because Gnulib's configure specifically sets CC to something that includes a -std=gnu11 flag on some systems, and this override would set it back to CC=gcc,

Re: [PATCH] Remove unused #include "vec.h" from hash-table.h

2019-09-25 Thread Christian Biesinger via gcc-patches
On Mon, Sep 23, 2019 at 3:15 PM Jason Merrill wrote: > > On Mon, Sep 23, 2019 at 3:52 PM Christian Biesinger via gcc-patches > wrote: > > > > From: Christian Biesinger > > > > Removes an unused include as a cleanup. Requires updating > > lots of files w

Re: [RFC] Move hash-table.h and related files to libiberty

2019-09-25 Thread Christian Biesinger via gcc-patches
On Sat, Sep 21, 2019 at 7:41 AM Richard Biener wrote: > > On September 21, 2019 12:28:57 PM GMT+02:00, Christian Biesinger > wrote: > >On Sat, Sep 21, 2019 at 7:22 PM Richard Biener > > wrote: > >> > >> On September 21, 2019 11:12:38 AM GMT+02:00, Christ

[PATCH] Remove unused #include "vec.h" from hash-table.h

2019-09-23 Thread Christian Biesinger via gcc-patches
From: Christian Biesinger Removes an unused include as a cleanup. Requires updating lots of files who previously relied on this transitive include. I have only been able to test this on x86_64 because I failed at building a cross compiler. gcc/ChangeLog: 2019-09-23 Christian Biesinger

Re: [RFC] Move hash-table.h and related files to libiberty

2019-09-21 Thread Christian Biesinger via gcc-patches
On Sat, Sep 21, 2019 at 7:22 PM Richard Biener wrote: > > On September 21, 2019 11:12:38 AM GMT+02:00, Christian Biesinger via > gcc-patches wrote: > >Hello, > > > >I would like to move hash-table.h, hash-map.h and related files > >to libiberty, so that GDB

[RFC] Move hash-table.h and related files to libiberty

2019-09-21 Thread Christian Biesinger via gcc-patches
Hello, I would like to move hash-table.h, hash-map.h and related files to libiberty, so that GDB can make use of it. I see that gcc already has a C++ file in include/ (unique-ptr.h), which I understand is libiberty. However, this patch is not complete yet (for a start, it doesn't compile).