Re: Naming flag for specifying the output file name for Binary Module Interface files
On Thu, Dec 15, 2022 at 07:37:35 +, Iain Sandoe wrote: > * I have patches for clang that implements the P1184 interface which > would allow a ‘module mapper’ to be used to discover module name <-> > pathname pairings. > > * The demand for the command line options we are discussing here is > coming from build systems folks who want to be able to specify > everything on the command line (i.e. from my understanding they do > not want to use a module mapper, but prefer dependency scanning). > > So I think the two aspects are somewhat independent, I would expect > the same build systems folks to want to be able to specify everything > on the GCC command line too. Note that it is particularly knowing the *output* module that is important for distributed builds so that the dispatcher can know what file(s) need to be sent and retrieved for a given command line. While GCC's module mapper has the information, it is lacking any indication of which might be output and input paths. With `-fmodule-output=`, the one output is known and anything else known to the specified `-fmodule-mapper=` (which must be understood by the dispatcher; I suspect flat files will be the preferred mechanism here rather than a socket or other fancy mechanism) can be assumed to be (potential; ideally exact) inputs. --Ben
Re: Contribution
Hi, thanks for your interest. There are some ideas at https://gcc.gnu.org/wiki/EasyHacks You might also look at Bugzilla PRs with a lot of interest, particularly with severity of "enhancement". In the search results screen you can display the number of CCs and duplicates using the "change columns" button at the bottom. On Wed, Dec 14, 2022 at 10:33 AM Mohamed Atef via Gcc wrote: > Hello all, >As I mentioned before, I don't have much time to contribute. > So is there any way I can contribute some medium project I can work on but > myself in the long run? I loved this community, I contributed before so can > you suggest some work for me? > > Mohamed > >
gcc assembler language reference
Dear Team GCC GNU ORG, please assist me with getting the assembler language reference the GCC implementation is based on lately Thank you and Have a great day Jeannot Deumer
Re: Possible dead code in file lra-spills.cc
Ok. And as you point out it is redundant code rather than dead code, to be precise. On Wed, Dec 14, 2022, 1:47 PM Richard Biener wrote: > > > > Am 14.12.2022 um 18:28 schrieb G.T. via Gcc : > > > > At line 276, lra_assert (spill_class != NO_REGS); would trigger > > whenever execution reached here with spill_class equal to NO_REGS. > > Seems to me that would never happen. Because one of the conditions in > > the if statement right above it (line 265) catches spill_class == > > NO_REGS and causes the rest of the for loop to be skipped by executing > > continue in the consequent of the if. So lra_assert never sees > > spill_class == NO_REGS. That makes line 276 dead code, right? > > Sometimes this serves as documentation to make the code more obvious to > read. Depends on the distance of the redundant check. > > Richard > > > > Thanks. > > GT. >
Re: Contribution
On Wed, 2022-12-14 at 17:32 +0200, Mohamed Atef via Gcc wrote: > Hello all, > As I mentioned before, I don't have much time to contribute. > So is there any way I can contribute some medium project I can work > on but myself in the long run? I loved this community, I contributed > before so can you suggest some work for me? I don't know if it's on the EasyHacks list but there's this bug with a patch I filed years ago, that has been asked for multiple times since, but I've never had the bandwidth to polish and submit it and it looks like I never will. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147
[wwwdocs] C++03 missing on https://gcc.gnu.org/projects/cxx-status.html
On this page all ISO C++ standards versions of gcc/g++ are listed, except C++03: https://gcc.gnu.org/projects/cxx-status.html This looks much like an error/omission b/c g++ has the options -std=c++03 and -std=gnu++03
Re: [wwwdocs] C++03 missing on https://gcc.gnu.org/projects/cxx-status.html
On Thu, Dec 15, 2022 at 05:53:19PM +0100, U.Mutlu wrote: > On this page all ISO C++ standards versions of gcc/g++ are listed, except > C++03: > https://gcc.gnu.org/projects/cxx-status.html > > This looks much like an error/omission b/c g++ has the options -std=c++03 > and -std=gnu++03 C++03 isn't a separate standard version, just technical corrigendum and the page mentions it: C++98 Support in GCC GCC has full support for the 1998 C++ standard as modified by the 2003 technical corrigendum -std=c++03 is an alias to -std=c++98 and -std=gnu++03 is an alias to -std=gnu++98 and the gcc manual explains that. Jakub
Re: Why does filing a bug report have to be so damn hard?
What is going on out there these days? I've added more addresses from the GCC mailing list to my killfile in the last week than in the previous two years combined. Yeesh.
Re: [wwwdocs] C++03 missing on https://gcc.gnu.org/projects/cxx-status.html
Jakub Jelinek wrote on 12/15/22 17:59: On Thu, Dec 15, 2022 at 05:53:19PM +0100, U.Mutlu wrote: On this page all ISO C++ standards versions of gcc/g++ are listed, except C++03: https://gcc.gnu.org/projects/cxx-status.html This looks much like an error/omission b/c g++ has the options -std=c++03 and -std=gnu++03 C++03 isn't a separate standard version, just technical corrigendum and the page mentions it: C++98 Support in GCC GCC has full support for the 1998 C++ standard as modified by the 2003 technical corrigendum -std=c++03 is an alias to -std=c++98 and -std=gnu++03 is an alias to -std=gnu++98 and the gcc manual explains that. Jakub Whatever, but they still could list it like the others and then give the explanation you gave. B/c otherwise it looks like as if the doc writer has forgotten one of the historic steps...
Re: [wwwdocs] C++03 missing on https://gcc.gnu.org/projects/cxx-status.html
On Thu, 15 Dec 2022, 19:50 U.Mutlu, wrote: > Jakub Jelinek wrote on 12/15/22 17:59: > > On Thu, Dec 15, 2022 at 05:53:19PM +0100, U.Mutlu wrote: > >> On this page all ISO C++ standards versions of gcc/g++ are listed, > except C++03: > >> https://gcc.gnu.org/projects/cxx-status.html > >> > >> This looks much like an error/omission b/c g++ has the options > -std=c++03 > >> and -std=gnu++03 > > > > C++03 isn't a separate standard version, just technical corrigendum > > and the page mentions it: > > > > C++98 Support in GCC > > GCC has full support for the 1998 C++ standard as modified by the 2003 > > technical corrigendum > > > > -std=c++03 is an alias to -std=c++98 and -std=gnu++03 is an alias to > > -std=gnu++98 and the gcc manual explains that. > > > > Jakub > > > Whatever, but they still could list it like the others and then give the > explanation you gave. > B/c otherwise it looks like as if the doc writer has forgotten one of the > historic steps... > I disagree. If you actually know what the -std=c++03 option means, you wouldn't think that. And it already says GCC had full support for C++ 1998 *including the 2003 Technical Corrigendum*. The document doesn't need to be clear to people who have no idea what C++ is, or what the gcc options mean, because that's not the audience it's intended for > >
Re: [wwwdocs] C++03 missing on https://gcc.gnu.org/projects/cxx-status.html
On Thu, 15 Dec 2022, 20:04 Jonathan Wakely, wrote: > > > On Thu, 15 Dec 2022, 19:50 U.Mutlu, wrote: > >> Jakub Jelinek wrote on 12/15/22 17:59: >> > On Thu, Dec 15, 2022 at 05:53:19PM +0100, U.Mutlu wrote: >> >> On this page all ISO C++ standards versions of gcc/g++ are listed, >> except C++03: >> >> https://gcc.gnu.org/projects/cxx-status.html >> >> >> >> This looks much like an error/omission b/c g++ has the options >> -std=c++03 >> >> and -std=gnu++03 >> > >> > C++03 isn't a separate standard version, just technical corrigendum >> > and the page mentions it: >> > >> > C++98 Support in GCC >> > GCC has full support for the 1998 C++ standard as modified by the 2003 >> > technical corrigendum >> > >> > -std=c++03 is an alias to -std=c++98 and -std=gnu++03 is an alias to >> > -std=gnu++98 and the gcc manual explains that. >> > >> > Jakub >> >> >> Whatever, but they still could list it like the others and then give the >> explanation you gave. >> B/c otherwise it looks like as if the doc writer has forgotten one of the >> historic steps... >> > > I disagree. If you actually know what the -std=c++03 option means, you > wouldn't think that. And it already says GCC had full support for C++ 1998 > *including the 2003 Technical Corrigendum*. > > The document doesn't need to be clear to people who have no idea what C++ > is, or what the gcc options mean, because that's not the audience it's > intended for > We could add "The options -std=c++03 and -std=gnu++03 are equivalent to -std=c++98 and -std=gnu++98, respectively." To the very end. That would not be as misleading as adding a separate artificial listing for C++03.
GOMP: OMP 5.1: simd construct for non-pointer random access iterators
Hi together, I just ran into the issue that `#pragma omp simd` does not work on C++ iterator loops (godbolt). >From going through the specifications I understand that this restriction was >part of 4.5 and 5.0, but was dropped with 5.1. As I couldn't find this change in the table of 5.1 (or 5.2) features for libgomp, I wanted to ask if this is on the horizon. Best, Paul Große-Bley
Re: GOMP: OMP 5.1: simd construct for non-pointer random access iterators
On Thu, Dec 15, 2022 at 09:31:50PM +0100, Grosse-Bley, Paul Leonard wrote: > > Hi together, > > I just ran into the issue that `#pragma omp simd` does not work on C++ > iterator loops (godbolt). > >From going through the specifications I understand that this restriction was > >part of 4.5 and 5.0, but was dropped with 5.1. > As I couldn't find this change in the table of 5.1 (or 5.2) features for > libgomp, I wanted to ask if this is on the horizon. That is not the case. OpenMP 5.1 has the restriction on p. 137 l. 22: "The only random access iterator types that are allowed for the associated loops are pointer types." OpenMP 5.2 has the same thing on p. 235 l. 31. Even TR11 (first OpenMP 6.0 draft) has the same wording on p. 246 l. 2. Jakub
Re: [-Wstringop-overflow=] strncat(3)
On 12/14/22 16:14, Alejandro Colomar via Libc-alpha wrote:
[CC += groff]
Hi Andrew,
On 12/14/22 23:57, Andrew Pinski wrote:
On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha
wrote:
Hi,
I was rewriting the strncat(3) manual page, and when I tried to
compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library Functions Manual
strncat(3)
NAME
strncat - concatenate a null‐padded character
sequence into a
string
LIBRARY
Standard C library (libc, -lc)
SYNOPSIS
#include
char *strncat(char *restrict dst, const char src[restrict
.sz],
size_t sz);
DESCRIPTION
This function catenates the input character sequence
contained in
a null‐padded fixed‐width buffer, into a string at
the buffer
pointed to by dst. The programmer is responsible for
allocating a
buffer large enough, that is, strlen(dst) + strnlen(src,
sz) + 1.
An implementation of this function might be:
char *
strncat(char *restrict dst, const char *restrict src,
size_t sz)
{
int len;
char *end;
len = strnlen(src, sz);
end = dst + strlen(dst);
end = mempcpy(end, src, len);
*end = '\0';
return dst;
}
RETURN VALUE
strncat() returns dest.
ATTRIBUTES
[...]
STANDARDS
POSIX.1‐2001, POSIX.1‐2008, C89, C99, SVr4, 4.3BSD.
CAVEATS
The name of this function is confusing. This function
has no re‐
lation with strncpy(3).
If the destination buffer is not large enough, the
behavior is un‐
defined. See _FORTIFY_SOURCE in feature_test_macros(7).
BUGS
This function can be very inefficient. Read about
Shlemiel
the painter
⟨https://www.joelonsoftware.com/2001/12/11/
back-to-basics/⟩.
EXAMPLES
#include
#include
#include
int
main(void)
{
char buf[BUFSIZ];
size_t len;
buf[0] = '\0'; // There’s no ’cpy’ function to this
’cat’.
strncat(buf, "Hello ", 6);
There's nothing wrong with this but the two lines above would be
more simply coded as one:
strcpy(buf, "Hello ");
The original code suggests a misunderstanding of strncpy's purpose:
that it writes exactly 6 bytes into the destination. That's what
the warning points out.
strncat(buf, "world", 42); // Padding null bytes
ignored.
strncat(buf, "!", 1);
len = strlen(buf);
printf("[len = %zu]: <%s>\n", len, buf);
exit(EXIT_SUCCESS);
}
SEE ALSO
string(3), string_copy(3)
Linux man‐pages (unreleased) (date)
strncat(3)
And when you compile that, you get:
$ cc -Wall -Wextra ./strncat.c
./strncat.c: In function ‘main’:
./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source
length
[-Wstringop-overflow=]
12 | strncat(buf, "Hello ", 6);
| ^
./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source
length
[-Wstringop-overflow=]
14 | strncat(buf, "!", 1);
| ^~~~
So, what? Where's the problem? This function does exactly that:
"take an
unterminated character sequence and catenate it to an existing
string".
Strncat has historically had two distinct use cases. One of them
-- to constrain the amount of data to copy to the space remaining
in the destination -- gained popularity with the push to reduce
buffer overflow weaknesses in code. Mistakes in these uses gave
rise to a whole other class of security bugs, to the extent that
CERT felt it necessary to publish the strncpy and strncat best
practice. The GCC warning in turn was added to support the CERT
guideline. I touch on some of this in a blog post I wrote a few
years ago:
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8
The specific uses of the function above are contrived (there's
no point in calling strncat to append the full string -- strcat
will do that more clearly and efficiently) but the general use
case -- limiting the amount of copied data to an initial
substring of the source sequence -- although valid and originally
intended (it's one of the two uses of the function in UNIX v7),
is not one that either the guideline or the warning consider.
They can only consider one use cases, and they chose the one
that was observed behind security bugs. That choice unavoidably
leads to some f
Re: GOMP: OMP 5.1: simd construct for non-pointer random access iterators
Hi, On 15.12.22 21:31, Grosse-Bley, Paul Leonard wrote: I just ran into the issue that `#pragma omp simd` does not work on C++ iterator loops (godbolt). From going through the specifications I understand that this restriction was part of 4.5 and 5.0, but was dropped with 5.1. I assume that it is about "non-pointer random access iterators" – as the subject line states. In OpenMP 5.0, there is: "2.9.1 Canonical Loop Form": "In the simd construct the only random access iterator types that are allowed for var are pointer types." [OpenMP 5.0, 100:15-16] But I still see in OpenMP 5.1: "2.11.5.1 simd Construct": "Restrictions to the simd construct are as follows: ... [C++] The only random access iterator types that are allowed for the associated loops are pointer types." [OpenMP 5.1, 137:2, 137:22]. Same words as in 5.1 are also in OpenMP 5.2 in "10.4 simd Construct" [235:31]. Did I miss something? If so, can you provide the example? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Fwd: Re: GOMP: OMP 5.1: simd construct for non-pointer random access iterators
Sorry, I just saw that I only answered Jakub and Tobias directly instead of CCing the List, so I will just forward my answer to Tobias to avoid wasting anyones time. Original Message Subject: Re: GOMP: OMP 5.1: simd construct for non-pointer random access iterators Date: Thursday, December 15, 2022 22:19 CET From: Grosse-Bley, Paul Leonard To: "Tobias Burnus" Hi Tobias, as Jakub pointed out to me, the restriction was just moved in the standard (or a redundant copy removed). The mention that I was searching for in 5.1 and 5.2 was in the "Canonical Loop Form" chapter and not in the chapter about the actual simd construct. As clang and Intel don't error for that godbold example, I thought I was onto something... Thanks for answering, Best, Paul On Thursday, December 15, 2022 21:53 CET, Tobias Burnus wrote: Hi, On 15.12.22 21:31, Grosse-Bley, Paul Leonard wrote: > I just ran into the issue that `#pragma omp simd` does not work on C++ > iterator loops (godbolt). > From going through the specifications I understand that this restriction was > part of 4.5 and 5.0, but was dropped with 5.1. I assume that it is about "non-pointer random access iterators" – as the subject line states. In OpenMP 5.0, there is: "2.9.1 Canonical Loop Form": "In the simd construct the only random access iterator types that are allowed for var are pointer types." [OpenMP 5.0, 100:15-16] But I still see in OpenMP 5.1: "2.11.5.1 simd Construct": "Restrictions to the simd construct are as follows: ... [C++] The only random access iterator types that are allowed for the associated loops are pointer types." [OpenMP 5.1, 137:2, 137:22]. Same words as in 5.1 are also in OpenMP 5.2 in "10.4 simd Construct" [235:31]. Did I miss something? If so, can you provide the example? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [-Wstringop-overflow=] strncat(3)
Hi Martin,
On 12/15/22 21:50, Martin Sebor wrote:
On 12/14/22 16:14, Alejandro Colomar via Libc-alpha wrote:
[...]
int
main(void)
{
char buf[BUFSIZ];
size_t len;
buf[0] = '\0'; // There’s no ’cpy’ function to this ’cat’.
strncat(buf, "Hello ", 6);
There's nothing wrong with this but the two lines above would be
more simply coded as one:
strcpy(buf, "Hello ");
I used a string literal to avoid having to think hard of an example using
utmpx(5), which would be the actual code for which I want users to use this
function.
With time, I expect to develop such example program.
The original code suggests a misunderstanding of strncpy's purpose:
By the "original code" what are you exactly referring to? The code quoted
above, or another?
In any case, the code is using strncat(3) not strncpy(3).
that it writes exactly 6 bytes into the destination.
That's the purpose of strncpy(3). I'll quote the versions of the pages that I'm
proposing:
strncpy(3):
These functions copy the string pointed to by src into a null‐padded
character sequence at the fixed‐width buffer pointed to by dst. If the
destination buffer, limited by its size, isn’t large enough to hold the
copy, the resulting character sequence is truncated. They only differ
in the return value.
The description above says that the destination buffer is limited by its size,
so as you say, this function copies exactly 6 bytes (the character sequence +
null padding).
strncat(3)
This function catenates the input character sequence contained in a
null‐padded fixed‐width buffer, into a string at the buffer pointed to
by dst. The programmer is responsible for allocating a buffer large
enough, that is, strlen(dst) + strnlen(src, sz) + 1.
But strncat(3) writes whatever is the length of the character sequence passed as
input (ignoring the padding null bytes), plus a terminating null byte.
That's what
the warning points out.
The warning would be fair for strncpy(3), but not for strncat(3).
strncat(buf, "world", 42); // Padding null bytes ignored.
strncat(buf, "!", 1);
len = strlen(buf);
printf("[len = %zu]: <%s>\n", len, buf);
exit(EXIT_SUCCESS);
}
SEE ALSO
string(3), string_copy(3)
Linux man‐pages (unreleased) (date) strncat(3)
And when you compile that, you get:
$ cc -Wall -Wextra ./strncat.c
./strncat.c: In function ‘main’:
./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source length
[-Wstringop-overflow=]
12 | strncat(buf, "Hello ", 6);
| ^
./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source length
[-Wstringop-overflow=]
14 | strncat(buf, "!", 1);
| ^~~~
So, what? Where's the problem? This function does exactly that: "take an
unterminated character sequence and catenate it to an existing string".
Strncat has historically had two distinct use cases. One of them
-- to constrain the amount of data to copy to the space remaining
in the destination -- gained popularity with the push to reduce
buffer overflow weaknesses in code. Mistakes in these uses gave
rise to a whole other class of security bugs, to the extent that
CERT felt it necessary to publish the strncpy and strncat best
practice. The GCC warning in turn was added to support the CERT
guideline. I touch on some of this in a blog post I wrote a few
years ago:
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8
While this is true, that's because there was nothing more appropriate, such as
strlcat(3).
My point is that strncat(3) is far from being a good tool for that, and should
never be used for that purpose in good code; especially now that we have
strlcat(3) widely available in most if not all POSIX systems (in Linux through
libbsd).
I'll quote some part of the link above:
|strncat (dest, src, dest_size - strlen (dest) - 1);
|
| Calls that have this form are not diagnosed.
That code is a source of bugs. Such code should _always_ be replaced by
strlcat(3) as:
strlcat(dst, src, sizeof(dst);
| Other calls, such as those where
| the size is derived in some way from the size or length of the source string,
| are diagnosed by -Wstringop-overflow. That includes unsafe calls like
The only sane use of strncat(3) is that. It's a use where no other function
serves better. To read a possibly non-terminated character sequence from a
fixed-width buffer; and the size is the only way strncat(3) can know when to
stop reading.
|
|strncat (dest, src, strlen (src)); // incorrect - warning
This call doesn't make any sense; I agree. It should _always_ be replaced by
strc
gcc-10-20221215 is now available
Snapshot gcc-10-20221215 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20221215/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 59bba6f9dc6dcfefe96e6fad677614f39928564e You'll find: gcc-10-20221215.tar.xz Complete GCC SHA256=cd85564181815c172a8d423eff145225e38043e59915f996b1ebf1b96bcef13f SHA1=32e95aad4df4751fa271f928157eb48329a663a3 Diffs from 10-20221208 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
