Re: Fw: Problems with compiling autogen with GCC8 or newer versions
Hi, You are supposed to be able to post once you've subscribed. Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than MAXNAMELEN characters. That is provable. "def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at an offset maximum of MAXNAMELEN+1 (also provable), meaning that at a minimum there are MAXNAMELEN+6 bytes left in the buffer. That objected-to sprintf can add a maximum of MAXNAMELEN + 4 to where "def_str" points. GCC is wrong. It is unable to figure out how far into the buffer "def_str" can point. On 1/8/21 2:26 AM, Oppe, Thomas C ERDC-RDE-ITL-MS Contractor wrote: Dear Sir: I would like to post the following message to the mailing list "autogen-us...@lists.sourceforge.net". Could you please add me to this list? I am an HPC user at ERDC DSRC in Vicksburg, MS. One of my projects is building GCC snapshots and releases using various software prerequisite packages necessary in the "make check" phase. One of these packages is autogen-5.18.16. Thank you for your consideration. Tom Oppe - Thomas C. Oppe HPCMP Benchmarking Team HITS Team SAIC thomas.c.o...@erdc.dren.mil Work: (601) 634-2797 Cell:(601) 642-6391 - From: Oppe, Thomas C ERDC-RDE-ITL-MS Contractor Sent: Friday, January 8, 2021 12:32 AM To: autogen-us...@lists.sourceforge.net Subject: Problems with compiling autogen with GCC8 or newer versions Dear Sir: When compiling autogen-5.18.16 with gcc8 or newer, I am getting format overflow errors like the following during the "make" step: top_builddir=".." top_srcdir=".." VERBOSE="" /bin/bash "../build-aux/run-ag.sh" -MFstamp-opts -MTstamp-opts -MP ./opts.def gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -g -O2 -I/p/home/oppe/gcc/10.2.0/include -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra -Wno-cast-qual -g -O2 -I/p/home/oppe/gcc/10.2.0/include -Wno-format-contains-nul -fno-strict-aliasing -c -o gd.o gd.c In file included from gd.c:11: getdefs.c: In function 'buildDefinition': getdefs.c:451:29: error: '%s' directive writing up to 255 bytes into a region of size 253 [-Werror=format-overflow=] 451 | sprintf(def_str, " %s'", name_bf); | ^~~~~ getdefs.c:451:9: note: 'sprintf' output between 4 and 259 bytes into a destination of size 255 451 | sprintf(def_str, " %s'", name_bf); | ^~ cc1: all warnings being treated as errors make[2]: *** [gd.o] Error 1 make[2]: Leaving directory `/p/work1/oppe/autogen-5.18.16/getdefs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/p/work1/oppe/autogen-5.18.16' make: *** [all] Error 2 Do I just add "-Wno-error=format-overflow" to the compile options? Do you have a fix? Tom Oppe - Thomas C. Oppe HPCMP Benchmarking Team HITS Team SAIC thomas.c.o...@erdc.dren.mil Work: (601) 634-2797 Cell:(601) 642-6391 -
Re: Fw: Problems with compiling autogen with GCC8 or newer versions
On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote: > Hi, > > You are supposed to be able to post once you've subscribed. > > Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than > MAXNAMELEN characters. That is provable. > > "def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at > an offset maximum of MAXNAMELEN+1 (also provable), meaning that at a > minimum there are MAXNAMELEN+6 bytes left in the buffer. > > That objected-to sprintf can add a maximum of MAXNAMELEN + 4 to where > "def_str" points. > > GCC is wrong. It is unable to figure out how far into the buffer > "def_str" can point. Can you get a .i file, command line and file a report. It'd be appreciated. jeff
Re: [RFC] restricting aliasing by standard containers (PR 98465)
On 1/8/21 12:51 AM, Richard Biener wrote:
On Thu, Jan 7, 2021 at 10:41 PM Martin Sebor wrote:
The test case in PR 98465 brings to light a problem we've discussed
before (e.g., PR 93971) where a standard container (std::string in
this case but the problem applies to any class that owns and manages
allocated memory) might trigger warnings for unreachable code.
The code is not eliminated due to a missing aliasing constraint:
because GCC doesn't know that the member pointer to the memory
managed by the container cannot alias other objects, it emits code
that can never be executed in a valid program and that's prone to
causing false positives.
To illustrate, at the moment it's impossible to fold away the assert
below because there's no way to determine in the middle end that
String::s cannot point to a:
extern char array[];
class String {
char *s;
public:
String (const char *p): s (strdup (p)) { }
String (const String &str): s (strdup (str.s)) { }
~String () { free (s); }
void f () { assert (s != array); }
};
The constraint is obvious to a human reader (String::s is private
and nothing sets it to point to array) but there's no way for GCC
to infer it from the code alone (at least not in general): there
could be member or friend functions defined in other translation
units that violate this assumption.
One way to solve the problem is to explicitly declare that
String::s, in fact, doesn't point to any such objects and that it
only ever points to allocated memory. My idea for doing that is
to extend attribute malloc to (or add a new attribute for) pointer
variables to imply that the pointer only points to allocated memory.
However, besides pointing to allocated memory, std::string can also
point to its own internal buffer, so the extended malloc attribute
couldn't be used there by itself. I think this could be solved by
also either extending the may_alias attribute or adding a new
"alias" (or some such) attribute to denote that a pointer variable
may point to an object or subobject.
Putting the two together, to eliminate the assert, std::string would
be annotated like so:
class string {
char *s __attribute__ ((malloc, may_alias (buf)));
char buf[8];
public:
string (): s (buf) { }
string (const char *p): s (strdup (p)) { }
string (const string &str): s (strdup (str.s)) { }
~string () { if (s != buf) free (s); }
void f () { assert (s != array); }
};
The may_alias association with members is relative to the this pointer
(i.e., as if by may_alias (this->buf), as opposed to being taken as
may_alias (String::buf) and meaning that s might be equal to any other
String::s with a different this. To help avoid mistakes, setting s
in violation of the constraints would trigger warnings.
If this sounds reasonable I'm prepared to prototype it, either for
GCC 11 if it's in scope to solve the PR and there's still time, or
(I suspect more likely) for GCC 12.
Richard, what are your thoughts/concerns?
I'm not sure it's feasible to make use of this attribute. First
there's the malloc part which has difficult semantics (similar
to restrict) when generating PTA constraints. We might see
_1 = str.s;
_2 = str.s;
but are of course required to associate the same allocated
dummy object with both pointers (as opposed to when we'd
see two malloc calls). What would possibly work is to
have the object keyed on the field decl, but then for
_1 = p_to_str_4(D);
_2 = _1 + offsetof-s;
_3 = *_2;
we have to somehow conservatively arrive at the same object.
I don't see how that can work out.
All the same applies to the may_alias part but I guess when the
malloc part falls apart that's not of much interest.
So I'm concerned about correctness - I'm sure you can hack
sth together to get some testcases optimized. But I'm not sure
you can make it correct in all cases (within the current PTA
framework).
Thanks for the feedback.
Absent some source level annotation I can't think of a good way
to avoid these false positives. Do you have any other ideas?
If not, would you be opposed to introducing these attributes to
suppress warnings (at least at first)? Besides avoiding the false
positives, implementing just that part might also be a good proof
of concept for the aliasing solution (or a confirmation of your
intuition).
Martin
Richard.
Martin
PS An alternate solution might be to provide a late-evaluated built-in,
something like
__builtin_decl (T *ptr)
that would return a answer if ptr could be determined to point
to a declared object or subobject, a if not (e.g., it points to
allocated storage), and a if it couldn't be determined.
The built-in would then be used in code to eliminate infeasible
paths. For example, a built-in like that could be used to eliminate
the assert in string::f():
void string::f ()
{
if ( == __builtin_decl_p (s) && s != buf)
__builtin_unreac
gcc-9-20210108 is now available
Snapshot gcc-9-20210108 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210108/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 6fab822465a941e0f7c0861f34a76067d64c801c You'll find: gcc-9-20210108.tar.xzComplete GCC SHA256=cd0b73dd53d4f9304e4f81d48cb9e02b6dbad360b3272e1c5ab1dbd30196d0f4 SHA1=3e9c7c7056b7340cb38e3f51046c8a76ee1476b1 Diffs from 9-20210101 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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.
Adjust offset of array reference in named address space
Hi,
I'm implementing named addresses spaces for a Harvard architecture machine
to support copying data from instruction memory to data memory. This is
achieved via a special instruction. e.g. think AVR and progmem/__flash.
However, the instruction memory is narrower than the data memory (12 vs 16
bits) on this machine. So a single data word is split across 2 instruction
words. When copied from IMEM to DMEM the two parts are combined via SHIFT +
OR patterns.
This is all working fine for regular variables (i.e. int som_var), but it
falls apart for array references (i.e. some_array[1]). Since the data is
stored across 2 IMEM words, I need to scale the calculated offset of each
array reference by 2. e.g. array[0] is actually stored in imem[0] & imem[1]
and array[1] is stored in imem[2] & imem[3].
e.g.
static __imem int imem_array[2];
return imem_array[1];
// needs to generate a symbol reference like
&imem_array.869+2
Similarly if the array index was a function parameter, I need to scale the
parameter by 2.
__imem int imem_array[2];
int some_func(int a)
{
// a needs to be scaled by 2 when generating RTL/ASM
return imem_array[a];
}
I haven't found any target hooks that would allow me to override the offset
calculation. Originally I thought I could handle it in a splitter but this
approach didn't work for the function parameter example as I ended up
scaling the entire address instead of just the offset.
I had another thought of using a combo of
TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS and
TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P to scale the offset and mark it as
adjusted but I don't think this combo will work in the end.
Is there any way to achieve this?
Thanks,
Tucker
