Fwd: Contribution

[farhad via Gcc]

TO whom it may concern,
I'm Farhad Sarvari and I have been working as a software engineer for more
than 10 years and also have a strong background in c++ programming language.
In addition I wrote a book about modern C++.
  I want to contribute to GCC
development. It would be great if you provide more detail about how i can
contribute.
Thanks in advance. I'm looking forward to hearing from you.

Best regards,
Farhad

-- 
sent by Farhad


-- 
sent by Farhad

Re: Contribution

[David Edelsohn via Gcc]

On Mon, Mar 14, 2022 at 4:37 AM farhad via Gcc  wrote:
>
> TO whom it may concern,
> I'm Farhad Sarvari and I have been working as a software engineer for more
> than 10 years and also have a strong background in c++ programming language.
> In addition I wrote a book about modern C++.
>   I want to contribute to GCC
> development. It would be great if you provide more detail about how i can
> contribute.
> Thanks in advance. I'm looking forward to hearing from you.

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

and browse other recent answers to similar questions in the archives
of this mailing list.

Thanks, David

>
> Best regards,
> Farhad
>
> --
> sent by Farhad
>
>
> --
> sent by Farhad

Announcement: gcobol

[James K. Lowden]

https://git.symas.net:443/cobolworx/gcc-cobol/
https://github.com/Apress/beg-cobol-for-programmers

Greetings, gcc!  We come bearing gifts! 

When you set your clock ahead an hour yesterday, you might not have
realized you set your calendar back to 1985.  There's a new gcc COBOL
compiler. We call it: gcobol.

On the books, we have 1 man-year invested: two full-time
programmers since October 2021.

We have so far compiled just over 100 programs from the examples in
"Beginning COBOL for Programmers", by Michael Coughlin. We are near the
end of that phase of the project, and expect to have ISAM and
Object-Oriented Cobol features implemented in the next few weeks.  We
are working on compiling the NIST COBOL test suite, which we expect
will take a few months to complete.  We have begun work on  gdb, too,
and hope to have it working by year end. 

Our project should not be confused with GnuCOBOL
(https://savannah.gnu.org/projects/gnucobol).  That project is a Cobol
translator: it compiles Cobol to C, and invokes gcc to produce
executable code.  Our gcobol compiler is (currently) a fork of gcc.  It
implements a gcc frontend for Cobol and (obviously) invokes the gcc
backend to produce executables.  (We have a friendly relationship with
GnuCOBOL, and its maintainer supports our undertaking.)

Ours should also not be confused with prior efforts to create a gcc
Cobol compiler.  Others have tried and failed.  Failure wasn't an
option for us.  I won't say it was easy, but here we are. 

Eventually, if the gcc maintainers are interested, we would like to
pursue full integration with gcc.  For the moment, we have questions
we're hoping can be answered here by those who ran the gauntlet
before us.  Given the state of the internals documentation, that seems
like our best option. We've been rummaging around in the odd sock
drawer for too long.  

If you're like me (like I was), your visceral response to this
announcement can be summed up in one word: Why?

The answer is as easy as it is trite: the right tool for the job.

I wouldn't write an operating system in Cobol.  But I wouldn't write
one in Python or Java, either.  Cobol has a niche no other language
occupies: a compiled language for record-oriented I/O.  

That might sound strangely specialized, but it's not.  Record-oriented
I/O describes, I would argue, nearly *all* applications.  Yet, since the
advent of C, nearly all applications have relegated I/O to an external
library, and adopted the Unix byte-stream definition of a "file".

If you've written a CGI web application, you know what I'm talking
about.  Cobol eliminates a lot of gobbledygook by reducing free-form
run-time variables to compile-time constants.

That's the rationale, and it's not just a theory.  Cobol is alive and
kicking.  Estimates vary, but they all say north of 100 billion lines
of Cobol are still in use, with millions more written every year, even
now, in the 21st century.  Odds are your last ATM transaction or credit
card purchase went through a Cobol application.

There's another answer to Why: because a free Cobol compiler is an
essential component to any effort to migrate mainframe applications to
what mainframe folks still call "distributed systems".  Our goal is a
Cobol compiler that will compile mainframe applications on Linux.  Not
a toy: a full-blooded replacement that solves problems.  One that runs
fast and whose output runs fast, and has native gdb support.

I am happy to debate the lunacy of this project and the viability of
Cobol, either here or off-list.  Today, we want to make the project
known to those in the technical community who might most want to know
what we're up to, and explain why we'll be asking the questions we're
asking.  

Also, if you want to give it a whirl, please don't hesitate.  We're
happy to help, and expect to learn something in the process. 

Thank you for you kind attention.

--jkl

Re: Announcement: gcobol

[David Edelsohn via Gcc]

On Mon, Mar 14, 2022 at 4:35 PM James K. Lowden
 wrote:
>
> https://git.symas.net:443/cobolworx/gcc-cobol/
> https://github.com/Apress/beg-cobol-for-programmers
>
> Greetings, gcc!  We come bearing gifts!
>
> When you set your clock ahead an hour yesterday, you might not have
> realized you set your calendar back to 1985.  There's a new gcc COBOL
> compiler. We call it: gcobol.
>
> On the books, we have 1 man-year invested: two full-time
> programmers since October 2021.
>
> We have so far compiled just over 100 programs from the examples in
> "Beginning COBOL for Programmers", by Michael Coughlin. We are near the
> end of that phase of the project, and expect to have ISAM and
> Object-Oriented Cobol features implemented in the next few weeks.  We
> are working on compiling the NIST COBOL test suite, which we expect
> will take a few months to complete.  We have begun work on  gdb, too,
> and hope to have it working by year end.
>
> Our project should not be confused with GnuCOBOL
> (https://savannah.gnu.org/projects/gnucobol).  That project is a Cobol
> translator: it compiles Cobol to C, and invokes gcc to produce
> executable code.  Our gcobol compiler is (currently) a fork of gcc.  It
> implements a gcc frontend for Cobol and (obviously) invokes the gcc
> backend to produce executables.  (We have a friendly relationship with
> GnuCOBOL, and its maintainer supports our undertaking.)
>
> Ours should also not be confused with prior efforts to create a gcc
> Cobol compiler.  Others have tried and failed.  Failure wasn't an
> option for us.  I won't say it was easy, but here we are.
>
> Eventually, if the gcc maintainers are interested, we would like to
> pursue full integration with gcc.  For the moment, we have questions
> we're hoping can be answered here by those who ran the gauntlet
> before us.  Given the state of the internals documentation, that seems
> like our best option. We've been rummaging around in the odd sock
> drawer for too long.
>
> If you're like me (like I was), your visceral response to this
> announcement can be summed up in one word: Why?
>
> The answer is as easy as it is trite: the right tool for the job.
>
> I wouldn't write an operating system in Cobol.  But I wouldn't write
> one in Python or Java, either.  Cobol has a niche no other language
> occupies: a compiled language for record-oriented I/O.
>
> That might sound strangely specialized, but it's not.  Record-oriented
> I/O describes, I would argue, nearly *all* applications.  Yet, since the
> advent of C, nearly all applications have relegated I/O to an external
> library, and adopted the Unix byte-stream definition of a "file".
>
> If you've written a CGI web application, you know what I'm talking
> about.  Cobol eliminates a lot of gobbledygook by reducing free-form
> run-time variables to compile-time constants.
>
> That's the rationale, and it's not just a theory.  Cobol is alive and
> kicking.  Estimates vary, but they all say north of 100 billion lines
> of Cobol are still in use, with millions more written every year, even
> now, in the 21st century.  Odds are your last ATM transaction or credit
> card purchase went through a Cobol application.
>
> There's another answer to Why: because a free Cobol compiler is an
> essential component to any effort to migrate mainframe applications to
> what mainframe folks still call "distributed systems".  Our goal is a
> Cobol compiler that will compile mainframe applications on Linux.  Not
> a toy: a full-blooded replacement that solves problems.  One that runs
> fast and whose output runs fast, and has native gdb support.
>
> I am happy to debate the lunacy of this project and the viability of
> Cobol, either here or off-list.  Today, we want to make the project
> known to those in the technical community who might most want to know
> what we're up to, and explain why we'll be asking the questions we're
> asking.
>
> Also, if you want to give it a whirl, please don't hesitate.  We're
> happy to help, and expect to learn something in the process.
>
> Thank you for you kind attention.
>
> --jkl

Hi, James

Great work!  Looking forward to having the GCobol front-end contributed to GCC.

Thanks, David

Re: [PATCH] Document that the 'access' and 'nonnull' attributes are independent

[Martin Sebor via Gcc]

On 3/9/22 14:57, David Malcolm via Gcc wrote:

On Wed, 2022-03-09 at 13:30 -0800, Andrew Pinski wrote:

On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc
 wrote:


We gained __attribute__ ((access, ...)) in GCC 10:
   
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

which identifies one of the pointer/reference arguments of a
function
as being accessed according to an access-mode: read_only,
read_write,
write_only, or none.

We also have __attribute__ ((nonnull)) to indicate that a function
argument (or all of them) must be non-NULL.

There doesn't seem to be a relationship between these in the
implementation, but it strikes me that almost anywhere that a user
might use the "access" attribute, that parameter is probably going
to
be required to be nonnull - though perhaps there are cases where
APIs
check for NULL and reject them gracefully?


No, I think they are separate. The access just says these access
attributes are read only, write only, read-write or don't access what
the pointer points to; it does not say they have to be read or
written
to.
I think it is a bad idea to connect the two ideas because you could
have some cases where an argument is optional but is only read from;
or is only written to (there are many in GCC sources even).


Thanks for the clarification...



Thanks,
Andrew Pinski



Might we want to somehow make __attribute__ ((access, ...)) imply
__attribute__ ((nonnull))?  (for non "none" access modes, perhaps?)

If so, one place to implement this might be in tree.cc's
get_nonnull_args, and have it add to the bitmap any arguments that
have an appropriate access attribute.

get_nonnull_args is used in various places:
- validating builtins
- in ranger_cache::block_apply_nonnull
- by -Wnonnull (in pass_post_ipa_warn::execute)
- by -Wanalyzer-possible-null-argument and -Wanalyzer-null-
argument;
I'm tracking the failure of these last two to make use of
__attribute__
((access)) in PR analyzer/104860.

So do we:

(a) leave it up to the user, requiring them to specify
__attribute__
((nonnull)) in addition to  __attribute__ ((access, ...))


...so that's (a) then.

I think it might be more user-friendly to be explicit about this in the
documentation, maybe something like the attached?


I agree it's worth clarifying the manual.

But I don't think there's a way to annotate a function to indicate
that it will definitely access an object (or dereference a pointer).
Attribute access just implies that it might dereference it (unless
the size is zero), and attribute nonnull that the pointer must not
be null, not that it will be dereferenced (or even that it must be
valid, although that's implied by the language and should probably
be enforced in all contexts by some other warning).

The combination of access with nonzero size and nonnull only means
that the pointer must be nonnull and point to an object with at least
size elements.

Martin



(not yet fully tested, but seems to build)

Dave






(b) leave it up to the individual sites in GCC that currently make
use
of get_nonnull_args to add logic for handling   __attribute__
((access,
...))

(c) extend get_nonnull_args

?

Thoughts?
Dave