On Thu, Jul 24, 2025 at 4:23 AM Jeff Law via Gcc wrote:
>
>
>
> On 7/23/25 5:45 PM, Andrew Pinski via Gcc wrote:
> > Hi all,
> >When I improved DSE to remove stores where the rhs is known 100% to be
> > an uninitialized variables (ssa_undefined_value_p), I get
On 7/23/25 5:45 PM, Andrew Pinski via Gcc wrote:
Hi all,
When I improved DSE to remove stores where the rhs is known 100% to be an
uninitialized variables (ssa_undefined_value_p), I get a few regressions due to
an uninitialized warning does not happen:
gcc.dg/uninit-40.c for an example
> -Original Message-
> From: Andrew Pinski
> Sent: Wednesday, July 23, 2025 4:45 PM
> To: gcc@gcc.gnu.org
> Subject: RFC/RFH: uninit warning vs DSE of store from a
> known uninitialized variable
>
> Hi all,
> When I improved DSE to remove stores where the r
Hi all,
When I improved DSE to remove stores where the rhs is known 100% to be an
uninitialized variables (ssa_undefined_value_p), I get a few regressions due to
an uninitialized warning does not happen:
gcc.dg/uninit-40.c for an example. (gcc.dg/analyzer/torture/boxed-int-1.c fails
also for
2025年7月17日 2:25:44 JST、Basile Starynkevitch より:
>
>The Cuthour wrote to the GCC mailing list
>
>> I understand that GNU Make and C++ Modules address many current challenges
>> with headers and dependency management.
>>
>> But what I'm suggesting is a build+p
>
Hello all,
The Cuthour wrote to the GCC mailing list
> I understand that GNU Make and C++ Modules address many current challenges
> with headers and dependency management.
>
> But what I'm suggesting is a build+package manager tightly integrated with the
> compiler
Thomas Koenig via Gcc writes:
> Hi,
>
> there is a branch I want to update. Git currently tells me
>
> Your branch is ahead of 'origin/devel/coarray_native' by 28906 commits.
> There are still a few ChangeLog entries to clean up, I'll make sure
> that contr
On 7/12/25 13:31, Thomas Koenig via Gcc wrote:
Am 12.07.25 um 13:11 schrieb Jonathan Wakely via Gcc:
Yes, it will probably make git unusable for a few hours, please don't
push all at once!
OK, I won't :-)
There might be two other possibilities that I can think of:
One would be
On Sat, 12 Jul 2025 at 12:31, Thomas Koenig wrote:
>
> Am 12.07.25 um 13:11 schrieb Jonathan Wakely via Gcc:
> > Yes, it will probably make git unusable for a few hours, please don't
> > push all at once!
>
> OK, I won't :-)
>
> There might be two other
Am 12.07.25 um 13:11 schrieb Jonathan Wakely via Gcc:
Yes, it will probably make git unusable for a few hours, please don't
push all at once!
OK, I won't :-)
There might be two other possibilities that I can think of:
One would be to squash all the commits (most of which came fro
On Sat, 12 Jul 2025 at 12:07, Mikael Morin via Gcc wrote:
>
> Le 12/07/2025 à 11:46, Thomas Koenig via Gcc a écrit :
> >
> > After doing that, can I just do a "git push", or will this cause any bad
> > effects like hanging servers etc? I seem to remember there
Le 12/07/2025 à 11:46, Thomas Koenig via Gcc a écrit :
After doing that, can I just do a "git push", or will this cause any bad
effects like hanging servers etc? I seem to remember there were some
issues a while back.
The hooks don't scale very well as far as I know, and I expe
Hi,
there is a branch I want to update. Git currently tells me
Your branch is ahead of 'origin/devel/coarray_native' by 28906 commits.
There are still a few ChangeLog entries to clean up, I'll make sure
that contrib/gcc-changelog/git_check_commit.py passes before
committing.
A
Hi All,
Please suggest if changes are required in the patch.
Thanks,
Sangamesh
On Fri, Jul 4, 2025 at 11:48 PM swamy sangamesh
wrote:
> Tried with the below change and able to bootstrap on AIX and X86.
>
> diff --git a/gcc/tree.cc b/gcc/tree.cc
> index e9a83e4260b..b693a58ab9d 10
It works OK in lang_specific_pre_link, but I get a segfault in a jit
target hook. (I guess this could again be a bug with global variables in
libgccjit)
The second issue I have is how can I extract the information I want from
the spec I evaluate?
For instance, how could I get the file found b
Tried with the below change and able to bootstrap on AIX and X86.
diff --git a/gcc/tree.cc b/gcc/tree.cc
index e9a83e4260b..b693a58ab9d 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -64,6 +64,7 @@ along with GCC; see the file COPYING3. If not see
#include "stringpool.h"
#include
On Tue, Jul 01, 2025 at 09:44:50PM +0200, Eric Botcazou wrote:
> > Some years ago (well, 5+ honestly) I was using I think 119 to help
> > figure out some endian-specific bugs in a patch I was working on. It
> > is slightly worrying if AIX/power support has bitrotted due to it
&g
ed to be access to an AIX system on the compile farm, but I do
> >> not know about the status of that.
> >>
> >> https://portal.cfarm.net/machines/list/ lists
> >> cfarm111 and cfarm119 as AIX machines, a POWER7
> >> and POWER8 system, respectively.
>
> Some years ago (well, 5+ honestly) I was using I think 119 to help
> figure out some endian-specific bugs in a patch I was working on. It
> is slightly worrying if AIX/power support has bitrotted due to it
> being kicked off the primary/secondary platforms list, are there any
> o
On Tue, Jul 1, 2025 at 10:31 AM swamy sangamesh via Gcc wrote:
>
> Thank you all for your response.
>
> I would be posting regression test results regularly and will work on
> setting up a buildbot for AIX.
>
> I can see that currently the AIX build is broken with the bel
Thank you all for your response.
I would be posting regression test results regularly and will work on
setting up a buildbot for AIX.
I can see that currently the AIX build is broken with the below error.
In file included from ./tm.h:25,
from /opt/freeware/src/packages/BUILD
ed to be access to an AIX system on the compile farm, but I do
> >> not know about the status of that.
> >>
> >> https://portal.cfarm.net/machines/list/ lists
> >> cfarm111 and cfarm119 as AIX machines, a POWER7
> >> and POWER8 system, respectively.
>
://portal.cfarm.net/machines/list/ lists
cfarm111 and cfarm119 as AIX machines, a POWER7
and POWER8 system, respectively.
Bootstrap works ok on cfarm119, with the right options. I haven't tried on
cfarm111 for a few years.
In the spirit of "Why not?" I gave this a spin. After replacing
make w
sts
> cfarm111 and cfarm119 as AIX machines, a POWER7
> and POWER8 system, respectively.
>
Bootstrap works ok on cfarm119, with the right options. I haven't tried on
cfarm111 for a few years.
There are quite a few known failures in the testsuite though.
Am 30.06.25 um 17:17 schrieb Richard Biener via Gcc:
There used to be access to an AIX system on the compile farm, but I do not know
about the status of that.
https://portal.cfarm.net/machines/list/ lists
cfarm111 and cfarm119 as AIX machines, a POWER7
and POWER8 system, respectively.
Best
All,
>
> Would like to know the criteria for adding AIX as a secondary platform.
> https://gcc.gnu.org/gcc-15/criteria.html
>
> Willing to participate in the work needed for the platform to be added as
> primary and secondary.
>
>
> --
> Thanks & Regards,
> Sangamesh
>
> Am 30.06.2025 um 16:55 schrieb swamy sangamesh via Gcc :
>
> Hi All,
>
> Would like to know the criteria for adding AIX as a secondary platform.
> https://gcc.gnu.org/gcc-15/criteria.html
Note we only make changes going forward which means for GCC 16, the set of
primary
Hi All,
Would like to know the criteria for adding AIX as a secondary platform.
https://gcc.gnu.org/gcc-15/criteria.html
Willing to participate in the work needed for the platform to be added as
primary and secondary.
--
Thanks & Regards,
Sangamesh
On Mon, Jun 30, 2025 at 8:59 AM Iain Sandoe wrote:
>
> Hi
>
> I am investigating the following;
>
> in the program code I have calls like
>
> uint16_t x = __crt_func ( 10 );
>
> where the argument is guaranteed to be a compile-time uint16_t literal.
>
> So I
Hi
I am investigating the following;
in the program code I have calls like
uint16_t x = __crt_func ( 10 );
where the argument is guaranteed to be a compile-time uint16_t literal.
So I’ve arranged a series of crts (built with -flto) where one is like
1/
uint16_t
__crt_func (const uint16_t
Hi GCC folks,
introducing a new RISC instruction set with a variable length
instruction packet using a super regular extension scheme with
compression techniques to separate the instruction stream into
two streams, one for instructions and and one for constants:
- latest: https
stresults/2025-May/845705.html
>
> (checking=yes,extra,rtl,df,gcac,fold - almost 7 hours wall clock time).
>
> A large part of the difference is explained by one of the emit-insn-N.cc
> files takes over an hour to compile (twice, of course) - mostly on its
> own ...
>
> In the
).
A large part of the difference is explained by one of the emit-insn-N.cc
files takes over an hour to compile (twice, of course) - mostly on its
own ...
In the manual "checking=fold" is not indicated as one of the checking
options that takes a lot of time ... but that was perhaps
, 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
1 - 100 of 4918 matches
Mail list logo
