, I'd be happy to revise it.
I’ll update the PDF on the GSoC portal accordingly.
Thanks!
On Thu, 3 Apr 2025 at 19:07, Jose E. Marchesi wrote:
> We get reports occassionally and normally we open bugzillas for them,
> but not always.
>
> We can compile a list of recent fix
> On Tue, Apr 1, 2025 at 8:07 PM Jose E. Marchesi
> wrote:
>>
>> Hello Piyush.
> Hello Jose,
>
>> Sounds like a quite good background.
> Thank you!
>
>> Have you built GCC from sources?
> Yes, I have. I built GCC while working on LFS and recently reb
On Tue, Apr 1, 2025 at 8:07 PM Jose E. Marchesi
wrote:
>
> Hello Piyush.
Hello Jose,
> Sounds like a quite good background.
Thank you!
> Have you built GCC from sources?
Yes, I have. I built GCC while working on LFS and recently rebuilt it,
running the test suite while going through
you for your understanding.
>
> -- Forwarded message -
> From: Piyush Raj
> Date: Tue, 1 Apr 2025 at 01:46
> Subject: [GSoC] Tooling for running BPF GCC tests on a live kernel
> To:
>
> Hello,
> I am an engineering student with experience in DevOps and
On Wed, Mar 26, 2025 at 1:44 AM Robin Dapp wrote:
> > You won't see failures in the testsuite. The failures only show-up when I
> > attempt to impose huge costs on NF above threshold. A quick & dirty way
> to
> > expose the bug is apply the appended patch, then
You won't see failures in the testsuite. The failures only show-up when I
attempt to impose huge costs on NF above threshold. A quick & dirty way to
expose the bug is apply the appended patch, then observe that you get output
from this only for mask_struct_store-*.c and not for mask_st
On Tue, Mar 25, 2025 at 2:47 AM Robin Dapp wrote:
> > A year ago, Robin added minimal and not-yet-tunable
> > common_vector_cost::segment_permute_[2-8]
>
> But it is tunable, just not a param? :)
I meant "param" generically, not necessarily a command-line --para
On 3/25/25 3:47 AM, Robin Dapp via Gcc wrote:
I am revisiting an effort to make the number of lanes for vector segment
load/store a tunable parameter.
A year ago, Robin added minimal and not-yet-tunable
common_vector_cost::segment_permute_[2-8]
But it is tunable, just not a param? :) We
I am revisiting an effort to make the number of lanes for vector segment
load/store a tunable parameter.
A year ago, Robin added minimal and not-yet-tunable
common_vector_cost::segment_permute_[2-8]
But it is tunable, just not a param? :) We have our own cost structure in our
downstream repo
I am revisiting an effort to make the number of lanes for vector segment
load/store a tunable parameter.
A year ago, Robin added minimal and not-yet-tunable
common_vector_cost::segment_permute_[2-8]
Some issues & questions:
* Since this pertains only to segment load/store, why is the
and I will get back to you with
additional information for your review.
Looking forward to your response.
Thanks,
Catherine Hill |Demand Generation Manager
From: Catherine Hill
Sent: Wednesday, March 12, 2025 10:41 AM
To: gcc@gcc.gnu.org
Subject: Take A
Hi Folks,
here is an idea expressed as a simple proof-of-concept simulator.
- https://github.com/michaeljclark/glyph/
I have been working on a proof-of-concept simulator for a RISC
architecture with an immediate base register next to the program counter
to split the front-end stream into
On Thu, 6 Mar 2025 at 15:09, Gwen Fu via Gcc wrote:
>
> Dear GCC Community,
>
> I have just joined the GCC community and am currently learning about the
> framework and essential knowledge related to the GCC compiler. I have
> cloned the GCC source code to my virtual machine, but I find the codeba
Dear GCC Community,
I have just joined the GCC community and am currently learning about the
framework and essential knowledge related to the GCC compiler. I have
cloned the GCC source code to my virtual machine, but I find the codebase
to be quite large and am unsure where to start. Do you have a
On Wednesday, March 5th, 2025 at 21:06, Nathaniel Shead via Gcc
wrote:
> Worth noting that GCC already provides a mapper that you can customise:
>
> $ g++ -fmodules -fmodule-mapper='|@g++-module-server -r path' -c m.cpp
>
> for an m.cpp that provides a module &quo
and send contents as necessary
>
> In my beautiful, blinded fantasy, this flag should only be used with other
> tools
> keeping the CMIs up-to-date, e.g. a build system. If a build system ensures
> all
> needed CMIs are updated before the source gets built, there should be no
>
as build tools like Make sometimes change current working
> directory,
> and so we need to locate CMIs in different folders.
>
> The mapping between module interface unit, module name, and expected CMI
> filename is still performed by the module mapper. But now when looking up
>
ching or give up?
> - caching and distributed build tools now need to somehow encapsulate
> repository state into their hashes and send contents as necessary
In my beautiful, blinded fantasy, this flag should only be used with other tools
keeping the CMIs up-to-date, e.g. a build system. If a b
t; The mapping between module interface unit, module name, and expected CMI
> filename is still performed by the module mapper. But now when looking up a
> CMI,
> it goes to each repo in the list, in order, until it finds a CMI that matches
> and returns its full path. When produ
,
and so we need to locate CMIs in different folders.
The mapping between module interface unit, module name, and expected CMI
filename is still performed by the module mapper. But now when looking up a CMI,
it goes to each repo in the list, in order, until it finds a CMI that matches
and returns its
mplicit module build" strategy which is
more-or-less "dump things into a directory and find modules like we find
headers"). However, the number of corner cases that exist at this level
are only bad news for using it for projects in the real world (i.e.,
incrementally; clean CI builds pro
is regard (though I haven't looked
at what xmake does between projects), but it currently only offers the
information through CMake target properties which is not all that useful
outside of CMake itself. The likely solution is to use CPS:
https://github.com/cps-org/cps
to propagat
On Sunday, March 2nd, 2025 at 02:13, Ben Boeckel via Gcc
wrote:
> On Sat, Mar 01, 2025 at 16:15:12 +, vspefs wrote:
>
> > I read a few mails from the autoconf thread. I'll try to read all now.
> > However,
> > a maybe-off-topic-but-could-be-on-topic questi
On Sat, Mar 01, 2025 at 16:15:12 +, vspefs wrote:
> I read a few mails from the autoconf thread. I'll try to read all now.
> However,
> a maybe-off-topic-but-could-be-on-topic question: what exactly is the state of
> Autotools now? The whole Autotools build system seems to
I read a few mails from the autoconf thread. I'll try to read all now. However,
a maybe-off-topic-but-could-be-on-topic question: what exactly is the state of
Autotools now? The whole Autotools build system seems to be on a very slow
release cycle. They seem to lack enough contributors/mainta
GCC conjures up both .o file and .gcm file in one invocation when possible, too.
And yes, that can be managed well with grouped target - but a rule with grouped
target must have a recipe, which I think is a little beyond `gcc -M`'s scope.
Thanks for bringing up the pattern rule workaround, t
t for its
Fortran dependency scanning internally). I'd like to integrate it into
gfortran as well, but not had the time to do so.
> Regarding Fortran modules, it is possible to create both the .o and any
> needed .mod files from one compiler execution. You can tell GNU Make that a
>
On Fri, Feb 28, 2025 at 13:54:45 -0500, Paul Smith wrote:
> On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote:
> > > In POSIX make, including GNU Make, if a command doesn't modify the
> > > modification time of the target then that target is not considere
On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote:
> > In POSIX make, including GNU Make, if a command doesn't modify the
> > modification time of the target then that target is not considered
> > updated, and other targets which list it as a prerequisite are no
> > `.RESTAT: output` in Make) and skips running dependent rules if the
> > output has not updated the mtime of the output(s) before the rule
> > (recipe) was executed. This can be used for modules to not have to
> > recompile sources that import the output modules it if they
On Fri, 2025-02-28 at 13:07 -0500, Paul Smith via Gcc wrote:
> ~$ touch three; make -f /tmp/x3.mk MKTWO=echo
Sorry this should be just "make MKTWO=echo"; my typo.
> output has not updated the mtime of the output(s) before the rule
> (recipe) was executed. This can be used for modules to not have to
> recompile sources that import the output modules it if they didn't
> change
I've seen this statement a few times and I've read the d
On Thu, Feb 27, 2025 at 21:39 vspefs via Gcc wrote:
> Current `-Mmodules` output is based on [P1602R0](wg21.link/p1602r0), which
> speaks about a set of Makefile rules that can handle modules, with the
> help of
> module mappers and a modified GNU Make.
>
> The proposal came ou
Current `-Mmodules` output is based on [P1602R0](wg21.link/p1602r0), which
speaks about a set of Makefile rules that can handle modules, with the help of
module mappers and a modified GNU Make.
The proposal came out in 2019, and the output of those rules was implemented
at GCC in 2020. However
ize 24 # in bytes, three registers excluding the incoming argument
> ...
>> ret 24
>
> Random observation: if the callee pops the stack you will have a harder
> time dealing with stdarg functions.
The callee only pops the stack up to and including the return address.
(The
On 2/24/25 4:32 AM, Florian Weimer wrote:
As a hobby project, I'm working on a mostly memory-safe architecture
that is targeted at direct software emulation. The majority of its
instructions have memory operands that are relative to the stack
pointer. Calls and returns adjust the
incoming argument
...
> ret 24
Random observation: if the callee pops the stack you will have a harder
time dealing with stdarg functions.
> I tried to create a GCC backend for this, by looking at the existing
> mmix backend (for the register windows) and the bpf backend (due to
> its verifi
As a hobby project, I'm working on a mostly memory-safe architecture
that is targeted at direct software emulation. The majority of its
instructions have memory operands that are relative to the stack
pointer. Calls and returns adjust the stack pointer, so I suppose one
could say tha
and will go through a few bugs to see where
I can reasonably add this.
Fortran is a complicated language, and quite often the question is not
if a program is illegal or not, but what it should do.
Best regards
Thomas
Thomas Koenig via Gcc writes:
> Hello world,
>
> looking at a few Fortran bug reports, I found some cases where
> it was not clear if the program in question was standard-conforming
> or not. I would propose to add a keyword for that, tentatively
> called "interp".
&
Hi!
On 2025-02-10T20:59:43+0100, Thomas Koenig wrote:
> Am 10.02.25 um 08:43 schrieb Richard Biener:
>> We have need-bisection and other need-, so iff then maybe a need-stdchk for
>> cases compliance is unclear?
>
> That sounds very good to me; if there are no objections, I
On Mon, 2025-02-10 at 09:29 +, Jonathan Wakely via Gcc wrote:
> On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc,
> wrote:
>
> > Hello world,
> >
> > looking at a few Fortran bug reports, I found some cases where
> > it was not clear if the program in questi
neeeds-stdcheck, makes a lot
of sense.
Am 10.02.25 um 08:43 schrieb Richard Biener:
We have need-bisection and other need-, so iff then maybe a need-stdchk for
cases compliance is unclear?
That sounds very good to me; if there are no objections, I will create
this in a day or so.
The fact that a testcase is (non-)compliant is
On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, wrote:
> Hello world,
>
> looking at a few Fortran bug reports, I found some cases where
> it was not clear if the program in question was standard-conforming
> or not. I would propose to add a keyword for that, tentatively
&
On Mon, Feb 10, 2025 at 8:19 AM Andre Vehreschild wrote:
>
> Hi all,
>
> I don't like the new keyword. Could we do "stdcomp" (for "standard compliant")
> or something like that? When a keyword allows a question mark, I would even
> add
> that, i.e
Hi all,
I don't like the new keyword. Could we do "stdcomp" (for "standard compliant")
or something like that? When a keyword allows a question mark, I would even add
that, i.e.. like "stdcomp?". Or when we like to go with interp then at least
add "std&quo
On 2/9/25 1:07 AM, Thomas Koenig wrote:
Hello world,
looking at a few Fortran bug reports, I found some cases where
it was not clear if the program in question was standard-conforming
or not. I would propose to add a keyword for that, tentatively
called "interp".
Comments? Suggest
Hello world,
looking at a few Fortran bug reports, I found some cases where
it was not clear if the program in question was standard-conforming
or not. I would propose to add a keyword for that, tentatively
called "interp".
Comments? Suggestions for a different name? Should I jus
On 31/01/2025 14:22, noname noname via Gcc wrote:
hello, I'm a regular user of Fedora 41 Workstation. I usually install all
my apps through one command which has tons of packages to it. So I'm not
sure which one of them pulled gcc as a dependency. But either way. While
installing a
On Fri, 31 Jan 2025 at 13:24, noname noname via Gcc wrote:
>
> hello, I'm a regular user of Fedora 41 Workstation. I usually install all
> my apps through one command which has tons of packages to it. So I'm not
> sure which one of them pulled gcc as a dependency.
On 31/01/2025 14:22, noname noname via Gcc wrote:
hello, I'm a regular user of Fedora 41 Workstation. I usually install all
my apps through one command which has tons of packages to it. So I'm not
sure which one of them pulled gcc as a dependency. But either way. While
installing a
sorry, I forgot to mention that the packages were installed somewhere in
November or December 2024. So this bug might already be resolved by now.
пт, 31 янв. 2025 г. в 15:22, noname noname :
> hello, I'm a regular user of Fedora 41 Workstation. I usually install all
> my apps through
hello, I'm a regular user of Fedora 41 Workstation. I usually install all
my apps through one command which has tons of packages to it. So I'm not
sure which one of them pulled gcc as a dependency. But either way. While
installing all of them, dnf said:
[128/579] Installing libgcc-0:14.
On Mon, Dec 30, 2024 at 11:16:37AM +1100, raf wrote:
> Rather than expecting all C compilers to be modified to
> ignore the #! line, it should be possible to configure
> /bin/sh to do the desired thing. If a file is
> executable and has no #! line, the kernel will execute
>
Rather than expecting all C compilers to be modified to
ignore the #! line, it should be possible to configure
/bin/sh to do the desired thing. If a file is
executable and has no #! line, the kernel will execute
it via /bin/sh. Anyone who wants this facility could
create a .profile file (or
You can also do what I do now (the example in my first message), and don't need to
pre-process the file before sending it to the compiler. What Jonothan suggested
("Still it would be a nice touch ...") would be great - but simply being able
use a custom script to (like I do
>>> cat e
#!/bin/sh
#
#
root -l -b <
int main(void)
{
puts("Hello, world, you can ignore all that particle physics if you like.");
printf("By the way, log(2025) is %lf\n",log(2025.));
printf("Here I have suppressed the banner\n");
return 0;
}
DOIT
>>> ./e
Hello, world, you can ignore al
On Sat, Dec 28, 2024 at 2:48 PM Florian Weimer wrote:
> [...]
>
>
> Still it would be a nice touch if we could do
>
> #!/usr/bin/gcc -f
> #include
> int main()
> {
> puts("Hello, world");
> return 0;
> }
>
re previously mentioned "roo
* Jonathan Wakely via Gcc:
> Here's a complete example:
>
> #!/bin/sh
> set -e
> out=$(mktemp /tmp/a.out.XX)
> sed 1,5d "$0" | gcc -x c - -o "$out"
> exec "$out"
>
> #include
> int main()
> {
> puts("Hello, worl
Does "root" do what you want?
https://root.cern/
https://root.cern/primer/#learn-c-at-the-root-prompt
Includes a c++ interpreter (which includes all of C) that interprets C as
you go, then at your option, compile a just-interpreted function,
dynamically link it, and use the compiled
On Sat, 28 Dec 2024, 16:17 Jonathan Wakely, wrote:
>
>
> On Sat, 28 Dec 2024, 15:26 Paul Smith via Gcc, wrote:
>
>> On Sat, 2024-12-28 at 09:00 -0600, Paul Markfort via Gcc wrote:
>> > I realize that C is not a line oriented language and usually
>> >
On Sat, 28 Dec 2024, 15:26 Paul Smith via Gcc, wrote:
> On Sat, 2024-12-28 at 09:00 -0600, Paul Markfort via Gcc wrote:
> > I realize that C is not a line oriented language and usually
> > completely ignores line termination characters (so yes this is
> > probably not
On Sat, 2024-12-28 at 09:00 -0600, Paul Markfort via Gcc wrote:
> I realize that C is not a line oriented language and usually
> completely ignores line termination characters (so yes this is
> probably not a simple thing to do).
You probably really want this capability added to the pre
I had about the same thought 20 some years ago. I also wanted a more
advanced preprocessor which had more scripting capabilities, with knowledge
of the C lexical output. For example write a preprocessor script that
would call a macro every time a function call was entered.
I also always
To be clear.
I am not suggesting that Compilers like GCC be modified to act on the "#!", or
even fully support it.
Just that they be simply modified to ignore "#!" - on the first line (which should terminate with
either a "/r" or "/n").
This allows t
Hello all,
Paul Markfort suggested
>
> This is just a suggestion to make it easier for Linux/Unix users to
> use the Gnu compilers instead of having to use a scripting language
> for short little utilities.
>
> I know someone has created and released a binary C interpreter
On Mon, Dec 16, 2024 at 11:43 AM Alexander Monakov wrote:
>
>
> On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
>
> > I would like to provide a facility to create wrapper functions without
> > lots of argument shuffling. To achieve that, the wrapping function and
This is just a suggestion to make it easier for Linux/Unix users to use the Gnu
compilers instead of having to use a scripting language for short little
utilities.
I know someone has created and released a binary C interpreter for this purpose.
But why would you want to install another
On Tue, 24 Dec 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> > Well, the first paragraph in your initial mail was talking very explicitly
> > about making a tailcall from the wrapper, so I guess the goalpost has moved.
>
> Uhm, I meant a tailcall from the tra
* Alexander Monakov:
> Well, the first paragraph in your initial mail was talking very explicitly
> about making a tailcall from the wrapper, so I guess the goalpost has moved.
Uhm, I meant a tailcall from the trampoline, not the wrapper.
>> LD_AUDIT offers outright replacement of
e of, apart of generating wrappers
> >> > in asm (speaking of, is there some reason that wouldn't work for you?).
> >>
> >> You mean wrappers that inject the extra argument? That doesn't work for
> >> variadic functions.
> >
> > Why not? I
* Alexander Monakov:
>> > Not in a way that will work with LLVM, I'm afraid, and with GCC
>> > you'll have to shield wrappers from LTO:
>> >
>> > register void *r10 asm("r10");
>> > void f(int, int);
>> > void f_wrap(int a,
On Mon, 23 Dec 2024, Florian Weimer via Gcc wrote:
> * Alexander Monakov:
>
> > On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
> >
> >> I would like to provide a facility to create wrapper functions without
> >> lots of argument shuffling. To ach
* Alexander Monakov:
> On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
>
>> I would like to provide a facility to create wrapper functions without
>> lots of argument shuffling. To achieve that, the wrapping function and
>> the wrapped function should have the same pro
> On 17 Dec 2024, at 5:44 AM, Alexander Monakov wrote:
>
>
>> On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
>>
>> I would like to provide a facility to create wrapper functions without
>> lots of argument shuffling. To achieve that, the wrapping fun
On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
> I would like to provide a facility to create wrapper functions without
> lots of argument shuffling. To achieve that, the wrapping function and
> the wrapped function should have the same prototype. There will be a
> trampoli
I would like to provide a facility to create wrapper functions without
lots of argument shuffling. To achieve that, the wrapping function and
the wrapped function should have the same prototype. There will be a
trampoline that puts additional data somewhere (possibly including the
address of the
Friday Nov 8, 16:00 UTC
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
Using #overseers on irc.libera.chat as backup.
To get the right time in your local timezone:
$ date -d "Fri Nov 8 16:00 UTC 2024"
Sourceware relies on cooperation among a broad diversity of core
toolchain and deve
compiler options and target
> > (.bss, .data, .rodata, .sbss, etc.). If the compiler has
> > "-align-object-data-section=64" in effect, then you could add ".align
> > 64" to the start and the end of each section. As far as I can see,
> > that would giv
compiler has
> "-align-object-data-section=64" in effect, then you could add ".align
> 64" to the start and the end of each section. As far as I can see,
> that would give the effect the OP is looking for in a simple manner
> that can also be different for different tr
to
> >> improve cache usage.
> >>
> >> However, in a multicore setting it is a never-ending source of
> >> unintentionally showing up and disappearing false-sharing depending on
> >> unrelated variables being added or removed.
> >>
> >> I'm a
On Thu, 24 Oct 2024 at 16:06, Mateusz Guzik wrote:
> On Thu, Oct 24, 2024 at 4:35 PM Jonathan Wakely
> wrote:
> >> For illustrative purposes, I don't care about the name:
> >> -align-object-data-section=64
> >>
> >> Thoughts?
> >
> >
&
On Thu, Oct 24, 2024 at 4:35 PM Jonathan Wakely wrote:
>> For illustrative purposes, I don't care about the name:
>> -align-object-data-section=64
>>
>> Thoughts?
>
>
> Wouldn't that be a linker option, and so not part of GCC?
>
Indeed it would be, I
On Thu, 24 Oct 2024 at 15:00, Mateusz Guzik via Gcc wrote:
> I understand the stock behavior of pilling variables on may happen to
> improve cache usage.
>
> However, in a multicore setting it is a never-ending source of
> unintentionally showing up and disappearing false-shari
I understand the stock behavior of pilling variables on may happen to
improve cache usage.
However, in a multicore setting it is a never-ending source of
unintentionally showing up and disappearing false-sharing depending on
unrelated variables being added or removed.
I'm aware one can man
On 24/10/2024 16:35, Jonathan Wakely via Gcc wrote:
On Thu, 24 Oct 2024 at 15:00, Mateusz Guzik via Gcc wrote:
I understand the stock behavior of pilling variables on may happen to
improve cache usage.
However, in a multicore setting it is a never-ending source of
unintentionally showing up
t the name:
>> >> -align-object-data-section=64
>> >>
>> >> Thoughts?
>> >
>> >
>> > Wouldn't that be a linker option, and so not part of GCC?
>> >
>>
>> Indeed it would be, I assumed this is the right list to prod though.
>>
Friday Oct 11, 16:00 UTC
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
Using #overseers on irc.libera.chat as backup.
To get the right time in your local timezone:
$ date -d "Fri Oct 11 16:00 UTC 2024"
Sourceware relies on cooperation among a broad diversity of core
toolchain and
of
mainline in support for some microcontroller cores and workarounds for known
hardware bugs, and they also often backported such changes from newer gcc mainline
to older gcc releases. So there is a very real chance that the sources you have
are not original.
>
> You could download the archive
Am 27.09.2024 um 11:03 schrieb David Brown:
So there is a very real chance that the sources you have are not original.
You could download the archived release from the gcc website and compare
the sources to get some idea if they have changed.
i do not have original source - only binaries, i
> but that usage should be visible by using -v on the original build, or?
>>> >
>>>
>>> I think so yes, but I'm not sure. If you said arm-elf in the mail Subject
>>> you might get the attention of somebody who knows the details.
>>
>> so jus
t; but that usage should be visible by using -v on the original build, or?
>
I think so yes, but I'm not sure. If you said arm-elf in the mail Subject
you might get the attention of somebody who knows the details.
so just repost with a changed subject?
Have you tried to obtain the so
t
> > > the
> > > > people who built your old toolchain didn't edit them.
> > >
> > > the other way would be using --with-multilib-list=list ?
> > > but that usage should be visible by using -v on the original build, or?
> > >
> >
>
ginal build, or?
>
I think so yes, but I'm not sure. If you said arm-elf in the mail Subject
you might get the attention of somebody who knows the details.
so just repost with a changed subject?
Have you tried to obtain the sources from whoever provided the original
compiler that you
On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote:
> Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
>
>
> > They might not have
> > been using the original gcc-3.4.0 sources.
>
>
> seems to be very possible
>
>
>
> > There should be no need to edit those files, but that doesn't mean that
> the
content of my gcc-3.4.0\gcc\config\arm\t-arm-elf
https://pastebin.com/CivYHhRa
Am 27.09.2024 um 09:23 schrieb Dennis Luehring via Gcc:
im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
old cross toolchain
building with my script (https://pastebin.com/kAEK0S24) works
but
On Fri, 27 Sept 2024, 08:24 Dennis Luehring via Gcc,
wrote:
> im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
> old cross toolchain
> building with my script (https://pastebin.com/kAEK0S24) works
> but my -print-multi-lib returns only
>
> ---
&g
Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
They might not have
been using the original gcc-3.4.0 sources.
seems to be very possible
There should be no need to edit those files, but that doesn't mean that the
people who built your old toolchain didn't edit them.
the other way would
1 - 100 of 4885 matches
Mail list logo
