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 regret not meeting the required timeline.
Due to unforeseen circumstances, I
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
> A
response at least.
On Wed, 9 Apr 2025, 7:39 pm Martin Jambor, wrote:
> 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
>
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 regret not meeting the required timeline.
Due to unforeseen circumstances, I
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
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"
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
you please let me know if everything is in order and whether I can
> proceed with submitting my application? I would really appreciate any guidance
> on the next steps.
It might be useful if you write a more concrete proposal
that stands by itself, and not just says "it's like c
to ‘--help=’ option: ‘check’
So Is this related to the project ?
Here is my proposal draft (importran part )
Parameter Mismatch Implicit Declaration Features of Fortran 77
I think this is the reason why parameter mismatch may occur
In *Fortran 77*, *Implicit Typing* is a variable type automatic
Hi GCC developers,
I'm sharing the draft proposal for my GSoC project titled "Fortran 2018/202x".
It has already been posted on the Fortran mailing list, where I received
valuable feedback from gfortran developers.
As mentioned on the GCC GSoC page, proposals should also be sh
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
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 ta
>
> This expands on implementation details, compares different approaches
> (in-memory vs. RPC-based solutions), and identifies relevant GCC components
> to modify.
>
> 1. Overview of Implementation Approaches
>
> Currently, GCC’s GPU offloading test framework lacks support for file I/O,
> causing
Hi Ambika!
Welcome to GCC!
On 2025-03-29T15:26:18-0500, Ambika Sharan via Gcc wrote:
> Simple File System for Nvidia and AMD GPU Code Generation Testing
Thanks for your interest, and initial work on this project idea.
Please add more detail: ideas how you think you'd implement the
respective
*Dear GCC Mentoring Team,*
> >> I am writing to submit my proposal for the Google Summer of Code (GSoC)
> >> 2025 program, aiming to contribute to the GCC project by implementing a
> >> feature similar to Clang's -ftime-trace. This feature generates
> performance
>
Simple File System for Nvidia and AMD GPU Code Generation Testing
2. Project Description and Goals
-
This project aims to enhance the GCC testing framework for GPU-targeted
code generation by developing a simple "in-memory" file system or an RPC
mechanism for devices to access host f
Jakub Jelinek via Gcc writes:
> On Tue, Mar 25, 2025 at 07:21:32AM +0300, Eldar Kusdavletov via Gcc wrote:
>> *Dear GCC Mentoring Team,*
>> I am writing to submit my proposal for the Google Summer of Code (GSoC)
>> 2025 program, aiming to contribute to the GCC proj
On Tue, Mar 25, 2025 at 07:21:32AM +0300, Eldar Kusdavletov via Gcc wrote:
> *Dear GCC Mentoring Team,*
> I am writing to submit my proposal for the Google Summer of Code (GSoC)
> 2025 program, aiming to contribute to the GCC project by implementing a
> feature similar to Clang&#x
*Dear GCC Mentoring Team,*
I am writing to submit my proposal for the Google Summer of Code (GSoC)
2025 program, aiming to contribute to the GCC project by implementing a
feature similar to Clang's -ftime-trace. This feature generates performance
reports detailing the compiler's time di
Title: Type-Based Alias Analysis in GCC using TySan
Overview
Both LLVM and GCC share a common sanitizer library called libsanitizer.
Recently, libsanitizer has introduced support for Type-Based Sanitization
(TySan). The goal of this project is to investigate and prototype the use of
type-based
GCC. I am
> writing to discuss THIS PROJECT("Fortran – run-time argument checking")
> idea and seek your feedback before submitting my formal proposal.
>
> [My Background]
>I am a computer science sophomore at Harbin Engineering University,
> with experience in C/C++ prog
For some C++26 language features listed on
https://gcc.gnu.org/projects/cxx-status.html
there are newer proposal revisions available:
Remove undefined behavior from lexing P2621R3 <https://wg21.link/P2621R3>
constexpr structured bindings and references to constexpr variables P2686R5
my formal proposal.
[My Background]
I am a computer science sophomore at Harbin Engineering University,
with experience in C/C++ programming, GDB debugging experience and
Experience in programming under the Linux environment. I have manually
implemented an HTTP server based on the Reactor pa
Hello,
On Fri, Apr 05 2024, PRANIL DEY wrote:
> Hello GCC Community,
> I am Pranil Dey and I had submitted a proposal for the project "Improve
> nothrow detection in GCC", but as the deadline period was a holiday time I
> wanted to ask you to review my proposal now.
Hello GCC Community,
I am Pranil Dey and I had submitted a proposal for the project "Improve
nothrow detection in GCC", but as the deadline period was a holiday time I
wanted to ask you to review my proposal now.
I am already getting familiar with the code but I wanted some pointers fo
Thank you Martin!
I've taken your advice into account and I've uploaded my proposal.
On Sat, Mar 30, 2024 at 1:49 PM Martin Jambor wrote:
> Hello,
>
> On Wed, Mar 27 2024, Soumya Ranjan wrote:
> > Hello!
> > Thanks for your response Martin!
> > Sorry for the
Hello,
On Wed, Mar 27 2024, Soumya Ranjan wrote:
> Hello!
> Thanks for your response Martin!
> Sorry for the late response, I've been researching the project, going over
> the source code and preparing the proposal. After a lot of thought, I've
> decided to go with the
in
> GFortran has limitations in handling locality clauses, supporting reduction
> operations, and parallelization strategies for DO CONCURRENT loops. So the
> proposal aims to address these limitations:
timing of the GSoC contributor application deadline (on the upcoming
Tuesday) is a
Hello!
Thanks for your response Martin!
Sorry for the late response, I've been researching the project, going over
the source code and preparing the proposal. After a lot of thought, I've
decided to go with the "Offloading to a separate process on the same host"
project, mostly
ction
operations, and parallelization strategies for DO CONCURRENT loops. So the
proposal aims to address these limitations:
1. Implementing locality clauses and ensuring correct handling of data
dependencies.
2. Supporting reduction operations in DO CONCURRENT loops.
3. Devel
ot;
>> devroom
>> as well as a "Debugger and analysis tools" devroom for FOSDEM 2024.
>>
>> We still need two volunteers to submit a proposal for a "GCC &
>> runtime
>> libraries" devroom. The deadline for the devroom requests is 16
> > to
> > help out with that.
>
> So, José, Guinevere and myself have requested a "Binary Tools"
> devroom
> as well as a "Debugger and analysis tools" devroom for FOSDEM 2024.
>
> We still need two volunteers to submit a proposal for a &qu
ot; devroom
as well as a "Debugger and analysis tools" devroom for FOSDEM 2024.
We still need two volunteers to submit a proposal for a "GCC & runtime
libraries" devroom. The deadline for the devroom requests is 16 October
2023: https://fosdem.org/2024/news/2023-09-29-devro
Hi.
Thanks for fast reply. I will check this, because I didn't know that.
BR,
Jakub
On 10.06.2023 20:12, Jakub Jelinek wrote:
On Sat, Jun 10, 2023 at 07:51:10PM +0200, Jakub Juszczakiewicz via Gcc wrote:
Hi all,
I don't know is here right place for sharing ideas, but I don't have
ide
On Sat, Jun 10, 2023 at 07:51:10PM +0200, Jakub Juszczakiewicz via Gcc wrote:
> Hi all,
>
> I don't know is here right place for sharing ideas, but I don't have
> idea, where I can send it.
> I have simple idea. When I turned on OpenMP, for parallelly execute simple
> for it's enough when I ad
Hi all,
I don't know is here right place for sharing ideas, but I don't
have idea, where I can send it.
I have simple idea. When I turned on OpenMP, for parallelly execute
simple for it's enough when I add line like this before loop:
#pragma omp parallel for
for (size_t i = 0; i < 100
>
> > > We could even try an analysis mode where we split the analysis
> > > path at
> > > a vfunc call, where we could create an out-edge in the egraph for
> > > each
> > > known concrete subclass for foo *, so that we can consider all
> > >
Sorry, I messed subject in my previous two emails :( so I am sending it
again.
I have completed a draft proposal for this project. I will appreciate Jan,
Martin, or anybody else feedback on the same.
Here is the link to my proposal
https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG
(I'm not sure
>> if this is a *good* idea, but it intrigues me)
>>
>
> Like adding a flag to run in a non-standard mode, to debug when an
> unexpected vfunc analysis occurs ? TBH I didn't look that much into vfuncs
> support, as my dummy tests behave OK and I assumed it w
de, to debug when an
unexpected vfunc analysis occurs ? TBH I didn't look that much into vfuncs
support, as my dummy tests behave OK and I assumed it was fixed after last
GSoC.
>
> >
> > Unfortunately I couldn't devote as much time as I wanted to gcc
> > yesterd
, I see what you mean now. Thanks for clarifying!
> >
> >
> > > Yeah, this sounds like a big project. Fortunately there are a lot
> > > of
> > > possible subtasks in this one, and the project has benefits to GCC
> > > and
> > > to CPython even
with the theory
> of this than I am!)
I was not ware of `-Wanalyzer-too-complex` when I wrote that proposal, and I
forgot to rewrite this part. I planned to ask you why we did not turn on this
flag by default. To avoid state explosion altogether, it is for sure that we
need to bear with f
or clarifying!
>
>
> > Yeah, this sounds like a big project. Fortunately there are a lot
> > of
> > possible subtasks in this one, and the project has benefits to GCC
> > and
> > to CPython even if you only get a subset of the ideas done in the
> > time
On Sun, 2023-04-02 at 17:24 +, Sun Steven via Gcc wrote:
> Hi, Eric, Malcom,
Hi - and welcome to the GCC community.
>
> Sorry that I didn't check this thread before.
>
> It sounds like there are a lot of things to do. I want to offer some
> help.
>
> Let me add some backgrounds of memory m
d the state-purging code so that it
> > > somehow
> > > "sees" that "extra" gets clobbered before it gets used, and thus
> > > we can
> > > purge the tainted state from it.
> >
> > Thanks for your notes. I think we may be talkin
Hi, Eric, Malcom,
Sorry that I didn't check this thread before.
It sounds like there are a lot of things to do. I want to offer some help.
Let me add some backgrounds of memory management in python here.
## Intro (for people unfamiliar with CPython)
Unlike programs written in C++, where the c
CPython even if you only get a subset of the ideas done in the time
> available (refcount checking being probably the highest-value subtask).
Sounds good.
I refactored the project description and timeline sections of the
proposal according to our conversation. Notably, I moved format string
checking to
sed.
>>
>> So one fix might be to extend the state-purging code so that it somehow
>> "sees" that "extra" gets clobbered before it gets used, and thus we can
>> purge the tainted state from it.
>
> Thanks for your notes. I think we may be talking ab
k for walking
global initializers (hopefully easy),
etc.
>
> > > Errors in exception-handling: Checks for situations in which
> > > functions
> > > returning PyObject* that is NULL are not gracefully handled.
> >
> > Yes; detection of this would automat
task. Please correct me if my understanding here is
wrong.
> > Errors in exception-handling: Checks for situations in which
> > functions
> > returning PyObject* that is NULL are not gracefully handled.
>
> Yes; detection of this would automatically happen if we implemented
t;
> So one fix might be to extend the state-purging code so that it somehow
> "sees" that "extra" gets clobbered before it gets used, and thus we can
> purge the tainted state from it.
Thanks for your notes. I think we may be talking about the same thing? If you
look
nalyzer.exp).
>
> Just by looking at these test files, it seems that it may have to do
> with how the analyzer does path selection, because there are many
> nested conditionals in these two files. As I mentioned in the
> proposal, it would be curious if this state explosion only happ
s path selection, because there are many nested conditionals in
these two files. As I mentioned in the proposal, it would be curious if this
state explosion only happens for taint analysis, because I don’t think there is
anything special about taint analysis that would cause state exp
stem, so much of it now lives on in C++ form as core
GCC functionality. Also, the Python community would continue to find
static analysis of CPython extension modules useful, so it would be
good to have the idea live on as a GCC plugin on top of -fanalyzer.
> Please find an
> initial draft
gi?id=107646. Please find an
initial draft of my proposal below and let me know if it is a
reasonable starting point. Please also correct me if I am
misunderstanding any particular tasks and let me know what areas I
should add more information for or what else I may do in preparation.
___
Describ
There is my GSOC 2023 Proposal about the Metadata Exports project please
review it and let me know what you guys think about it??
GSOC Proposal for Metadata Exports in Rust-GCC by Parthib Datta.docx
Description: MS-Word 2007 document
On Mon, 2023-03-20 at 18:28 +0100, Shengyu Huang wrote:
> Hi Dave,
>
> Thanks for always getting back to me so promptly! I am drafting the
> proposal today. Here is the link:
>
> https://docs.google.com/document/d/1MRI1R5DaX8kM6DaqRQsEri5Mx2FvHmWv13qe1W0Bj0g/
>
> (The pr
Hi Dave,
Thanks for always getting back to me so promptly! I am drafting the proposal
today. Here is the link:
https://docs.google.com/document/d/1MRI1R5DaX8kM6DaqRQsEri5Mx2FvHmWv13qe1W0Bj0g/
(The proposal was first written in markdown and then copied pasted to Google
Docs, so some formatting
y you or not big enough
> to make a GSoC project, I decided to take on this project and have
> been getting familiar with the analyzer this weekend.
Excellent; thanks.
> I want to sort several things out before writing the proposal.
>
> 1. What should I do with the integration tests?
r replying to you late due to another project from my university.
Since most other ideas are being worked on by you or not big enough to make a
GSoC project, I decided to take on this project and have been getting familiar
with the analyzer this weekend. I want to sort several things out before
w
On Tue, 2023-02-28 at 15:46 +0100, Shengyu Huang wrote:
> Hi Dave,
>
> > On 22 Feb 2023, at 15:11, Shengyu Huang
> > wrote:
> >
> > > But a better place to look would probably be in our bugzilla; see
> > > the
> > > links on the wiki page:
> > > https://gcc.gnu.org/wiki/StaticAnalyzer
> > > Th
Hi Dave,
> On 22 Feb 2023, at 15:11, Shengyu Huang wrote:
>
>> But a better place to look would probably be in our bugzilla; see the
>> links on the wiki page:
>> https://gcc.gnu.org/wiki/StaticAnalyzer
>> The "open bugs" list currently has 41 "RFE" bugs ("request for
>> enhancement" i.e. idea
Hi Ben,
Thanks for your feedback. The original problem I was trying to solve is to do
such deduction in my own project where I use self-written wrapper around libpq,
so naturally I'm not concerned if I'll be writing in pure C++ or C++ dialect.
Actually, I tried to come up with a solution which m
On Thu, Jul 14, 2022 at 18:46:47 +0200, Dan Klishch via Gcc wrote:
> As far as I understand the currently available plugin extension points, it is
> not possible to modify template argument deduction algorithm (except the
> theoretical possibility to completely override parsing step). However, such
Hi,
As far as I understand the currently available plugin extension points, it is
not possible to modify template argument deduction algorithm (except the
theoretical possibility to completely override parsing step). However, such
opportunity might be beneficial for projects like libpqxx, for exam
Richard Biener writes:
> I suggest you post merge patches where the branch touches generic code
> for review again, indicating parts that have been approved in the
> past.
Hello Richard, David and the GCC Steering Committee,
Firstly thank you for the release of gcc-12.1 and secondly thank you
f
Richard Biener writes:
>> Am 14.05.2022 um 00:57 schrieb Gaius Mulley via Gcc :
>>
>>
>> Hi David,
>>
>> David Edelsohn writes:
>>
>>> I hope that you and the GNU Modula-2 team can propose the merge of the
>>> Modula-2 front-end and library soon.
>>
>> [reposting with a new title for maili
> Am 14.05.2022 um 00:57 schrieb Gaius Mulley via Gcc :
>
>
> Hi David,
>
> David Edelsohn writes:
>
>> I hope that you and the GNU Modula-2 team can propose the merge of the
>> Modula-2 front-end and library soon.
>
> [reposting with a new title for mailing list clarity]
>
> Yes I was a
Hi David,
David Edelsohn writes:
> I hope that you and the GNU Modula-2 team can propose the merge of the
> Modula-2 front-end and library soon.
[reposting with a new title for mailing list clarity]
Yes I was also wondering whether now might be a sensible time for the
Modula-2 front end to m
x27;m about to go on a week-long trip, and will be away from the
computer during that time, so I probably won't be able to reply further
before the application deadline.
Hope this is helpful
Dave
>
>
>
> On Fri, Apr 15, 2022 at 9:35 PM David Malcolm
-GCC.
I have included the draft of my project proposal here
<https://docs.google.com/document/d/1JEEpLc_rYDWrpwPwt-EavbBO01N3n5PfMwmjqdiJ9yM/edit?usp=sharing>.
I would be grateful for any suggestions you have regarding it and will try
to implement them in my final submission.
Thank you.
M V V S
d working wiith FDs?
Thank you.
On Fri, Apr 15, 2022 at 9:35 PM David Malcolm wrote:
> On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> > I've submitted a proposal for extending the static analyzer to support
> > posix fd APIs on GSoC website. Here is the Google
On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> I've submitted a proposal for extending the static analyzer to support
> posix fd APIs on GSoC website. Here is the Google docs link (gdocs
> <
> https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7
I've submitted a proposal for extending the static analyzer to support
posix fd APIs on GSoC website. Here is the Google docs link (gdocs
<https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7374/edit?usp=sharing>).
Please take a look and let me know what you th
ntrary to how
For all existing qualifiers, the rules about discarding are rules about
permitted assignments (and conversions as if by assignment) between
pointers and concern the qualifiers on pointer target types: 6.5.16.1 is
the key subclause concerning implicit conversions, and any pro
On 12/2/21 21:24, Alejandro Colomar (man-pages) wrote:
#define nonnull_assign(nn, p) \
({ \
auto p_ = p; \
auto nn_ = nn; \
On 11/16/21 13:34, Alejandro Colomar (man-pages) wrote:
$ cat _Nonnull.c
#include
int *_Nonnull f(int *_Nullable p)
{
if (!p)
exit(1);
return p;
}
int *_Nonnull g(int *_Null_unspecified p)
{
return p;
}
int *_Nonnull h(int *p)
{
return p;
}
int *_Nullable i(in
Hi Dmitri
On 12/2/21 01:39, Dmitri Gribenko wrote:
Pre-C3X headers won't work correctly when included in C3X programs,
making incremental adoption of C3X syntax, as it was intended to be
used, impossible. Projects would likely invent a NULLABLE macro, which
would expand to _Nullable in C3X and n
Hi Alejandro,
On Wed, Dec 1, 2021 at 11:24 PM Alejandro Colomar (man-pages)
wrote:
> On 11/23/21 13:45, Dmitri Gribenko wrote:
> > If I were to speculate what would happen if C3X did flip the default,
> > I think it would be treated by the community as a language fork.
>
> Yes
>
> > Pre-C3X heade
hecking rules, you would get a warning on the `q = p` assignment
> regardless of the `if (!p)` check. That's how the C type system works,
> it is not flow-sensitive.
>
> If we want the diagnostics to be fllow-sensitive like in your example
> (I think it would be the best choi
check. That's how the C type system works,
it is not flow-sensitive.
If we want the diagnostics to be fllow-sensitive like in your example
(I think it would be the best choice), then we need to add a new
flow-sensitive component to the C type system. I don't think there is
a precedent for this in C right now. I'm not sure how the committee or
implementors would react to such a proposal.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
Hi Dmitry,
On 11/23/21 12:17, Dmitri Gribenko wrote:
Hi Alejandro,
On Tue, Nov 16, 2021 at 1:34 PM Alejandro Colomar (man-pages) via
cfe-dev wrote:
First of all,
I see unnecessary (probably over-engineered) qualifiers:
- _Null_unspecified seems to me the same as nothing.
If I didn't specify
ang document that talks about something similar.
> >I don't know its validity,
> >or if it was a draft before _Nonnull qualifiers.
> ><https://clang.llvm.org/docs/analyzer/developer-docs/nullability.html>
>
> That document suggests that I shouldn't get a dia
Hi Alejandro,
On Tue, Nov 16, 2021 at 1:34 PM Alejandro Colomar (man-pages) via
cfe-dev wrote:
> First of all,
> I see unnecessary (probably over-engineered) qualifiers:
>
> - _Null_unspecified seems to me the same as nothing.
> If I didn't specify its nullability,
> it's by definition unspecifie
nostic from f().
Why did I get a diagnostic? (I tried clang 11, 13 & 14(experimental))
Is it talking about a different nonnull attribute/qualifier?
Was it about a proposal prior to the current _Nonnull?
Why is it not in use? Was it too difficult to implement?
Do you think Clang could be i
, 13 & 14(experimental))
Is it talking about a different nonnull attribute/qualifier?
Was it about a proposal prior to the current _Nonnull?
Why is it not in use? Was it too difficult to implement?
Do you think Clang could be improved to not warn on f()?
Thanks,
Alex
On Tue, Nov 16, 2021 at 4:31 AM Jonathan Wakely via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Mon, 15 Nov 2021, 21:15 Alejandro Colomar (man-pages)
> wrote:
>
>> Also, I'm curious, do you do those diffs usually by hand?
>>
>
> Yes. Just highlight text in red and green, with strike through or
this
variant with a runtime check for NULL.
Note that discussion of prior art in such a proposal should also consider
relevant prior art (for constraining possible values of a variable through
the type system) in C++ or other languages if possible.
The only other language that I know is C++, so I&#
On Mon, 15 Nov 2021, 21:15 Alejandro Colomar (man-pages)
wrote:
> My intention is that the final PDF to be sent to the committee
> will have those diffs.
> But I have no clue of how to do that kind of things,
> so for an initial draft to discuss on,
> before even presenting it to the committee,
>
converting a normal pointer to this
variant with a runtime check for NULL.
Note that discussion of prior art in such a proposal should also consider
relevant prior art (for constraining possible values of a variable through
the type system) in C++ or other languages if possible.
--
Joseph S. Myers
jos...@codesourcery.com
Hi Joseph,
On 11/15/21 23:17, Joseph Myers wrote:
On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote:
How is restrict handling that problem of lvalue-to-rvalue already?
restrict has tricky rules about "based on" (6.7.3.1).
Hmm, I think I can "base on" that,
to define what I h
On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote:
> How is restrict handling that problem of lvalue-to-rvalue already?
restrict has tricky rules about "based on" (6.7.3.1).
--
Joseph S. Myers
jos...@codesourcery.com
Hi Joseph,
On 11/15/21 21:18, Joseph Myers wrote:
lvalue-to-rvalue conversion loses qualifiers, which makes any rules based
on whether the RHS of an assignment was nonnull-qualified very
problematic. (The specification of restrict is exceedingly tricky and
very unlikely to be a good basis for s
lvalue-to-rvalue conversion loses qualifiers, which makes any rules based
on whether the RHS of an assignment was nonnull-qualified very
problematic. (The specification of restrict is exceedingly tricky and
very unlikely to be a good basis for specifying any other feature.)
I don't think a man
#x27;d like to get some feedback from GCC and Clang,
> before sending it as an official proposal.
>
> BTW, since the working group is probably very busy with C2X,
> I may delay sending it more than a year.
> Or I may propose it first to ISO C++,
> and then to ISO C.
>
> I wro
Hi all,
I'd like to propose the following feature for ISO C (and also ISO C++).
It is based on a mix of GCC's [[gnu::nonnull]] and Clang's _Nonnull,
with a pinch of salt of mine.
I'd like to get some feedback from GCC and Clang,
before sending it as an official proposal.
BT
1 - 100 of 1090 matches
Mail list logo
