Re: new mirror greece
Hi again, The issue I was experiencing seems to be resolved now. Please add it to the mirrors. Regards, Kostas Στις Δευ 5 Αυγ 2024 στις 11:40 μ.μ., ο/η Konstantinos Draziotis < drazi...@gmail.com> έγραψε: > Hi, > > I wanted to inform you that the mirror is defective from 1st August, > likely due to an issue with its storage system. We are currently unsure > when this problem will be resolved. If it cannot be fixed, I will notify > all administrators to remove it from their listings. > > Thank you for your understanding. > > Kostas > > Στις Δευ 5 Αυγ 2024 στις 11:08 μ.μ., ο/η Gerald Pfeifer < > ger...@pfeifer.com> έγραψε: > >> On Thu, 29 Jun 2023, Konstantinos Draziotis via Gcc wrote: >> > I'd like to let you know that I have successfully set up a mirror >> > (http/https server) in Greece for gcc. >> >> Thank you, Konstantinos! >> >> > Location : Thessaloniki / Greece >> > Admin Name : K. A. Draziotis >> > Admin Email : drazi...@gmail.com >> > Sponsor Name: Aristotle University of Thessaloniki >> > Sponsor URL : https://auth.gr >> > HTTP/HTTPS URL: fosszone.csd.auth.gr/gnu/gcc >> >> I was going to add this to https://gcc.gnu.org/mirrors.html, alas >> fosszone.csd.auth.gr/gnu/gcc >> responds neither to http nor https in my tests? >> >> Can you please advise? >> >> (Maybe you can suggest a patch against that page?) >> >> Gerald >> >
-Wstringop-truncation false positive thoughts
I am working with “gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3)” so my
apologies if something has already been done about this.
I am also not a “list subscriber” so I will not see all the discussion this
post may cause, but seeing a couple of direct replies will be appreciated.
I am working on removing warnings from code and do not like using “nonstring”
where it is not strictly true.
It is my understanding that the following code sequence will not produce the
warning:
static const size_t BUFF_LEN = 256;
char cmdBuff[BUFF_LEN];
strncpy(cmdBuff, pCmdStr, BUFF_LEN);
cmdBuff[BUFF_LEN-1] = ‘\0’;
However, that fourth statement hides the truncation from detection and can be
considered a “bad practice” In many situations.
Most of the code that I am looking at replaces that fourth statement with:
If (‘\0’ != cmdBuff[BUFF_LEN-1]){. . .}
Thus, the truncation is detected and handled in some manner.
I can see how blindly accepting that the “truncation detection” solution can
lead to “false negatives”. Most of the code that I am looking at has a lot of
logic after the truncation handling block that would take a major amount of
“static analysis effort” to prove correct. So, I do not propose that either.
It is also possible that the detection could be done using strcmp(), but that
would lead to unnecessary runtime effort.
The solution that I see is to add the “string termination” statement as the
first thing done within the “truncation recovery” block. The code that I am
looking at is seemingly coded to prevent use, but who knows what may be done to
it in the future.
I admit that I do not understand the complexities of static analysis very well.
However, I suspect that it would not take much to change from simply “is
immediately terminated” to adding “or truncation detected and repaired”.
I know I am simplifying things a bit here. I can think of at least four valid
ways that conditional might be correctly coded, but those should all be easily
matched.
What I am wondering is:
* Does what I am proposing make sense and satisfy all the original issues that
the warning exists to satisfy?
* Am I correct that my solution would not take too much to implement in the
compiler?
Francis Belliveau
Consultant
Lincoln Laboratory, Massachusetts Institute of Technology
244 Wood Street
Lexington, MA 02421-6426
smime.p7s
Description: S/MIME cryptographic signature
Ccccccxcbbcb
B Cc Cxcn N C B B Bm Vbc Bv Cc m JC mom M CNBC m C B Cccbcb C Can Sent from Tony's iPhone
files in (at least) two archives in https://gcc.gnu.org/onlinedocs/gcc-14.2.0/ contain case-sensitive file names
Hello, From https://gcc.gnu.org/onlinedocs/gcc-14.2.0/ I recently downloaded gnat_rm-html.tar.gz and gnat_ugn-html.tar.gz. In both archives there are filenames that are case-sensitive, e.g. index.html and Index.html. This is fine for Unix/Linux users but not workable for MSWindows users. Is it possible to remedy this, or otherwise provide a warning about the non-portability of these archives. Or provide a workaround. Best regards, Rob Groen
Fixing dormant bugs in obstack code
I've been debugging a use-immediately-after-free bug involving obstacks (the bug isn't in trunk; I found it whilst testing one of my patches). It was only visible as a crash when it happened that the call to obstack_free led to the underlying buffer being freed. Most of the time, the bug was dormant, since the obstack_free was merely unwinding the "high water mark" of allocation within a buffer, and so the "obstack_free"d memory was still accessible to the process. Is there a way to make the obstack code "fussier" e.g. a debug option that on obstack_free fills the freed memory with a canary garbage value, so that this kind of bug immediately leads to a crash? (probably only in a checking build). Similarly, filling obstack memory with "not-yet-initialized" etc. I wonder if there's a way to "teach" valgrind about obstacks. I can try my hand at a patch if people think it's a good idea. It's part of libiberty, so which mailing list "owns" obstack development? Thanks Dave
Re: Fixing dormant bugs in obstack code
On Wed, Aug 28, 2024 at 2:37 PM David Malcolm via Gcc wrote: > > I've been debugging a use-immediately-after-free bug involving obstacks > (the bug isn't in trunk; I found it whilst testing one of my patches). > > It was only visible as a crash when it happened that the call to > obstack_free led to the underlying buffer being freed. Most of the > time, the bug was dormant, since the obstack_free was merely unwinding > the "high water mark" of allocation within a buffer, and so the > "obstack_free"d memory was still accessible to the process. > > Is there a way to make the obstack code "fussier" e.g. a debug option > that on obstack_free fills the freed memory with a canary garbage > value, so that this kind of bug immediately leads to a crash? (probably > only in a checking build). Similarly, filling obstack memory with > "not-yet-initialized" etc. I wonder if there's a way to "teach" > valgrind about obstacks. Note obstack upstream is technically glibc. Sam had filed a GCC bug report asking adding valgrind notations (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116246) but he found that there is already a bug report opened against gdb for it though: https://sourceware.org/bugzilla/show_bug.cgi?id=30114 . Also libiberty upstream is technically gcc git repo; though most patches are posted to either the GCC mailing list or to gdb and the GCC mailing or to binutils and gcc mailing list. Thanks, Andrew Pinski > > I can try my hand at a patch if people think it's a good idea. It's > part of libiberty, so which mailing list "owns" obstack development? > > Thanks > Dave >
Re: Fixing dormant bugs in obstack code
Andrew Pinski via Gcc writes: > On Wed, Aug 28, 2024 at 2:37 PM David Malcolm via Gcc wrote: >> >> I've been debugging a use-immediately-after-free bug involving obstacks >> (the bug isn't in trunk; I found it whilst testing one of my patches). >> >> It was only visible as a crash when it happened that the call to >> obstack_free led to the underlying buffer being freed. Most of the >> time, the bug was dormant, since the obstack_free was merely unwinding >> the "high water mark" of allocation within a buffer, and so the >> "obstack_free"d memory was still accessible to the process. >> >> Is there a way to make the obstack code "fussier" e.g. a debug option >> that on obstack_free fills the freed memory with a canary garbage >> value, so that this kind of bug immediately leads to a crash? (probably >> only in a checking build). Similarly, filling obstack memory with >> "not-yet-initialized" etc. I wonder if there's a way to "teach" >> valgrind about obstacks. > > Note obstack upstream is technically glibc. > Sam had filed a GCC bug report asking adding valgrind notations > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116246) but he found > that there is already a bug report opened against gdb for it though: > https://sourceware.org/bugzilla/show_bug.cgi?id=30114 . > > Also libiberty upstream is technically gcc git repo; though most > patches are posted to either the GCC mailing list or to gdb and the > GCC mailing or to binutils and gcc mailing list. BTW, I have a sync for libiberty/ with gnulib. I just haven't posted it yet. But I don't mind rebasing after dmalcolm's work either. > > Thanks, > Andrew Pinski > > >> >> I can try my hand at a patch if people think it's a good idea. It's >> part of libiberty, so which mailing list "owns" obstack development? Yes please! >> >> Thanks >> Dave >>
Re: [RFC] Return Value Propagation in IPA-CP
Ping (https://gcc.gnu.org/pipermail/gcc/2024-August/244625.html).
On 22/08/24 11:32, Dhruv Chawla via Gcc wrote:
External email: Use caution opening links or attachments
* Table Of Contents *
- Introduction
- Motivating Test Cases
- Proposed Solution
- Other Options
- Existing Solutions
- Primary Optimizations To Be Improved
- Front-End Attribute For Recording Return-Value Information
- Future Work
- References
- Questions
* Introduction *
Return jump functions offer a way of modeling return values of a function in
terms of its formal parameters, similar to how regular jump functions can be
used to model the actual parameters of a callee at a callsite in terms of the
formal parameters of the caller.
By discovering this information and propagating it across the program callgraph
in LTO mode, various transformations like value-range propagation, sibling-call
and chaining-call optimization can be augmented to take advantage of it and
potentially perform better optimizations.
Currently, ipa-cp models parameters using jump functions, propagates the values
of those jump functions by iterating to a fixed-point using lattices, and
clones functions by taking decisions from those lattice values.
We propose extending ipa-cp with the analysis and propagation of return jump
functions, starting with the basic case of a direct return of the form
"return x;" where "x" is any formal parameter of the function.
* Motivating Test Cases *
* Optimizing tail calls:
- PR92867
char buf[128] = { 1 };
char *foo (__SIZE_TYPE__ n)
{
return __builtin_memset (buf, ' ', n);
}
char *bar (__SIZE_TYPE__ n)
{
__builtin_memset (buf, ' ', n);
return buf;
}
Here, the call to __builtin_memset in foo gets successfully converted to a
tail-call, however the call in bar cannot be optimized to a tail-call. This is
an optimization that LLVM is able to perform.
Link to compiler explorer: https://godbolt.org/z/E81axqWTb
- PR67797
#include
void *my_func(void *s, size_t n)
{
memset(s, 0, n);
return s;
}
This is a similar case to the above example. LLVM is able to optimize the call
to memset to be a tail-call as well.
Link to compiler explorer: https://godbolt.org/z/YzjGc59f8
* Optimizing chaining calls:
#include
void f (int x, int y)
{
std::cout << x;
std::cout << y;
}
This function can be optimized to the following:
#include
void f (int x, int y)
{
std::cout << x << y;
}
LLVM is able to perform this optimization as well:
https://godbolt.org/z/MW75on1o5
* Proposed Solution *
* Extending IPA-CP:
1. Add return jump function data structures
- This involves updating ipa_node_params to contain information regarding the
return statements of the function, namely the lattice and the jump function
describing the return value, where both use existing data structures.
- The ipa_node_params class is reused to avoid introducing a new class and a
corresponding function_summary type, though it is trivial to add if deemed
a better solution. The ipa_return_value_summary class may also be a good
place for this information, however using it would involve moving it from
ipa-prop.cc to ipa-prop.h.
- Additionally, ipa_edge_args is updated to track whether or not it is a
callgraph edge originating from a return statement. This enables the
propagation of information in the WPA phase.
2. LGEN
- Set up return jump functions for each function similar to the parameter
jump function. When it cannot be conclusively determined that one formal
parameter is always returned (such as conditionally returning either of
two), the jump function is marked as invalid.
- This involves looking through phi nodes when return statements of
conditional branches are merged into a single exit block. Note that
returning a call expression does not count towards invalidating the
information for that function.
3. WPA
- Implement return value information propagation. It is not possible to do
this in the existing propagate_constants_topo function, because it iterates
in reverse postorder i.e. from caller to callee. However return value
propagation needs to be done from callee to caller, thus there is a need to
iterate in a postorder fashion.
- The lattice values are initialized using the jump functions computed in the
LGEN phase. These values are then propagated over the callgraph.
- The existing lattices are reused, with three possible values like usual.
The possible values are:
return_lattice -> { TOP, param_decl, BOTTOM }
where TOP and BOTTOM are defined as usual. param_decl refers to the tree of
either the parameter declaration or its type, whichever is available. The
meet operator is defined as usual for TOP and BOTTOM. When both are
param_decl, the following meet operation is defined:
meet(x, y) = x if x == y, BOTTOM otherwise
- Finally, nodes to which no information could be
