[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 tim.vanholder at anubex dot com changed: What|Removed |Added CC||tim.vanholder at anubex dot ||com --- Comment #6 from tim.vanholder at anubex dot com 2012-08-08 21:10:24 UTC --- Daniel, your patch modifies the configure scripts, which are generated files - so the effect would be temporary at best. I don't have a gcc checkout handy (nor high-speed internet), so I can't check this myself right now, but: - If the configure.ac scripts use autoconf's own AC_LN_S macro, then a bug report should be submitted to the autoconf maintainers, and a GCC_LN_S macro would probably have to be created with the fix in place (to avoid depending on an upstream fix). Of course if autoconf uses all this internally, an upstream fix may be the only avenue. - If a gcc-specific macro is already being used (grep for "ln" or "cp -p" in the top-level "config" subdir (*.m4) to get an idea), then just put the fix(es) there Based on the variables seen in your patch it's probably going to be both (as_ln_s is an autoshell (part of autoconf) variable, gcc_cv_prog_LN_S sounds like a GCC-specific one). Once the macros are added/fixed, whatever script/command regenerates all the gcc configure scripts will propagate those changes automatically (and they will stay present even if a user regenerates a configure script). Note: I think I see an LN="cp -p" remain untouched in your patch - surely if the "ln -s" replacement needs to support directories, so does the one for plain ln?
[Bug tree-optimization/83733] New: -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733
Bug ID: 83733
Summary: -Wformat-overflow false positive for %d on bounded
integer when inlining
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.vanholder at anubex dot com
Target Milestone: ---
Given code similar to
struct foo {
char buf[9];
};
void fun(struct foo* pfoo, int report) {
if (report < 0 || report >= 32)
return;
...
sprintf (pfoo->buf, "CMPRT%02d", report);
}
There is no diagnostic when compiling without inlining active (which is
correct, given that report is constrained to [0,31], which does not overflow
%02d).
However, with optimizations enabled, I get errors like the following reported
for some (but not all) of fun()'s callers:
src.c: In function ‘caller_of_fun()’:
src.c:123:45: error: ‘%02d’ directive writing between 2 and 6 bytes into a
region of size 4 [-Werror=format-overflow=]
sprintf (pfoo->buf, "CMPRT%02d", report);
^~~~
src.c:123:45: note: directive argument in the range [-32768, 32767]
sprintf (pfoo->buf, "CMPRT%02d", report);
^~~
src.c:123:45: note: ‘sprintf’ output between 8 and 12 bytes into a destination
of size 9
sprintf (pfoo->buf, "CMPRT%02d", report);
^~~~
[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733 --- Comment #2 from Tim Van Holder --- Created attachment 43062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43062&action=edit Testcase Testcase attached. Compiling with "gcc -c -Wall -Wextra -Werror -O3 gcc83733.c" yields: gcc83733.c: In function ‘caller1’: gcc83733.c:33:44: error: ‘%02d’ directive writing between 2 and 6 bytes into a region of size 4 [-Werror=format-overflow=] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ gcc83733.c:33:38: note: directive argument in the range [-32768, 32767] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~ gcc83733.c:33:7: note: ‘sprintf’ output between 8 and 12 bytes into a destination of size 9 sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ gcc83733.c: In function ‘caller2’: gcc83733.c:33:44: error: ‘%02d’ directive writing between 2 and 6 bytes into a region of size 4 [-Werror=format-overflow=] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ gcc83733.c:33:38: note: directive argument in the range [-32768, 32767] sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~ gcc83733.c:33:7: note: ‘sprintf’ output between 8 and 12 bytes into a destination of size 9 sprintf (r->definition.ddname, "CMPRT%02d", foo); ^~~~ There seem to be several subtleties involved. For example, dropping the 'definition' struct (making 'ddname' a field directly in 'foo_t') changes the diagnostic, claiming there's 11 bytes in the target (slack space in the struct?).
[Bug driver/48520] New: "make install" for cross-compile silently clobbers target-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48520 Summary: "make install" for cross-compile silently clobbers target-gcc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: tim.vanhol...@anubex.com GCC 4.6.0 (from the svn tag) configured on i686-pc-linux-gnu with --prefix=/opt/experimental --target=mingw32 target_alias=mingw32 --program-prefix=mingw32- --program-suffix=-4.6.0 --enable-targets=mingw32,x86_64-w64-mingw32 --enable-multilib --disable-lto --disable-shared --enable-languages=c,c++ make all-gcc works fine (after adding w32api and mingwrt to the winsup subdirectory of the source tree) make install-gcc also apparently completes successfully however, mingw32-gcc-4.6.0 is NOT present in /opt/experimental/bin Looking more closely, make install-gcc does have messages on stderr: ln: accessing `mingw32-gcc-4.6.0': No such file or directory make: [install-driver] Error 1 (ignored) but they're buried in the many lines of output produced and apparently make is instructed not to care if the installation does not succeed... Looking at the commands run for the C++ driver, things are fine: rm -f /opt/experimental/bin/mingw32-g++-4.6.0 /usr/bin/install -c g++ /opt/experimental/bin/mingw32-g++-4.6.0 chmod a+x /opt/experimental/bin/mingw32-g++-4.6.0 rm -f /opt/experimental/bin/mingw32-c++-4.6.0 ( cd /opt/experimental/bin && \ ln mingw32-g++-4.6.0 mingw32-c++-4.6.0 ) same goes for the preprocessor: rm -f /opt/experimental/bin/mingw32-cpp-4.6.0 /usr/bin/install -c -m 755 cpp /opt/experimental/bin/mingw32-cpp-4.6.0 but for the C driver, it goes wrong: rm -f /opt/experimental/bin/mingw32-gcc-4.6.0 /usr/bin/install -c xgcc /opt/experimental/bin/mingw32-gcc-4.6.0 rm -f /opt/experimental/bin/mingw32-gcc-4.6.0 ( cd /opt/experimental/bin && \ ln mingw32-gcc-4.6.0 mingw32-gcc-4.6.0 ) so first it's installed fine, but then it gets removed and an attempt is made to hardlink the removed file to itself
[Bug bootstrap/48520] "make install" for cross-compile silently clobbers target-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48520
--- Comment #2 from tim.vanholder at anubex dot com 2011-04-11 06:56:27 UTC ---
Fair enough.
However, this was the _only_ (noticeable) breakage resulting from this
configuration.
If that's really all there is I don't see why this couldn't/shouldn't simply be
handled by the makefile rule.
Also, I don't really understand why it's ok for "make install" to silently
ignore errors during the creation of the (hard links to the) binaries in the
installation tree. That seems to be a rather fundamental aspect of "make
install".
If there are more (hidden) breakages resulting from this, maybe this
"program-prefix should not be '-'" rule should be enforced by configure
(as far as I can tell, it's not mentioned anywhere in the source tree).
In fact, gcc/configure currently includes
# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
test -n "$target_alias" &&
test "$program_prefix$program_suffix$program_transform_name" = \
NONENONEs,x,x, &&
program_prefix=${target_alias}-
so it even explictly sets the program prefix to the target_alias (if one is
given), meaning that even if I had not explicitly given
--program-prefix=mingw32-, configure would have set that up for me
automatically (provided I also left off the --program-suffix, which for a
cross-compiler would not be entirely needed either).
So I guess the only issue is when both prefix & suffix are set to the standard
ones used during installation, which should be handled perfectly well by
adjusting gcc/Makefile.am to only do the rm+ln if GCC_INSTALL_NAME does not
match the canon_target-gcc-version construct.
[Bug c/105346] New: -Wno-free-nonheap-object false positive (on Bison-generated grammar code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346 Bug ID: 105346 Summary: -Wno-free-nonheap-object false positive (on Bison-generated grammar code) Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tim.vanholder at anubex dot com Target Milestone: --- Bison grammars (can) include code like /* The state stack: array, bottom, top. */ yy_state_t yyssa[YYINITDEPTH]; yy_state_t *yyss = yyssa; yy_state_t *yyssp = yyss; ... (code that may allocate a larger stack if needed, in which case `yyss` and `yyssp` get repointed) #ifndef yyoverflow if (yyss != yyssa) YYSTACK_FREE (yyss); #endif (with YYSTACK_FREE() expanding to free()). For this gcc (Debian 11.2.0-19) 11.2.0 is reporting (with -Werror): Linux/DML-grammar.cc:13901:18: error: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Werror=free-nonheap-object] 13901 | YYSTACK_FREE (yyss); Linux/DML-grammar.cc:5609:16: note: declared here 5609 | yy_state_t yyssa[YYINITDEPTH]; |^ So it is tracing yyss to yyssa from its declaration, but is apparently not seeing that there is an explicit test that yyss is not equal to yyssa around the free. (I'd test with a more recent version, but this is what I have available.)
[Bug c/105346] -Wno-free-nonheap-object false positive (on Bison-generated grammar code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346 --- Comment #2 from Tim Van Holder --- Sorry, missed that update. Will see what I can do. It is a fairly large grammar; there are 8300 lines between the declaration and the free(). Not sure if that is likely to matter.
[Bug c/105346] -Wno-free-nonheap-object false positive (on Bison-generated grammar code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346 --- Comment #3 from Tim Van Holder --- Created attachment 52880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52880&action=edit testcase (redacted .ii file) Right, I managed to strip out all code I'm not allowed to share. I do seem to have messed up some of the location directives, so the warnings claim it's part of included files when it's not. This reproduces the warning, and even adds a second one of the exact same type (which is NOT shown with the unredacted source).
[Bug c++/105346] -Wno-free-nonheap-object false positive (on Bison-generated grammar code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346 Tim Van Holder changed: What|Removed |Added Component|c |c++ --- Comment #4 from Tim Van Holder --- Marking as C++ rather than C; while Bison generates C code, here it gets compiled in C++ context (with a namespace wrapped around Bison's symbols).
