On Wed, 21 May 2025 at 09:27, Homam Alkhateeb wrote:
>
> Dear GCC Mailing List Administrators,
This is the main GCC mailing list, not how to reach the list
administrators. gcc-owner@gcc... is probably better for reaching the
admins, otherwise you're just adding more emails with your name in
them t
On Mon, 19 May 2025 at 16:58, Martin C. Foster wrote:
>
> Hi,
>
> I am a retired software engineer. I'm looking for projects where I might
> be useful. I would like to get on your mailing list.
>
> I listened to an interview with Jonathan Wakely on the podcast cppcast
> and contributing to the gcc
Hi,
I think using a different arc64 port is better as the new ARCv3 comes
with some new innovations which are not in the "classical" arc port.
Moreover, the classical arc is implementing arcv1, arcv2 and all kinds
of variations in between. Adding a new 64bit architecture will just
complicate the e
On 15/05/2025 17:55, Richard Biener wrote:
On Thu, May 15, 2025 at 6:43 PM Andrew Stubbs wrote:
Dear GCC Maintainers and Steering Committee,
I'm currently doing a feasibility study and effort estimate for
upstreaming the existing ARCv3 out-of-tree port [1].
Question: Is there likely to be an
On 16/05/2025 01:23, Paul Koning wrote:
On May 15, 2025, at 8:06 PM, Oleg Endo via Gcc wrote:
Hi,
On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote:
Dear GCC Maintainers and Steering Committee,
I'm currently doing a feasibility study and effort estimate for
upstreaming the existing A
> On May 15, 2025, at 8:06 PM, Oleg Endo via Gcc wrote:
>
> Hi,
>
> On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote:
>> Dear GCC Maintainers and Steering Committee,
>>
>> I'm currently doing a feasibility study and effort estimate for
>> upstreaming the existing ARCv3 out-of-tree por
Hi,
On Thu, 2025-05-15 at 17:41 +0100, Andrew Stubbs wrote:
> Dear GCC Maintainers and Steering Committee,
>
> I'm currently doing a feasibility study and effort estimate for
> upstreaming the existing ARCv3 out-of-tree port [1].
>
> Question: Is there likely to be any objection to adding a new
On Thu, May 15, 2025 at 6:43 PM Andrew Stubbs wrote:
>
> Dear GCC Maintainers and Steering Committee,
>
> I'm currently doing a feasibility study and effort estimate for
> upstreaming the existing ARCv3 out-of-tree port [1].
>
> Question: Is there likely to be any objection to adding a new "arc64"
On Wed, 14 May 2025 at 21:26, Jonathan Wakely wrote:
>
> On Wed, 14 May 2025 at 20:56, ASSI wrote:
> >
> > Jonathan Wakely via Gcc writes:
> > > For 13.4 the link on the https://gcc.gnu.org home page for the gcc 13
> > > status goes to https://gcc.gnu.org/pipermail/gcc/2025-April/245992.html
> >
On Wed, 14 May 2025 at 20:56, ASSI wrote:
>
> Jonathan Wakely via Gcc writes:
> > For 13.4 the link on the https://gcc.gnu.org home page for the gcc 13
> > status goes to https://gcc.gnu.org/pipermail/gcc/2025-April/245992.html
> > which says:
> > "The plan is to do a release candidate for GCC 13.
On Wed, May 14, 2025 at 09:55:07PM +0200, ASSI wrote:
> That seems appropriate for the GCC Releases document, while the one I
> linked to is advertised to show "future releases and an alternative view
> of the release history". But I get it that it's just not getting an
> update at this time so th
Jonathan Wakely via Gcc writes:
> For 13.4 the link on the https://gcc.gnu.org home page for the gcc 13
> status goes to https://gcc.gnu.org/pipermail/gcc/2025-April/245992.html
> which says:
> "The plan is to do a release candidate for GCC 13.4 on Thursday, May
> 29th, one week after the GCC 14.3
Jonathan Wakely via Gcc writes:
> On Wed, 14 May 2025 at 19:12, ASSI wrote:
>>
>>
>> The current schedule as published at
>>
>> https://gcc.gnu.org/develop.html
>>
>> ends with the 16.1 release.
>
> No it doesn't btw - it ends with the 15.1 release and with stage 1 for
> gcc 16, we're still a year
On Wed, 14 May 2025 at 20:09, Jonathan Wakely wrote:
>
> On Wed, 14 May 2025 at 19:12, ASSI wrote:
> >
> >
> > The current schedule as published at
> >
> > https://gcc.gnu.org/develop.html
> >
> > ends with the 16.1 release. Is there an updated / extended version
> > available that shows the pla
On Wed, 14 May 2025 at 19:12, ASSI wrote:
>
>
> The current schedule as published at
>
> https://gcc.gnu.org/develop.html
>
> ends with the 16.1 release.
No it doesn't btw - it ends with the 15.1 release and with stage 1 for
gcc 16, we're still a year away from the 16.1 release.
> Is there an
On Wed, 14 May 2025 at 19:12, ASSI wrote:
>
>
> The current schedule as published at
>
> https://gcc.gnu.org/develop.html
>
> ends with the 16.1 release. Is there an updated / extended version
> available that shows the planned releases for the next half year at
> least?
No, but you can extrapol
f the overall build process
being tracked by bear. For now I only have less than 50 lines.
Best regards,
Yuao
From: Sam James
Sent: Wednesday, May 14, 2025 10:32
To: Yuao Ma via Gcc
Cc: Yuao Ma
Subject: Re: Generating compile_commands.json for GCC source code
Yu
Yuao Ma via Gcc writes:
> Hello GCC developers,
> I am trying to generate a compile_commands.json file for the GCC source code.
> This file is very useful for various development tools and IDE integrations.
> Since GCC uses a Makefile-based build system, I attempted to use bear
> (https://githu
On Tue, May 13, 2025 at 12:51 PM Andrew Stubbs wrote:
>
> On 12/05/2025 15:27, Nikhil Patil via Gcc wrote:
> > Hi Richard,
> >
> > Thank you so much for the reply!
> >
> > You're absolutely right about using CPU threads. I’m just really curious
> > about whether GPU acceleration could somehow be e
On 12/05/2025 15:27, Nikhil Patil via Gcc wrote:
Hi Richard,
Thank you so much for the reply!
You're absolutely right about using CPU threads. I’m just really curious
about whether GPU acceleration could somehow be explored for compilation,
even if it’s not traditionally well-suited. I know it
Hi Nikhil,
While today's compilers are still largely very intricate code for Turing
machines, this will certainly change during your career. It seems you'll be
using GPUs for AI-assisted construction of optimal program graphs and
immediately testing the performance of code fragments instead of rel
Hi Richard,
Thank you so much for the reply!
You're absolutely right about using CPU threads. I’m just really curious
about whether GPU acceleration could somehow be explored for compilation,
even if it’s not traditionally well-suited. I know it might not be
practical, but I wanted to understand
On Mon, May 12, 2025 at 2:55 PM Nikhil Patil via Gcc wrote:
>
> Hi GCC Team,
>
> I'm fairly new to the world of compilers and trying to understand how they
> work in more depth. Recently, I started exploring the idea of *parallelizing
> the internal steps of compilation* — such as parsing, code ge
On Sun, May 11, 2025 at 8:38 PM Harald Anlauf wrote:
>
> Hi Thomas,
>
> Am 11.05.25 um 12:51 schrieb Thomas Koenig via Gcc:
> > Hi Harald,
> >
> >> Hi Thomas,
> >>
> >> On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
> >>> As PR120139 has shown (again), it is too easy to create regressions
> >>> fo
On Sun, May 11, 2025 at 10:34:11 +0200, Thomas Koenig via Gcc wrote:
> 2) Dump to standard output and check for the presence of certain
> regexps, ignoring anything else. Again, this is something I don't
> know how to do.
This is…fraught with peril and fiddliness. If the test can stomach some
C++
Hi Thomas,
Am 11.05.25 um 12:51 schrieb Thomas Koenig via Gcc:
Hi Harald,
Hi Thomas,
On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test
Hi Harald,
Hi Thomas,
On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
for something along this variant you can tr
Hi Thomas,
On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
So, what to do? I see several possibilities:
1a) Change t
On Monday, May 5th, 2025 at 19:14, Andreas Schwab wrote:
>
>
> On Mai 05 2025, Basile Starynkevitch wrote:
>
> > and to my surprise its libgccjit.h was installed under /usr/local/include/
> > and
>
>
> libgccjit.h has always been installed in $(includedir), so this is
> expected.
By the wa
On Mai 05 2025, Basile Starynkevitch wrote:
> and to my surprise its libgccjit.h was installed under /usr/local/include/ and
libgccjit.h has always been installed in $(includedir), so this is
expected.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552
On Thu, May 1, 2025 at 11:41 AM Toon Moene wrote:
>
> Compare:
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2025-April/845489.html
>
> (checking=yes,extra,rtl,df,gcac - shortly over 2 hours and 15 minutes)
>
> with:
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/845705.html
>
> (c
Gerald Pfeifer writes:
> On Sat, 26 Apr 2025, Jonathan Wakely wrote:
>> $ grep -R 'generator.*Docutils' libgomp | wc -l
>> 136
>> $ grep -R 'generator.*Docutils' libitm | wc -l
>> 8
>> $ grep -R 'generator.*Docutils' gdc | wc -l
>> 7
>> $ grep -R 'generator.*Docutils' gfc-internals | wc -l
>>
On Sat, 26 Apr 2025, Jonathan Wakely wrote:
> $ grep -R 'generator.*Docutils' libgomp | wc -l
> 136
> $ grep -R 'generator.*Docutils' libitm | wc -l
> 8
> $ grep -R 'generator.*Docutils' gdc | wc -l
> 7
> $ grep -R 'generator.*Docutils' gfc-internals | wc -l
> 4
I yanked all these, including
"Richard Earnshaw (lists) via Gcc" writes:
> On 30/04/2025 18:34, Heiko Eißfeldt wrote:
>>> - FEAT_LRCPC2 (+rcpc2), enabled by default for
>>> + FEAT_RCPC2 (+rcpc2), enabled by default for
>>>
>>> and
>>>
>>> - FEAT_LRCPC3 instructions, when support for the instructions is
>>> + FE
Hi Heiko,
Thanks for doing this...
> On 30 Apr 2025, at 18:53, Richard Earnshaw (lists) via Gcc
> wrote:
>
> On 30/04/2025 17:23, Heiko Eißfeldt wrote:
>> Hi,
>>
>> here is a patch for some mostly minor typos in
>> https://gcc.gnu.org/gcc-15/changes.html.
>> My fixes might be wrong of course
On 30/04/2025 18:34, Heiko Eißfeldt wrote:
>> - FEAT_LRCPC2 (+rcpc2), enabled by default for
>> + FEAT_RCPC2 (+rcpc2), enabled by default for
>>
>> and
>>
>> - FEAT_LRCPC3 instructions, when support for the instructions is
>> + FEAT_RCPC3 instructions, when support for the instructi
- FEAT_LRCPC2 (+rcpc2), enabled by default for
+ FEAT_RCPC2 (+rcpc2), enabled by default for
and
-FEAT_LRCPC3 instructions, when support for the instructions is
+FEAT_RCPC3 instructions, when support for the instructions is
These are incorrect. The features really are FEAT_LR
On 30/04/2025 17:23, Heiko Eißfeldt wrote:
> Hi,
>
> here is a patch for some mostly minor typos in
> https://gcc.gnu.org/gcc-15/changes.html.
> My fixes might be wrong of course, so they are just suggestions.
>
> Also, the linked page https://gcc.gnu.org/gcc-15/porting_to.html contains the
> n
Hey folks,
I thought I'll post a follow up here in case it is of wider interest.
First, my colleague Nicolas Savoire did a Git bisect and identified the
commit[0] that stopped GCC from choosing AArch64 FP registers for pointer
storage. He even created a reproducer[1] on Godbolt that shows the
dif
On Fri, Apr 25, 2025 at 2:31 PM ywgrit via Gcc wrote:
>
> I encountered one problem with loop-im pass.
> I compiled the program dhry2reg which belongs to unixbench(
> https://github.com/kdlucas/byte-unixbench).
>
> The gcc used
> gcc (GCC) 12.3.0
>
> The commands executed as following
> make
> ./R
ywgrit writes:
> I encountered one problem with loop-im pass.
> I compiled the program dhry2reg which belongs to
> unixbench(https://github.com/kdlucas/byte-unixbench).
>
> The gcc used
> gcc (GCC) 12.3.0
>
> The commands executed as following
> make
> ./Run -c -i 1 dhry2reg
>
> The results are
I encountered one problem with loop-im pass.
I compiled the program dhry2reg which belongs to unixbench(
https://github.com/kdlucas/byte-unixbench).
The gcc used
gcc (GCC) 12.3.0
The commands executed as following
make
./Run -c -i 1 dhry2reg
The results are shown below.
Dhrystone 2 using registe
On Sat, 26 Apr 2025 at 19:24, Jonathan Wakely wrote:
>
> On Sat, 26 Apr 2025 at 13:55, Sam James wrote:
> >
> > Gerald Pfeifer writes:
> >
> > > On Tue, 4 Feb 2025, Jonathan Wakely wrote:
> > > :
> > >>> ./gnat_ugn/_static/
> > >>> ./libgccjit/_static/
> > >>> ./libgdiagnostics/_static/
> > >>>
On Sat, 26 Apr 2025 at 13:55, Sam James wrote:
>
> Gerald Pfeifer writes:
>
> > On Tue, 4 Feb 2025, Jonathan Wakely wrote:
> > :
> >>> ./gnat_ugn/_static/
> >>> ./libgccjit/_static/
> >>> ./libgdiagnostics/_static/
> >>> ./libgomp/_static/
> > :
> >> N.B. there's ./jit/_static which should stay,
Gerald Pfeifer writes:
> On Tue, 4 Feb 2025, Jonathan Wakely wrote:
> :
>>> ./gnat_ugn/_static/
>>> ./libgccjit/_static/
>>> ./libgdiagnostics/_static/
>>> ./libgomp/_static/
> :
>> N.B. there's ./jit/_static which should stay, because jit still uses
>> sphinx for its docs.
>
I found
https://gc
On Tue, 4 Feb 2025 at 15:16, Jonathan Wakely wrote:
>
> On Fri, 15 Nov 2024 at 12:43, Gerald Pfeifer wrote:
> >
> > On Fri, 15 Nov 2024, Jonathan Wakely wrote:
> > > All these directories should have been removed two years ago:
> >
> > Agreed. Thank you for digging into this and raising it, Jonat
I encountered one problem with loop-im pass.
I compiled the program dhry2reg which belongs to unixbench(
https://github.com/kdlucas/byte-unixbench).
The gcc used
gcc (GCC) 12.3.0
The commands executed as following
make
./Run -c -i 1 dhry2reg
The results are shown below.
Dhrystone 2 using registe
I bootstrapped and tested on Power8 and Power9 BE in both 32-bit and
64-bit modes, and on Power8, Power9 & Power10 LE in 64-bit mode, and
everything looks good.
On 24/04/25 4:30 am, Peter Bergner wrote:
>
> The second release candidate for GCC 15.1 is available from
>
> https://gcc.gnu.org/pu
I bootstrapped and tested on Power8 and Power9 BE in both 32-bit and
64-bit modes, and on Power8, Power9 & Power10 LE in 64-bit mode, and
everything looks good.
On 24/04/25 4:28 am, Peter Bergner wrote:
>
> The first release candidate for GCC 15.1 is available from
>
> https://gcc.gnu.org/pub/g
Hi -
> We were wondering if it would be possible / suitable to have https
> requests served by one container,
> and ssh ones by another? Maybe that's already the case though...
SSH stuff is already (un)contained.
> [...]
> so maybe it would help if we switched to ssh access for our CI user
> whe
Hi!
Thanks for all the hard work maintaining all this fundamental infrastructure.
On Mon, 21 Apr 2025 at 18:00, Mark Wielaard wrote:
>
> Hi hackers,
>
> TLDR; When using https://patchwork.sourceware.org or Bunsen
> https://builder.sourceware.org/testruns/ you might now have to enable
> javascrip
Hi Mark,
On Tue, 22 Apr 2025, 4:00 am Mark Wielaard, wrote:
> Hi hackers,
>
> TLDR; When using https://patchwork.sourceware.org or Bunsen
> https://builder.sourceware.org/testruns/ you might now have to enable
> javascript. This should not impact any scripts, just browsers (or bots
> pretending
On 2025-04-22 14:06, Jonathan Wakely wrote:
> On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc
> wrote:
> >
> > On 4/21/25 12:59 PM, Mark Wielaard wrote:
> > > Hi hackers,
> > >
> > > TLDR; When using https://patchwork.sourceware.org or Bunsen
> > > https://builder.sourceware.org/testruns/
On Tue, 22 Apr 2025, 14:17 Guinevere Larsen, wrote:
>
> On 4/22/25 10:06 AM, Jonathan Wakely wrote:
> > On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc
> > wrote:
> >> On 4/21/25 12:59 PM, Mark Wielaard wrote:
> >>> Hi hackers,
> >>>
> >>> TLDR; When using https://patchwork.sourceware.org
On 4/22/25 10:06 AM, Jonathan Wakely wrote:
On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc wrote:
On 4/21/25 12:59 PM, Mark Wielaard wrote:
Hi hackers,
TLDR; When using https://patchwork.sourceware.org or Bunsen
https://builder.sourceware.org/testruns/ you might now have to enable
jav
On Tue, 22 Apr 2025 at 13:36, Guinevere Larsen via Gcc wrote:
>
> On 4/21/25 12:59 PM, Mark Wielaard wrote:
> > Hi hackers,
> >
> > TLDR; When using https://patchwork.sourceware.org or Bunsen
> > https://builder.sourceware.org/testruns/ you might now have to enable
> > javascript. This should not
On 4/21/25 12:59 PM, Mark Wielaard wrote:
Hi hackers,
TLDR; When using https://patchwork.sourceware.org or Bunsen
https://builder.sourceware.org/testruns/ you might now have to enable
javascript. This should not impact any scripts, just browsers (or bots
pretending to be browsers). If it does ca
Hi,
On Fri, Apr 18, 2025 at 09:42:57PM +0100, Jonathan Wakely via Gcc wrote:
> On Fri, 18 Apr 2025, 20:14 Siva Sai Manchem via Gcc,
> wrote:
> > We wanted to bring to your attention that one of our customers, who is
> > utilizing Zscaler services, is currently facing difficulties accessing your
>
On Fri, 18 Apr 2025, 20:14 Siva Sai Manchem via Gcc,
wrote:
> Hi Team,
>
> I hope you're doing well.
>
> We wanted to bring to your attention that one of our customers, who is
> utilizing Zscaler services, is currently facing difficulties accessing your
> website. Upon reviewing the issue, we fou
On 17/04/2025 12:19, Wasim Khan via Gcc wrote:
>
>
>> -Original Message-
>> From: Richard Earnshaw (lists)
>> Sent: 17 April 2025 14:57
>> To: Wasim Khan ; gcc-h...@gcc.gnu.org;
>> gcc@gcc.gnu.org
>> Subject: Re: memcpy issue with arm-gnu-toolc
On 17/04/2025 07:49, Wasim Khan via Gcc wrote:
> Hi,
>
> I have a custom implementation of memcpy() function and don't want to use
> implementation provided by libc.a.
> Things works fine with toolchain version 12.3 and my local implementation in
> utils.c is considered.
> But when I move to too
> -Original Message-
> From: Richard Earnshaw (lists)
> Sent: 17 April 2025 14:57
> To: Wasim Khan ; gcc-h...@gcc.gnu.org;
> gcc@gcc.gnu.org
> Subject: Re: memcpy issue with arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-
> none-elf
>
> [You don't of
++ gcc@gcc.gnu.org
> -Original Message-
> From: Wasim Khan
> Sent: 15 April 2025 12:41
> To: gcc-h...@gcc.gnu.org
> Subject: GCOV issue with GCC-14.2
>
> Hi,
>
> I am using GCOV for test coverage in a project using instructions for
> freestanding environment
>
> Below are the flags i us
I recommend creating a different name for your own memcpy() implementation,
and use that. You may also make it configurable which implementation to use.
On Thu, Apr 17, 2025, 08:51 Wasim Khan via Gcc-help
wrote:
> Hi,
>
> I have a custom implementation of memcpy() function and don't want to use
Hi, sorry for bumping this again
I forgot to mention that Windows inlining, from what I remember, was
ok before gcc 14 landed. It seemed that only once gcc 14 came about
that the insane inlining started happening. This might point to the
inlining heuristics having changed, but unfortunately gcc 13
Hi Jonathan,
Thanks for the suggestion, it seems promising. I switched out the
error attribute for the warning attribute at first, since they should
be equivalent except warning just warns instead of erroring. This
results in the link step failing if LTO is enabled for some reason
though. I then c
Hi,
On Mon, Apr 14, 2025 at 09:51:50PM +, justin.colon--- via Gcc wrote:
> Hello GCC and GNU support, I am the proxy service lead for Lockheed
> Martin and something seems to be blocking our traffic when our US
> users try to reach https://gcc.gnu.org/onlinedocs/. Our Non-US users
> do not hav
vior of a C ++ program is
undefined if it adds declarations or definitions to namespace std or
to a namespace within namespace std."
But ::malloc is not in namespace std, so that rule doesn't apply. But
that's arguably a defect in the standard caused by forgetting that
std::malloc m
On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
>
> Hi Jonathan,
>
> Yep, unfortunately #pragma GCC poison is far too restrictive, it
> doesn't check if it is a function call to that particular banned
> function, it restricts any and all use of that identifier in the code
> altogether. Not only
On Mon, 14 Apr 2025 at 12:57, Jonathan Wakely wrote:
>
> On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
> >
> > Hi Jonathan,
> >
> > Yep, unfortunately #pragma GCC poison is far too restrictive, it
> > doesn't check if it is a function call to that particular banned
> > function, it restricts
Hi Jonathan,
Yep, unfortunately #pragma GCC poison is far too restrictive, it
doesn't check if it is a function call to that particular banned
function, it restricts any and all use of that identifier in the code
altogether. Not only does this mean you can't use overloads of a
banned function, you
On Mon, 14 Apr 2025 at 10:11, Julian Waters via Gcc wrote:
>
> Hi all,
>
> A codebase I'm working with has decided that poisoning certain
> standard library functions is necessary, as it explicitly does not use
> those functions unless absolutely necessary for its own reasons (This
> was not my de
Hi,
On Wed, Nov 27, 2024 at 05:35:00PM +0100, Mark Wielaard via Overseers wrote:
> After lots of discussions at some of our Open Office hours, at the
> Cauldron, with other Software Freedom organizations and some of our
> hardware and services providers we now have a Sourceware Cyber Security
> FA
Dear Peeyush,
On Wed, Apr 09 2025, Peeyush Maurya via Gcc wrote:
> Dear Professor Burnus and the Fortran Project Team,
>
> I am writing to sincerely apologize for my late submission of the proposal
> for the “Fortran – 2018/202x” project. I understand that the deadline was
> April 8th, and I regre
Thank you for trying.
Also if possible can I receive any guidance for next year hopefully. Since
I am new and am learning things.
If possible any guidance would be helpful for my growth
Though I like to work for GCC more are there any other ways which can help
me to contribute.
Thanks for the respo
Thank you for your detailed explanation of "dummy parameter" !
>It is still unclear to me what you are trying to accomplish.
>Implicit typying and implicit interfaces are a compile-time
>thing.
...
>An -fcheck=implicit-type option that generates a runtime
>error that does not make sense to m
Thanks a lot, Andi!
I’ve submitted the final version of the proposal on the GSoC platform. I
really appreciate your feedback, as well as the input from everyone who
took the time to review and help refine the idea. It made a significant
difference.
I hope for the opportunity to contribute to GCC
On Mon, Apr 07, 2025 at 02:42:10PM +0800, Gwen Fu wrote:
> Thanks for your reply !
> >The word "parameter" has very a specific meaning in Fortran. The
> >entity that is passed into a function or subroutine is an "actual
> >argument". The entity within the functions associated with the
> >"actual ar
Hello
Apologies for sending my draft proposal so close to the deadline. You
can find it here:
https://docs.google.com/document/d/1UL-mGDWyfEjne3f6uEZOI5KG4s9XTP53QZ_LJjoqn-s/edit?usp=sharing
Please share any comments or suggestions you might have. If any
section needs more clarity, do let me know,
Thanks for your reply !
>The word "parameter" has very a specific meaning in Fortran. The
>entity that is passed into a function or subroutine is an "actual
>argument". The entity within the functions associated with the
>"actual argument" is a "dummy argument".
Can I understand "dummy parameters"
Hi Thomas,
Some updates here.
After some research, I realized that the nouveau driver may not be
sufficient for our workload, so the nvidia drivers are a must, along with
the CUDA toolchain. Fortunately, I got the drivers to work under Debian
when I disabled Secure Boot in the firmware. So we're
On Sat, Apr 05, 2025 at 03:16:45PM +0800, Gwen Fu wrote:
> My doubt :
> 1.Does the compilation option only need to support fortran versions above
> 9, o5r does it also need to support fortran 77?
gfortran started life as a Fortran 95 compiler. It should
support anything that is Fortran 95 or late
On 2025-04-06 10:46, Eldar Kusdavletov wrote:
Thanks, Andi — I’ve updated the proposal to reflect your feedback,
especially around separating frontend and backend phases. I now
describe the backend instrumentation as building on existing
per-function timevars and focusing on trace formatting and
On Mon, Mar 31, 2025 at 3:14 PM Julian Waters wrote:
>
> Thanks for the quick reply, I'll ask the people responsible for
> working on the Linux parts try to compile and link the codebase with
> -fno-use-linker-plugin to see what happens. It's a bit disheartening
> to hear that LTO support on Windo
On Mon, Mar 31, 2025 at 11:14:47PM +0300, Eldar Kusdavletov wrote:
> I wanted to follow up on my previous email regarding my interest in
> participating in Google Summer of Code with GCC. I saw the discussion in the
> thread, but it seems there was no final confirmation.
>
> Could you please let m
On 3/19/25 4:14 AM, Georg-Johann Lay wrote:
Am 16.03.25 um 14:51 schrieb Jeff Law via Gcc:
On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:
There are situations where knowledge about which bits
of a value are (not) set can be used for optimization.
For example in an insn combine pattern l
On Fri, Apr 4, 2025 at 12:17 AM Robert Dubner wrote:
>
> The COBOL compiler has this routine:
>
> void
> gg_exit(tree exit_code)
> {
> tree the_call =
> build_call_expr_loc(location_from_lineno(),
> builtin_decl_explicit (BUILT_IN_EXIT),
>
Am 21.03.25 um 19:16 schrieb Georg-Johann Lay via Gcc:
Am 21.03.25 um 01:02 schrieb Jeff Law:
On 3/19/25 4:14 AM, Georg-Johann Lay wrote:
Am 16.03.25 um 14:51 schrieb Jeff Law via Gcc:
On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:
There are situations where knowledge about which bits
of
Hi,
> Let us know if you need further help; we understand it's not trivial to
get this set up at first.
Sure! To be honest, I haven't had time to completely set up the toolchain
yet (due to classes and ongoing mid-semester examinations). I plan to
finish it as soon as I get some time. I have set
Hi Pau!
On 2025-03-19T21:53:22-0400, Pau Sum via Gcc wrote:
> Hey GCC Community,
Welcome to GCC!
> I am interested in contributing to the "Enhance OpenACC Support" project for
> Google Summer of Code 2025.
Thanks for your interest!
I saw you also briefly discussed on GCC IRC. I'm logged in,
> You can see what -fuse-linker-plugin says, what gcc/auto-host.h contains
> for HAVE_LTO_PLUGIN. I don't know whether the BFD linker (or mold)
> supports linker plugins on windows. I do know that libiberty simple-object
> does not support PE, that is, at _least_ (DWARF) debuginfo will be subpar.
Hello,
and sorry for a somewhat late reply.
On Fri, Mar 28 2025, Ansh Jaiswar via Gcc wrote:
> Dear GCC Developers,
>
> I am Ansh Jaiswar , a second-year Computer Science student interested in
> compilers and systems programming. I have experience with C/C++ and basic
> knowledge of Rust.
>
> I
On Fri, Apr 04, 2025 at 07:21:47AM +0300, Eldar Kusdavletov wrote:
> Thanks. I’ve submitted a more concrete version of the proposal — attaching it
> here.
>
> I’ve taken a brief look at Clang’s implementation, but the idea isn’t to
> follow
> it exactly — rather, to provide a similar kind of trac
On 23/03/2025 20:26, Toon Moene wrote:
> I had the following message when sending test results to gcc-testresults
> *starting* today (3 times):
>
> Note that the message is generated by *my* exim4 "mail delivery software"
> (Debian Testing) - it is not the *receiving* side that thinks the lines
Hi Arijit, Andrew!
Arijit, welcome to GCC!
On 2025-03-11T03:26:44+0530, Arijit Kumar Das via Gcc wrote:
> Thank you for the detailed response! This gives me a much clearer picture
> of how things work.
>
> Regarding the two possible approaches:
>
>- I personally find *Option A (self-containe
On Thursday, April 3rd, 2025 at 10:45 PM, Andi Kleen
wrote:
>
>
> On Fri, Apr 04, 2025 at 07:21:47AM +0300, Eldar Kusdavletov wrote:
>
> > Thanks. I’ve submitted a more concrete version of the proposal — attaching
> > it
> > here.
> >
> > I’ve taken a brief look at Clang’s implementation, b
On Mon, Mar 31, 2025 at 1:20 PM Julian Waters via Gcc wrote:
>
> Hi all,
>
> I've been trying to chase down an issue that's been driving me insane
> for a while now. It has to do with the flatten attribute being
> combined with LTO. I've heard that flatten and LTO are a match made in
> hell (Someo
Hi,
On Wed, Apr 02 2025, Leul Abiy via Gcc wrote:
> Dear Sir/Madam,
>
> I would like to work on the rust frontend for this summer.
We are delighted you found contributing to GCC interesting.
> I am trying to
> break down all the steps for the first project in the rust frontend. So far
> I plan o
To: Robert Dubner
> Cc: GCC Mailing List
> Subject: Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> optimized away.
>
> On Fri, Apr 4, 2025 at 3:35 PM Richard Biener
> wrote:
> >
> > On Fri, Apr 4, 2025 at 3:06 PM Robert Dubner wrote:
> > >
>
t reading from a unsigned char
declaration. Since the
declaration __gg__data_return_code is just 1 byte the 2-byte store
cannot possibly alias it.
Richard.
> Richard.
>
> >
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Friday, April 4, 2
1 - 100 of 63377 matches
Mail list logo
