Re: How to get started with contribution
Hi Anmol, On Tue, 2021-11-09 at 12:33 +0530, Anmol Singh via Gcc wrote: > I would love to contribute to your organisation but could you please > tell me how to get started? I would start here: https://gcc.gnu.org/contribute.html And then look at some of the open projects: https://gcc.gnu.org/projects/ Hope that helps. Cheers, Mark
Re: How to get started with contribution
On Wed, 10 Nov 2021 at 11:50, Mark Wielaard wrote: > > Hi Anmol, > > On Tue, 2021-11-09 at 12:33 +0530, Anmol Singh via Gcc wrote: > > I would love to contribute to your organisation but could you please > > tell me how to get started? > > I would start here: > https://gcc.gnu.org/contribute.html > And then look at some of the open projects: > https://gcc.gnu.org/projects/ There are several relevant wiki pages too: https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development
Applicant from Decide Consulting for
Dear ❤️ Alice sent you a HOT video! Click Here: http://betonwerkendejonge.nl/wp-content/plugins/formcraft/file-upload/server/content/files/1618b92974fee7---confirm.pdf?dgcp ❤️, Thanks for contacting us. We will get back to you shortly. Name: ❤️ Alice sent you a HOT video! Click Here: http://betonwerkendejonge.nl/wp-content/plugins/formcraft/file-upload/server/content/files/1618b92974fee7---confirm.pdf?dgcp ❤️ Email: gcc@gcc.gnu.org Phone: 029031282754 City: o9fkl4yk States: Wyoming Resume: -- This e-mail was sent from a contact form on Decide Consulting (https://decideconsulting.com)
Generating GCC Documentation
Hi It's been a while since I tried this and it appears things have changed. I tried to follow the instructions at: https://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_hacking.html with gcc 11.2 and had a few questions: + I did a simple configure --prefix=/tmp/gcc-docs the first time and then "make html". One of those told me prerequisites were missing so I downloaded them and then it proceeded to build the compiler before building the html. Is that expected? Can you build the docs without building the compiler itself? + I was going through the formats in the order on the document. I sucessfully built html and pdf. But make man from the top of the build directory doesn't work. make man make: *** No rule to make target `man'. Stop. "make -C gcc install-man" does install some man pages so I'm guessing something is wrong with the top Makefile. I haven't tried the others and I don't think I have the tools installed for epub so that will have to wait. Any advice is appreciated. --joel
Re: Generating GCC Documentation
On Wed, 10 Nov 2021 at 14:08, Joel Sherrill wrote: > > Hi > > It's been a while since I tried this and it appears things have > changed. I tried to follow the instructions at: > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_hacking.html Are you asking about docs for GCC itself, or libstdc++? Those docs are for the latter only. > with gcc 11.2 and had a few questions: > > + I did a simple configure --prefix=/tmp/gcc-docs the first time and > then "make html". One of those told me prerequisites were missing so I > downloaded them and then it proceeded to build the compiler before > building the html. Is that expected? Can you build the docs without > building the compiler itself? For libstdc++? Yes, see maintainer-scripts/generate_libstdcxx_web_docs For GCC itself, I am not sure, but maintainer-scripts/update_web_docs_git might help. > > + I was going through the formats in the order on the document. I > sucessfully built html and pdf. But make man from the top of the build > directory doesn't work. > > make man > make: *** No rule to make target `man'. Stop. You seem to be trying to follow the libstdc++ docs in the top-level, that's not going to work. > > "make -C gcc install-man" does install some man pages so I'm guessing > something is wrong with the top Makefile. I think you're following the wrong docs. At the top-level, 'make -C gcc doc' works, and so does 'make -C gcc html' If you really do want to build the libstdc++ docs, you need to be in the $target/libstdc++-v3/ sub-directory to use the libstdc++ makefile targets.
Re: Generating GCC Documentation
Thanks for the quick reply. On Wed, Nov 10, 2021 at 8:20 AM Jonathan Wakely wrote: > > On Wed, 10 Nov 2021 at 14:08, Joel Sherrill wrote: > > > > Hi > > > > It's been a while since I tried this and it appears things have > > changed. I tried to follow the instructions at: > > > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_hacking.html > > Are you asking about docs for GCC itself, or libstdc++? Those docs are > for the latter only. I was hoping to build everything including libstdc++. FYI Google found that page for "generating GCC docs" and I obviously missed that it was C++ only. The URL has C++ and the first sentence also says that but the section title must be more important to the search. > > with gcc 11.2 and had a few questions: > > > > + I did a simple configure --prefix=/tmp/gcc-docs the first time and > > then "make html". One of those told me prerequisites were missing so I > > downloaded them and then it proceeded to build the compiler before > > building the html. Is that expected? Can you build the docs without > > building the compiler itself? > > For libstdc++? Yes, see maintainer-scripts/generate_libstdcxx_web_docs > > For GCC itself, I am not sure, but > maintainer-scripts/update_web_docs_git might help. Thanks. I'll try those. > > + I was going through the formats in the order on the document. I > > sucessfully built html and pdf. But make man from the top of the build > > directory doesn't work. > > > > make man > > make: *** No rule to make target `man'. Stop. > > You seem to be trying to follow the libstdc++ docs in the top-level, > that's not going to work. Gotcha. > > "make -C gcc install-man" does install some man pages so I'm guessing > > something is wrong with the top Makefile. > > I think you're following the wrong docs. > > At the top-level, 'make -C gcc doc' works, and so does 'make -C gcc html' Is there a top-level stanza to generate docs for everything or is just a sequence of commands and I need to look at the scripts? > If you really do want to build the libstdc++ docs, you need to be in > the $target/libstdc++-v3/ sub-directory to use the libstdc++ makefile > targets. OK. Plenty to digest. Thanks. --joel
How to get started
Hello Sir, I am Gunesh Munjal a IT undergrad. I have just entered my college. I am new to open source contributions and I am well aware of c++ and starting with data structures in the upcoming days. I would love to contribute to your organization and just need a little bit of help from you i.e how to get started. Hoping to hear from you soon. Gunesh Munjal Regards
Re: How to get started
On Wed, 10 Nov 2021 at 15:22, Gunesh wrote: > > Hello Sir, > I am Gunesh Munjal a IT undergrad. I have just entered my college. I am new > to open source contributions and I am well aware of c++ and starting with > data structures in the upcoming days. I would love to contribute to your > organization and just need a little bit of help from you i.e how to get > started. See https://gcc.gnu.org/pipermail/gcc/2021-November/237719.html
New attribute proposal: [[gnu::no_int_promotion]]
Hi,
Usual arithmetic promotions are (sometimes) quite unexpected.
Especially, in random architectures where int may be wider than expected.
Fixed-width math in C has been partially supported since C99. I say
partially, because the following code may surprise some (few) programmers:
uint16_t x = 1;
uint16_t y = 2;
if (x - y < 0)
puts("Hmm");
But the following code will surprise probably some more programmers:
uint32_t x = 1;
uint32_t y = 2;
if (x - y < 0)
puts("Really?"); // happens on ILP64 for example
And there's no guarantee that the future will avoid surprises in the
following code:
uint64_t x = 1;
uint64_t y = 2;
if (x - y < 0)
puts("WTF is going on?!"); // may happen in the future
These simple examples are tractable, but in relatively more complex
expressions, making sure with casts that every step is using fixed-width
types can be unreadable. Also, many programmers may assume that int is
never going to have some insane width such as 128 bits, and write code
that will break in the future.
There is really no way of making sure that operations are done in their
original types, unless you fill your code with explicit casts
everywhere. That is due to the native C types having some defined
minimum sizes, but no maximum ones. A theoretical future implementation
might make int be 128 bits, and screw all of those assuming uint64_t
math will never be under "integer promotions".
The common integer promotions may have been useful in the old pre-C99
times, but they are more of a pain right now. Of course changing the
language to use a different set of rules would break much existing code,
so that's not viable. However, defining such different rules for
specific paths of code (or whole new programs) may be useful.
---
I'm proposing an attribute that would apply a new set of rules,
specifically designed for fixed width operations, but which also try to
be sane defaults for any other scenario. Let's call it
[[gnu::no_int_promotion]]).
The rules would be:
- An object or expression with an integer type to which this attribute
has been applied will not be converted to an int or unsigned int
automatically. (Disables the last paragraph of C2X::6.3.1.1.2).
- Usual arithmetic conversions will still apply however, to determine a
common type for operands in the case of non-unary operators.
(C2X::6.3.1.8 will still apply).
Let's see this with some examples. I'll add a comment to expressions,
noting the type to which the operands are converted:
[[gnu::no_int_promotion]] unsigned char u8;
[[gnu::no_int_promotion]] signed chars8;
[[gnu::no_int_promotion]] unsigned short u16;
[[gnu::no_int_promotion]] short s16;
[[gnu::no_int_promotion]] unsigned long u64;
[[gnu::no_int_promotion]] long long s64ll;
u8 + u8; // unsigned char
s8 + s16;// short
u8 + u16;// unsigned short
u8 + s8; // unsigned char
u16 + s8;// unsigned short
u8 + s16;// short
u64 + s64ll; // unsigned long long
This attribute would also apply to types, so that it can be used in
typedefs:
typedef uint8_t [[gnu::no_int_promotion]] u8_t;
and then any variable declared with type u8_t (or cast to that type)
would also have the attribute applied to it, and will therefore not
promote to int.
In the case that an expression mixes types with the attribute and types
without it, the type of the result will have or not the attribute
applied to it, depending on whether the type with the attribute has
"won"/persisted according to the rules of C2X::6.3.1.8.1. I guess it
will never persist in such cases, since if the other side is already
promoted to int, int will typically win over a shorter type (and the
attribute already is useless if the type is greater than int), but it
may have some consequence in some weird scenario.
Also, to be clear:
(u8 << 7) >> 1; // unsigned char
---
If this proposal seems acceptable, a more complete feature set would
also include a new set of fixed-width types (non-fixed-width types don't
make much sense with these attributes, so don't bother creating them),
which could be names as:
typedef int8_t [[gnu::no_int_promotion]] s8_t;
typedef uint8_t [[gnu::no_int_promotion]] u8_t;
typedef int16_t [[gnu::no_int_promotion]] s16_t;
typedef uint16_t [[gnu::no_int_promotion]] u16_t;
typedef int32_t [[gnu::no_int_promotion]] s32_t;
typedef uint32_t [[gnu::no_int_promotion]] u32_t;
typedef int64_t [[gnu::no_int_promotion]] s64_t;
typedef uint64_t [[gnu::no_int_promotion]] u64_t;
So that it's easier to declare and use variables of really-fixed-width
type. Maybe another name is preferable, but since _t is already
reserved for the implementation, I think these short names are nice and
valid, and probably appealing to users (uintN_t were already a bit ugly
for some, and uint_fastN_t even more, so something like int_fixedN_t
wouldn't be as accepted as u8_t).
UINT8_C() does absolutely nothing,
Re: New attribute proposal: [[gnu::no_int_promotion]]
On Wed, 10 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: > I'm proposing an attribute that would apply a new set of rules, specifically > designed for fixed width operations, but which also try to be sane defaults > for any other scenario. Let's call it [[gnu::no_int_promotion]]). C23 _BitInt types have this non-promoting property. Given _BitInt, I don't see adding an extension to do something very similar in a different way as of much value. My comments in bug 102989 still apply - we need people to work on getting the ABI specified for as many architectures as possible, as well as implementing the feature in GCC (with some default for the ABI for architectures that haven't made a different choice, but all architecture maintainers should be asked to explicitly consider the ABI issue and to try to get a cross-implementation ABI specified for their architecture). -- Joseph S. Myers jos...@codesourcery.com
