apologies.]
From 3e0e7d6e5cfdc46342fcad5fe6b24b4f47af0d87 Mon Sep 17 00:00:00 2001
Message-Id:
<3e0e7d6e5cfdc46342fcad5fe6b24b4f47af0d87.1532988611.git.John.Ericson@Obsidian.Systems>
From: John Ericson
Date: Mon, 30 Jul 2018 18:06:02 -0400
Subject: [PATCH] multilib: Don't bother with multilib configurat
On 07/30/18 19:48, Joseph Myers wrote:
On the contrary, I think an important principle here is that non-multilib
and multilib builds follow the same code paths as far as possible, with
the multilib variables just set to trivial values (modulo osdirname) in
the case of a non-multilib build - a non
The helper is for `--print-prog-name` and similar things. Since all
executable finding goes through it, we can move the default overrides
into that path too. This also ensures that if some is looking for a
*non*-program that called `as`, `ld`, etc., weird things don't happen.
---
gcc/gcc.c | 59 ++
OK I have polished off my code in light of previous discussion and will
submit it in follow-up emails.
As mentioned before, this patch series is on top of the
non-behavior-changing cleanup I previously submitted in
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576725.html
The first patch
This means, we might search for:
- path/$machine/$version/prog
- path/$machine/prog
- path/$machine-prog
But not
- path/$machine/$version/$machine-prog
because disambiguating $machine twice is unnecessary.
This does mean we less liberal in what we accept than LLVM, but that's
OK. The down side
This matches the behavior of Clang, and makes it easier to work with
cross compilers without heeding to hard-code paths at build time.
---
gcc/gcc.c | 78 ---
1 file changed, 68 insertions(+), 10 deletions(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
i
We will use this in the subsequent diff to control what basenames we
search for. In machine-specific subdirectories, we should just look for
the original basename, but in machine-agnostic subdirectories, we might
additionally look for prefixed disambiguated names, as an alternate
method of keeping
Previously, they always scraped the thread mode from `$CC -v', now, that
is the default but one may pass `--with-threads=MODEL` to be explicit
instead.
One use-case is bootstraping with a shorter critical path. The
traditionally route was to build an entire "static stage" GCC, build
libc, and then
From: John Ericson
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_t
at 11:02 AM, John Ericson wrote:
> Hello, this 4-year-old patch of mine was never reviewed. Per
> https://github.com/NixOS/nixpkgs/pull/414299, we in a package set / distro,
> Nixpkgs/NixOS, just began (albeit on an experimental basis) packaging GCC
> with this patch (among others)
there, so a good one to start with. (I think it would be unnecessary
complicated to discuss them all at once.)
Thanks in advance,
John
On Wed, Aug 18, 2021, at 4:38 PM, John Ericson wrote:
> From: John Ericson
>
> Previously, they always scraped the thread mode from `$CC -v', now,
This dates back to the creation of top-level `libgcc` in
fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
does nothing.
(For context, my overall goal here is hoping libgcc can depend on
fewer/no stuff that is generated by `gcc/Makefile`. This is me trying to
pluck some low-ha
This dates back to the creation of top-level `libgcc` in
fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
does nothing.
Andrew Pinksi adds:
> So looking into this further, MACHMODE_H used part of LIBGCC_DEPS
> because of TM_H and r0-78222-gfa9585134f6f58 moved away from incl
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_thread_file` cache variable first. I adm
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_C
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_C
From: John Ericson
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
use the output of:
$(CC) -print-sysroot
It is just used in one spot, in an AIX code-path. I just made (within
make) a shell variable to use instead.
I
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_C
From: John Ericson
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
use the output of:
$(CC) -print-sysroot
It is just used in one spot, in an AIX code-path. I just made (within
make) a shell variable to use instead.
I
* Makefile.in: Use regular libdir/includedir, no more libsubdir
etc.
* config/t-slibgcc-vms: Use regular libdir, no more libsubdir.
* configure: Regenerate.
* configure.ac: Stash away the passed libdir as orig_libdir, and
define libdir and includedir to matc
libdir as orig_libdir, and
define libdir and includedir to match what Makefile.in used to
do.
Signed-off-by: John Ericson
---
libssp/Makefile.am | 6 +--
libssp/Makefile.in | 113 +---
libssp/configure| 12 +++--
libssp/configure.ac
> and "get those settings passed down from top level" is one plausible end
> state - sharing logic implicitly that way rather than expanding it all
> locally in each target library configure script, even if expanding it
> locally for each library is useful as an intermediate stage.)
Correct m
On Mon, Aug 4, 2025, at 4:02 PM, Joseph Myers wrote:
> On Sun, 3 Aug 2025, John Ericson wrote:
>
> > > and "get those settings passed down from top level" is one plausible
> > > end state - sharing logic implicitly that way rather than expanding it
> &
On Tue, Aug 5, 2025, at 5:15 PM, Joseph Myers wrote:
> On Tue, 5 Aug 2025, John Ericson wrote:
>
> > > That's unavoidable to some extent, given that the GCC libraries have
> > > additional concepts for installation directories (such as a directory for
> &
I can't quite tell, but I have a nagging suspicion that this is unused.
It would be nice to simplify some of the multilib stuff, and the
complexity around source directory (rather than build directory)
handling seems like it ought not to be so necessary.
This also nicely fixes a "fixme" about the
er added in the
previous commit to implement the above logic.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 81025d4fafe..e98a67fdaec 100644
--- a/gcc/gcc.cc
+
file_at_path, just as find_a_file uses file_at_path.
(driver::set_up_specs): Initial just_machine_prefix, a constant
used above.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 76 +++---
1 file changed, 66 insertions(+), 10 deletions(-)
diff
unused paramter to match new callback
type.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index d3ba4d6565b..81025d4fafe 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -2783,7 +2783,7
make variable via autoconf
substitution.
* configure: Regenerate.
* configure.ac: New configure check to define NO_PIE_CFLAGS
using the algorithm Andrew asked for in the linked mail.
Suggested-by: Andrew Pinski
Signed-off-by: John Ericson
---
gcc/Makefile.in
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_thread_file` cache variable first. I adm
back on the above class which
inherited its name.
(do_spec_1): Updated to use new spec_path.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 126 +
1 file changed, 68 insertions(+), 58 deletions(-)
diff --git a/gcc/gcc.cc b/gcc/g
A follow-up from "driver: Rework for_each_path using C++"
These types are, for all intents and purposes, single-use closure
environment types. It is much more ergonomic to juse use lambdas for
this.
On IRC there was concern about static dispatch and compile times with
lambdas, but I have kept the
I think upon further reflection, I have a slightly different read of what's
going on.
See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
https://www.airs.com/ian/configure/configure_8.html (rendering of since-deleted
from the GDB repo item referenced in reply), which I also foun
From: John Ericson
This continues what I started in way back in
5fee8a0a9223d030c66d53c104fb0a431369248f --- there is no
executable-specific logic cluttering up find_a_file either, but instead
there is a clean separation.
The cost of this is that there is now some code duplication, but in
_file call.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 3e1e4bbd866..ca73aea90bd 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -387,7 +387,7 @@ static void xputenv (
(spec_path): Became the callback on the above class which
inherited its name.
(do_spec_1): Updated to use new spec_path.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 485 ++---
1 file changed, 242 insertions(+), 243 deletions(-)
dif
is no longer
mentioned at the beginning of the motivation :).
Cheers,
John
On Wed, Aug 6, 2025, at 12:57 AM, Andrew Pinski wrote:
> On Tue, Aug 5, 2025 at 9:54 PM Andrew Pinski wrote:
> >
> > On Tue, Aug 5, 2025 at 9:50 PM John Ericson wrote:
> > >
> > > This m
From: John Ericson
We will use this in the subsequent patch to control what filenames we
search for.
gcc/ChangeLog:
* gcc.cc (for_each_path): Pass an additional boolean argument to
the callback specifying whether the current directly being
searched is machine-specific
From: John Ericson
Prefatory note:
I've since learned that this quite similar to
https://inbox.sourceware.org/gcc-patches/20240522095404.1825269-1-...@gcc.gnu.org/,
postdating my original patch series, but predating this version. See
that thread for additional motivation. That patch upda
u, 7 Aug 2025, John Ericson wrote:
>
> > The VPATH workaround however is akin to:
> >
> > mkdir -p $build/mach0/mach1/libgcc
> > cd $build/mach0/mach1/libgcc
> > ln -s $gcc_source/libgcc/* ./
> > ./configure
> >
> > and it's that --- using
On Thu, Aug 7, 2025, at 3:21 PM, Joseph Myers wrote:
> On Thu, 7 Aug 2025, John Ericson wrote:
>
> > I think upon further reflection, I have a slightly different read of
> > what's going on.
> >
> > See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.h
On Thu, Jul 31, 2025, at 6:08 PM, Joseph Myers wrote:
> OK in the absence of build machinery maintainer objections within the next
> week.
Checking in on a few of these (this will be one of a few emails). I believe it
is has been a few weeks of no objections now?
John
On Thu, Jul 31, 2025, at 6:03 PM, Joseph Myers wrote:
> OK in the absence of libgcc or build machinery maintainer objections
> within the next week.
Checking in on a few of these (this will be one of a few emails). I believe it
is has been a few weeks of no objections now?
John
On Wed, Jul 30, 2025, at 5:52 PM, Joseph Myers wrote:
> OK in the absence of AIX maintainer objections within the next week.
Checking in on a few of these (this will be one of a few emails). I believe it
is has been a few weeks of no objections now?
John
back on the above class which
inherited its name.
(do_spec_1): Updated to use new spec_path.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 128 +
1 file changed, 70 insertions(+), 58 deletions(-)
diff --git a/gcc/gcc.cc b/gcc/g
build and that linked and run fine.
On Wed, Aug 20, 2025, at 11:05 PM, Jason Merrill wrote:
> On 8/13/25 2:48 PM, John Ericson wrote:
> > A follow-up from "driver: Rework for_each_path using C++"
> >
> > These types are, for all intents and purposes, single-use closu
for lambda
(build_search_list): Use for_each_path with lambda.
(find_a_file): Use for_each_path with lambda.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 142 +
1 file changed, 66 insertions(+), 76 deletions(-)
diff --git a/gcc/gc
From: John Ericson
This time use no classes, virtual methods. Just use higher order
functions using templates.
Now it's even shorter than before --- which is also shorter than the
no-lambda, pure OOP original --- but at the cost of some overkill
template specialization. Here are the
it makes some sense to separately consider 1 & 2
as a single unit, and then 3 & 4 as a single unit.
John
On Wed, Aug 6, 2025, at 5:44 PM, John Ericson wrote:
> Now that `find_a_program` and `find_a_file` have been separated, we
> don't need a mode parameter, because one is
e less spooky-action-at-a-distince using C++ features, but I
just matched how the corresponding suffix variable worked for
now for uniformity.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 54 +++---
1 file changed, 39 insertions(+), 15 d
From: John Ericson
Now that `find_a_program` and `find_a_file` have been separated, we can
make a number of simplification in both of them. Most notably, we don't
need a mode parameter, because one is always doing `R_OK`, and the other
is always doing `X_OK`.
This change also proves that
is pure duplication (for easy reading) but the rest of the
series will remove a bunch of dead code / extraneous parameters, until
there is hardly any duplication.
gcc/ChangeLog:
* gcc.cc (find_a_program): Inline find_a_file, instead of
calling.
Signed-off-by: John Ericson
()): Add unused parameter to match new
callback type.
Signed-off-by: John Ericson
---
gcc/gcc.cc | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 3f27c35708b..ebdbb0d2d78 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
From: John Ericson
The old C-style was cumbersome make making one responsible for manually
creating and passing in two parts a closure (separate function and
*_info class for closed-over variables).
With C++ lambdas, we can just:
- derive environment types implicitly
- have fewer stray static
On Fri, Aug 22, 2025, at 2:35 PM, Jason Merrill wrote:
> That looks fine to me. Please combine all three patches into one.
Great!
Also I remembered that since we're using templates now, I can also go ahead and
use a polymorphic return type to get rid of a pair of void* <-> char* casts. So
the
n end.f90 -o end
> > > > > > >> f951: Fatal Error: Cannot open pre-included file '\xe0\xd4\xf2,'
> > > > > > >> compilation terminated.
> > > > > > >>
> > > > > > >> From your description, it sou
From: John Ericson
Previously, they always scraped the thread mode from `$CC -v', now, that
is the default but one may pass `--with-threads=MODEL` to be explicit
instead.
One use-case is bootstraping with a shorter critical path. The
traditionally route was to build an entire "static
57 matches
Mail list logo
