[Bug c/94229] New: more clarification on the warning message from -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94229 Bug ID: 94229 Summary: more clarification on the warning message from -Wmisleading-indent Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: --- gcc issues the following warning message for -Wmisleading-indentation: test.c:632: note: -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers For a file test.c on its line #632, which looks very confusing to the user who got this message because 632 lines in a file is not big at all. is it possible to make the warning message more clear on why the size limit is met to help the user understand this better? >From my understanding of the gcc code in libcpp/line-map.[hc], looks like that the "size" here refs to source_location, and the source_location encoded both line num info and column num info.
[Bug c/94230] New: provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 Bug ID: 94230 Summary: provide an option to change the size limitation for -Wmisleading-indent Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: --- gcc issues the following warning message for -Wmisleading-indentation: test.c:632: note: -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers For a file test.c on its line #632. please provide an option to the user to change the limitation of the size.
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) > The size limitation is given from the way columns, lines, blocks and > location ranges are encoded in location_t, which is a 32-bit number. > See libcpp/include/line-map.h comment above location_t typedef. > If you have very long lines (I think more than 4095 columns), the code is > badly formatted and -Wmisleading-indentation just doesn't make sense. does this mean, for a 32-bit number, the size limitation cannot be changed anymore? if we use 64-bit number for it, will that resolve the issue?
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) > We do not want to use 64-bit number for that, it is used everywhere in the > compiler and would cause massive growth of compile time memory. understand, so, this request cannot be fixed?
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 --- Comment #7 from qinzhao at gcc dot gnu.org --- (In reply to David Malcolm from comment #6) > If you have a huge workload, one possible workaround would be to disable > range tracking, perhaps tweaking line_table->default_range_bits, which would > give you a bit more "headroom". IIRC we don't currently expose a way to do > this, and probably some extra code would be needed. It's currently > hardcoded to 5. > > Perhaps some kind of -fno-location-ranges? It could either: > (a) don't attempt to store location ranges (would probably have to disable > e.g. fix-it hints) > (b) set line_table->default_range_bits to 0, so that all ranges have to go > to the ad-hoc table, but buying space for more locations. I have tried the above (2) to set the line_table->default_range_bits to 0. and used this GCC to compile our huge application with -Wmisleading-indent, this time, the compiler works without the warning. and there are also some proper misleading-indent warning were emitted. So, I'd like to add one new gcc option -fno-location-range, whose implementation is to set line_table->default_range_bits to 0 to save more space for column tracking. Is this good to go?
[Bug sanitizer/91203] __asan_set_error_report_callback has no effect on leak messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91203 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #2)> > You are right, LSAN does not provide such a callback. Please create an > upstream feature request here: > https://github.com/google/sanitizers/issues > the feature request has been filed more than half year ago. I am wondering whether any patch has been delivered or not?
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 --- Comment #8 from qinzhao at gcc dot gnu.org --- (In reply to David Malcolm from comment #6) > If you have a huge workload, one possible workaround would be to disable > range tracking, perhaps tweaking line_table->default_range_bits, which would > give you a bit more "headroom". IIRC we don't currently expose a way to do > this, and probably some extra code would be needed. It's currently > hardcoded to 5. > > Perhaps some kind of -fno-location-ranges? It could either: > (a) don't attempt to store location ranges (would probably have to disable > e.g. fix-it hints) > (b) set line_table->default_range_bits to 0, so that all ranges have to go > to the ad-hoc table, but buying space for more locations. > Hi, David, I have sent a Patch review request to you (Cc'ing gcc-patc...@gcc.gnu.org) on 4/3/2020. this patch is per your above approach b. please take a look and let me know your opinion on it.
[Bug middle-end/94855] New: provide an option to initialize automatic variable for security purpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94855 Bug ID: 94855 Summary: provide an option to initialize automatic variable for security purpose Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: ---
[Bug middle-end/94855] provide an option to initialize automatic variable for security purpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94855 --- Comment #1 from qinzhao at gcc dot gnu.org --- this is a request to provide a new option in GCC to initialize automatic variables for security purpose. Motivations for this request: 1. Kees Cook's slide: https://outflux.net/slides/2019/lca/danger.pdf https://outflux.net/slides/2019/lpc/gcc-and-clang.pdf 2. LLVM's implementation: https://reviews.llvm.org/D54604 3. Kernal's plugin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/gcc-plugins/structleak_plugin.c)
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 qinzhao at gcc dot gnu.org changed: What|Removed |Added Version|10.0|11.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #10 from qinzhao at gcc dot gnu.org --- the patch has been committed to gcc11 today. closed as fixed.
[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 --- Comment #6 from qinzhao at gcc dot gnu.org --- So, based on the previous discussion on the LLVM option -ftrivial-auto-var-init=[uninitialized|pattern|zero] we can see: -ftrivial-auto-var-init=pattern might not be a good idea due to the following: 1. performance data is not good; 2. doesn't really help improve the general situation. People see it as a debugging tool, not a "improve code quality and improve the life of kernel developers" tool. (Per Linus) On the other hand, -ftrivial-auto-var-init=zero might be helpful to improve code quality and improve the life fo kernel developers. At the same time, a new variable attribute might be needed at the same time along with -ftrivial-auto-var-init=zero: __attribute((uninitialized) to mark variables that are uninitialized intentionally for performance purpose. In a summary, in GCC, we should provide: 1. add a new GCC option: -ftrivial-auto-var-init to initialize trivial auto variable to zero. 2. provide a new attribute for variable: __attribute((uninitialized) to mark variables that are uninitialized intentionally for performance purpose.
[Bug gcov-profile/95348] New: GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
Bug ID: 95348
Summary: GCC records zero functions and modules in the
profiling data file, ICC does NOT
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
when using GCC and ICC to build a big parallel application with profiling
feedback, the size of the profiling feedback data of GCC is over 20x times
larger than that of ICC.
As we studied, one of the major reason for this size difference is:
GCC records all functions and modules that execute 0 times, but ICC does NOT.
since I cannot expose the details of the real application that has the
profiling data size issue. I come up with a small testing case to show this
problem.
**testing case:
[]$ cat lib.h
void five (int);
void ten (int);
[]$ cat lib.c
#include
void five(int n) {
if (n > 5) {
printf("%d is greater than five\n", n);
} else {
printf("%d is not greater than five\n", n);
}
}
void ten(int n) {
if (n > 10) {
printf("%d is greater than ten\n", n);
} else {
printf("%d is not greater than ten\n", n);
}
}
[]$ cat ten.c
#include
#include "lib.h"
int main(int argc, char *argv[]) {
if (argc != 2) {
return 2;
}
int n = atoi(argv[1]);
ten(n);
return 0;
}
[]$ cat five.c
#include "lib.h"
void foo(int n) {
if (n > 0)
five(n);
return;
}
**ICC :
[]$ cat build_it_icc
#!/bin/bash
ICC=/ICC-install-dir/bin/icc
opt="-O0 "
opt_gen="-prof_gen"
opt_gen="$opt_gen -prof_dir ./icc_prof_dir"
tf1="five.c"
tf2="ten.c"
libf="lib.c"
rm *.o ten
rm -rf icc_prof_dir
mkdir icc_prof_dir
echo $ICC $opt $opt_gen -c $tf1 -o five.o
$ICC $opt $opt_gen -c $tf1 -o five.o
echo $ICC $opt $opt_gen -c $libf -o lib.o
$ICC $opt $opt_gen -c $libf -o lib.o
echo $ICC $opt $opt_gen -c $tf2 -o ten.o
$ICC $opt $opt_gen -c $tf2 -o ten.o
echo $ICC $opt $opt_gen ten.o five.o lib.o -o ten
$ICC $opt $opt_gen ten.o five.o lib.o -o ten
./ten 12
echo "Done"
[]$ sh build_it_icc
then we got the profiling data under
./icc_prof_dir/5ec6e83f_78751.dyn
using
/ICC-install-dir/bin/profmerge -dump 5ec6e83f_78751.dyn > data
we can see, only two functions, "main" in ten.c, and "ten" in lib.c have
records in this profiling data file.
**GCC: with latest upstream gcc11:
[]$ cat build_it_gcc
#!/bin/bash
GCC=/GCC-install-dir/bin/gcc
opt="-O0 "
opt="$opt -fno-inline"
opt_gen="-fprofile-generate"
opt_gen="$opt_gen -fprofile-dir=gcc_prof_dir/%p"
tf1="five.c"
tf2="ten.c"
libf="lib.c"
rm -rf gcc_prof_dir
echo $GCC $opt $opt_gen -c $libf
$GCC $opt $opt_gen -c $libf -o lib.o
echo $GCC $opt $opt_gen $tf1
$GCC $opt $opt_gen -c $tf1 -o five.o
echo $GCC $opt $opt_gen $tf2
$GCC $opt $opt_gen -c $tf2 -o ten.o
echo $GCC $opt $opt_gen ten.o five.o lib.o -o ten
$GCC $opt $opt_gen ten.o five.o lib.o -o ten
./ten 12
echo "Done"
[]$ build_it_gcc
then the profiling data are under
./gcc_prof_dir/16856
under ~/Bugs/profile/small_gcc/gcc_prof_dir/16856
[]$ ls -l
total 12
-rw-r--r-- 1 qinzhao qinzhao 100 May 26 19:18
#home#qinzhao#Bugs#profile#small_gcc#five.gcda
-rw-r--r-- 1 qinzhao qinzhao 184 May 26 19:18
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda
-rw-r--r-- 1 qinzhao qinzhao 100 May 26 19:18
#home#qinzhao#Bugs#profile#small_gcc#ten.gcda
[]$ /home/qinzhao/Install/latest/bin/gcov-dump *.gcda
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:data:magic `gcda':version
`B10e'
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:stamp 1375590637
#home#qinzhao#Bugs#profile#small_gcc#five.gcda: a100: 2:OBJECT_SUMMARY
runs=1, sum_max=1
#home#qinzhao#Bugs#profile#small_gcc#five.gcda: 0100: 3:FUNCTION
ident=1636255671, lineno_checksum=0x13fda123, cfg_checksum=0xc7b3f828
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:01a1: 6:COUNTERS
arcs 3 counts
#home#qinzhao#Bugs#profile#small_gcc#five.gcda:01af: 2:COUNTERS
time_profiler 1 counts
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:data:magic `gcda':version
`B10e'
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:stamp 1375590591
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda: a100: 2:OBJECT_SUMMARY
runs=1, sum_max=1
#home#qinzhao#Bugs#profile#small_gcc#lib.gcda: 0100: 3:FUNCTION
ident=1977925159, lineno_checksum=0x5bf41
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #3 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #2) > Thank you for the report. It's a known limitation Honza noticed me about. > Is the size problematic from size perspective or speed perspective? I think both size and speed. for the full execution of our application, the GCC's profiling data is too big to out of the disk space. at the same time, since we have to merge all the profiling data for different processes, the merging process take a long time due to so many profiling data files. > Have you tried compressing the gcda files? > > Anyway, I'm going to work on that this stage1. thanks a lot. this is a high priority task for us.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #5 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #4)> > Can you please share some statistics how big are the files and how many runs > do you merge? There were on the order of 10,000 processes. Source code coverage approximately 20%. Size of the profiling data gathered in the vicinity of 1TB. > Would it be possible to share 'gcov-dump -l' for all your .gcda files? It is impossible since too many .gdca files, each process has one directory, there are over 10,000 directories and under each directory, there are over thousand .gdca files. the situation is similar as the small testing case I added in the first comment. the functions and modules that do not execute have records in the .gdca file with zero counts.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #8 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #6 > Which means one run takes 100MB is size, right? As you mentioned, having > 1000 .gcda files, it means that one takes 0.1MB? around 14000 processes, they are not the same executable, so not all the run take the same size. some bigger, some smaller. the bigger ones take over 100MB. for the bigger one, there are over 5000 .gcda files. > Can you please provide dump of one directory? At least for portion of .gcda > files? > How is it common that an entire module is empty? I will try to get this info for you.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #9 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #7) > 1) You should not generate profile data for each process to a different > folder, but rather merge it. not sure how to do this? can you provide more details on this approach? > 2) I would like to know how long does one process run and what portion is > spent in merging (and dumping) of a profile. will try to get this info.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #15 from qinzhao at gcc dot gnu.org --- please refer to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #17 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #6) more details: > > Which means one run takes 100MB is size, right? As you mentioned, having > 1000 .gcda files, it means that one takes 0.1MB? > Out of the 14,239 processes, the amount of gcda data saved is: - Around 6500 processes in the 120-130M range. - Around 1000 processes in the 16M-18M range - Around 10 processes in the 736K - 764K range - Around 6000 processes in the 8K-32K range we are mostly interested in those 120-130M range, a typical process in the 130M bucket has over 5000 gcd files per directory. > > Can you please provide dump of one directory? At least for portion of .gcda > files? > How is it common that an entire module is empty? I compared the GCC profiling data and ICC profiling data for the similar process, the following are some interesting data: for GCC, among 5144 modules, there are 4308 empty modules, i.e 83% modules in GCC are empty; on function level, among all 187338 functions, only 3524 functions executed, i.e, 98% functions have zero counts. GCC records all the zero count functions and modules, But ICC ONLY records functions and modules that have non-zero count. So, GCC's profiling data is MUCH larger than ICC's. I believe that this is a big issue that need to be fixed from GCC.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #18 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #16) > > For our application, all processes generating profiling feedback data to a > > single directory seems is not a choice. > > Why is it problem? You need to provide reasoning for that. this is a long time ago. If I remembered correctly, we tried the scheme that all the processes generate profiling feedback data to the single directory, but looks like a lot of info got lost, resulting bad performance effect. then we switched to this current approach. > > > We chose -fprofile-dir=%p and then use gcov-merge to merge them. > > Sure, that's possible but you pay with a lot of disk space needed. > Btw. how long does it take to merge all the collected data with gcov-tool? I didn't get very accurate info on this, but it's over 24 hours for merging.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #24 from qinzhao at gcc dot gnu.org --- with the patch added to gcc11, I tested it with the small testing case, and got the following data: **without the patch: qinzhao@gcc14:~/Bugs/profile/small_gcc/gcc_prof_dir/13248$ ls -l -rw-r--r-- 1 qinzhao qinzhao 100 Jun 2 19:02 #home#qinzhao#Bugs#profile#small_gcc#five.gcda -rw-r--r-- 1 qinzhao qinzhao 184 Jun 2 19:02 #home#qinzhao#Bugs#profile#small_gcc#lib.gcda -rw-r--r-- 1 qinzhao qinzhao 100 Jun 2 19:02 #home#qinzhao#Bugs#profile#small_gcc#ten.gcda **with the patch: qinzhao@gcc14:~/Bugs/profile/small_gcc/gcc_prof_dir/20668$ ls -l -rw-r--r-- 1 qinzhao qinzhao 68 Jun 2 19:34 #home#qinzhao#Bugs#profile#small_gcc#five.gcda -rw-r--r-- 1 qinzhao qinzhao 144 Jun 2 19:34 #home#qinzhao#Bugs#profile#small_gcc#lib.gcda -rw-r--r-- 1 qinzhao qinzhao 100 Jun 2 19:34 #home#qinzhao#Bugs#profile#small_gcc#ten.gcda from the above data, we can see: 1. there are size reduction for "five.c" and "lib.c" as expected. 2. However, we still keep the *.gcda file for five.c even though there is no any meaningful data in this file. I will try to get more data on our real application. one question: why not just delete the entire records whose counter is zero and delete the entire file whose counter is zero?
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #36 from qinzhao at gcc dot gnu.org --- I found a bug with this proposed patch: when doing automatic merging, the following error message is emitted: Merge mismatch for function 1. the bug can be repeated with the small testing case I added in the comment #1 and the following script: #!/bin/bash GCC=/GCC-install-dir/bin/gcc opt="-O0 " opt="$opt -fno-inline" opt_gen="-fprofile-generate" opt_gen="$opt_gen -fprofile-dir=gcc_prof_dir" tf1="five.c" tf2="ten.c" libf="lib.c" rm -rf gcc_prof_dir echo $GCC $opt $opt_gen -c $libf $GCC $opt $opt_gen -c $libf -o lib.o echo $GCC $opt $opt_gen $tf1 $GCC $opt $opt_gen -c $tf1 -o five.o echo $GCC $opt $opt_gen $tf2 $GCC $opt $opt_gen -c $tf2 -o ten.o echo $GCC $opt $opt_gen ten.o five.o lib.o -o ten $GCC $opt $opt_gen ten.o five.o lib.o -o ten ./ten 12 ./ten 11 echo "Done" [qinzhao@localhost small_gcc]$ sh build_it_gcc /home/qinzhao/Install/latest-821/bin/gcc -O0 -fno-inline -fprofile-generate -fprofile-dir=gcc_prof_dir -c lib.c /home/qinzhao/Install/latest-821/bin/gcc -O0 -fno-inline -fprofile-generate -fprofile-dir=gcc_prof_dir five.c /home/qinzhao/Install/latest-821/bin/gcc -O0 -fno-inline -fprofile-generate -fprofile-dir=gcc_prof_dir ten.c /home/qinzhao/Install/latest-821/bin/gcc -O0 -fno-inline -fprofile-generate -fprofile-dir=gcc_prof_dir ten.o five.o lib.o -o ten 12 is greater than ten 11 is greater than ten profiling:gcc_prof_dir/#home#qinzhao#Bugs#profile#small_gcc#lib.gcda:Merge mismatch for function 1 profiling:gcc_prof_dir/#home#qinzhao#Bugs#profile#small_gcc#five.gcda:Merge mismatch for function 0 Done
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #37 from qinzhao at gcc dot gnu.org --- So, the previous prof data size for the real application might not be correct. After this bug is fixed, we might need to collect the new real code size reduction.
[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #39 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #38) > Created attachment 48738 [details] > Patch candidate v2 I have added this patch to my private gcc 8 with some change, works fine with the small testing case, and fixed the bug I reported in comment #36. > > There's a properly tested patch that supports all operations. > Please apply also pending patch: > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548206.html do I need to apply this as well in order to get the data from the real application? (note I need to apply the patch to gcc 8, this patch is not easy to be applied to gcc 8).
[Bug gcov-profile/91971] Profile directory concatenated with object file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 --- Comment #3 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #2) > Confirmed. Can you please send the patch to mailing list? I have sent the patch to gcc-patches several weeks ago, and pinged twice already: https://gcc.gnu.org/ml/gcc-patches//2019-10/msg01506.html are you the reviewer for this?
[Bug gcov-profile/91971] Profile directory concatenated with object file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 --- Comment #5 from qinzhao at gcc dot gnu.org --- Author: qinzhao Date: Wed Oct 23 18:12:39 2019 New Revision: 277344 URL: https://gcc.gnu.org/viewcvs?rev=277344&root=gcc&view=rev Log: 2019-10-23 qing zhao PR gcov-profile/91971 * coverage.c (coverage_init): Mangle the full path of filename when filename is a absolute path. Modified: trunk/gcc/ChangeLog trunk/gcc/coverage.c
[Bug gcov-profile/91971] Profile directory concatenated with object file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from qinzhao at gcc dot gnu.org --- the patch has been checked in upstream gcc today.
[Bug gcov-profile/92382] New: variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382
Bug ID: 92382
Summary: variable double-definition in routine
replace_filename_variables of
libgcc/libgcov-driver-system.c
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
In the routine replace_filename_variables of libgcc/libgcov-driver-system.c:
145 static char *
146 replace_filename_variables (char *filename)
147 {
148 char buffer[16];
149 char empty[] = "";
150 for (char *p = filename; *p != '\0'; p++)
151 {
152 unsigned length = strlen (filename);
153 if (*p == '%' && *(p + 1) != '\0')
154 {
155 unsigned start = p - filename;
156 p++;
157 char *replacement = NULL;
158 switch (*p)
159 {
160 case 'p':
161 sprintf (buffer, "%d", getpid ());
162 replacement = buffer;
163 p++;
164 break;
165 case 'q':
166 if (*(p + 1) == '{')
167 {
168 p += 2;
169 char *e = strchr (p, '}');
170 if (e)
171 {
172 *e = '\0';
173 replacement = getenv (p);
174 if (replacement == NULL)
175 replacement = empty;
176 p = e + 1;
177 }
178 else
179 return filename;
180 }
181 break;
182 default:
183 return filename;
184 }
185
186 /* Concat beginning of the path, replacement and
187 ending of the path. */
188 unsigned end = length - (p - filename);
189 unsigned repl_length = replacement != NULL ? strlen (replacement)
: 0;
190
191 char *buffer = (char *)xmalloc (start + end + repl_length + 1);
192 char *buffer_ptr = buffer;
193 buffer_ptr = (char *)memcpy (buffer_ptr, filename, start);
194 buffer_ptr += start;
195 if (replacement != NULL)
196 buffer_ptr = (char *)memcpy (buffer_ptr, replacement,
repl_length);
197 buffer_ptr += repl_length;
198 buffer_ptr = (char *)memcpy (buffer_ptr, p, end);
199 buffer_ptr += end;
200 *buffer_ptr = '\0';
201
202 free (filename);
203 filename = buffer;
204 p = buffer + start + repl_length;
205 }
206 }
207
208 return filename;
209 }
The major issue in the above code is: the "buffer" is redefined:
At line 148, "buffer" is defined outside the loop, the intend usage of this
"buffer" is at line 161 and 162 to hold the process id string for the
replacement of "%p";
However, At line 191, inside this same loop, "buffer" is defined again and
initialized to hold the new name of the whole filename, and the lifetime of
this "buffer" will overwrite the other "buffer" defined outside of the loop.
the fix to this problem is to rename the second "buffer" of line 183 to
another different name.
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) > Why is this a major issue? Just variable shadowing, so something that with > -Wshadow* compiler will warn, but nothing more, the code is well defined, > isn't it? when you print the value of "buffer" inside gdb at line 161, it's NULL, not a buffer with size 16. As a result, the sprint (buffer, "%d", get pic ()) at line 161 will write the processID to a NULL buffer, is this correct?
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #5 from qinzhao at gcc dot gnu.org --- Okay, I see. thank you for explanation. I will close this one as not a bug. (In reply to Jakub Jelinek from comment #4)
[Bug debug/92386] New: gdb issue with variable-shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92386
Bug ID: 92386
Summary: gdb issue with variable-shadowing
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gdb cannot print the correct value of variables if it's shadowed.
please see the following small testing case for an example:
1 #include
2 int
3 main ()
4 {
5 volatile int v = 0;
6 int i;
7 for (i=0; i < 3; i++)
8 {
9v++;
10v++;
11printf("i = %d outer v 1 is %d\n",i, v);
12volatile int v = 4;
13v++;
14printf("i = %d inner v is %d\n",i, v);
15 }
16 printf("outer v 2 is %d\n", v);
17 }
built it with the latest gcc10 and execute it, no problem:
[qinzhao@localhost ~]$ gcc t.c
[qinzhao@localhost ~]$ ./a.out
i = 0 outer v 1 is 2
i = 0 inner v is 5
i = 1 outer v 1 is 4
i = 1 inner v is 5
i = 2 outer v 1 is 6
i = 2 inner v is 5
outer v 2 is 6
However, when use gdb to check the value of variable v, we will see that at
line 9, 10, the value of "v" is incorrect:
(gdb) run
Starting program: /home/qinzhao/a.out
Breakpoint 1, main () at t.c:9
9 v++;
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-222.ora28641867.1.el7.x86_64
(gdb) print v
$1 = 32767
(gdb) n
10 v++;
(gdb) print v
$2 = 32767
(gdb) n
11 printf("i = %d outer v 1 is %d\n",i, v);
(gdb) n
i = 0 outer v 1 is 2
12 volatile int v = 4;
(gdb) n
13 v++;
(gdb) print v
$3 = 4
(gdb) n
14 printf("i = %d inner v is %d\n",i, v);
(gdb) print v
$4 = 5
(gdb) n
i = 0 inner v is 5
7for (i=0; i < 3; i++)
(gdb) n
Breakpoint 1, main () at t.c:9
9 v++;
(gdb) print v
$5 = 5
(gdb) n
10 v++;
(gdb) print v
$6 = 5
[Bug gcov-profile/92382] variable double-definition in routine replace_filename_variables of libgcc/libgcov-driver-system.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382 --- Comment #7 from qinzhao at gcc dot gnu.org --- I have just created a bug to record the debugging issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92386 (In reply to Jakub Jelinek from comment #6) > Feel free to open an issue against GDB or GCC< wherever the debug info issue > is e.g. for the #c4 testcase. Because certainly I see 0 as the value of v > even when it should be 1 or 2.
[Bug driver/93019] New: memory leak in gcc -O2 reported by Valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
Bug ID: 93019
Summary: memory leak in gcc -O2 reported by Valgrind
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
Valgrind reported 12 memory errors when I run the latest upstream gcc with -O2
on the following small testing case:
[qinzhao@localhost memory_leak]$ cat t1.c
int main(int argc, char** argv)
{
return 0;
}
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all
/home/qinzhao/Install/latest/bin/gcc -g -O2 t1.c
==29535== Memcheck, a memory error detector
==29535== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29535== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==29535== Command: /home/qinzhao/Install/latest/bin/gcc -g -O2 t1.c
==29535==
==29535==
==29535== HEAP SUMMARY:
==29535== in use at exit: 170,882 bytes in 80 blocks
==29535== total heap usage: 378 allocs, 298 frees, 218,175 bytes allocated
==29535==
==29535== 1 bytes in 1 blocks are still reachable in loss record 1 of 69
==29535==at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==29535==by 0x4E5E37: xmalloc (xmalloc.c:147)
==29535==by 0x4529D0: diagnostic_initialize(diagnostic_context*, int)
(diagnostic.c:179)
==29535==by 0x410EF7: driver::global_initializations() (gcc.c:7443)
==29535==by 0x410CD4: driver::main(int, char**) (gcc.c:7363)
==29535==by 0x41ACF8: main (gcc-main.c:47)
==29535==
==29535== 3 bytes in 1 blocks are still reachable in loss record 2 of 69
==29535==at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==29535==by 0x4E5E37: xmalloc (xmalloc.c:147)
==29535==by 0x414186: save_string(char const*, int) (gcc.c:8495)
==29535==by 0x40CAEF: do_spec_1(char const*, int, char const*) (gcc.c:5611)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==by 0x40EE3A: handle_braces(char const*) (gcc.c:6507)
==29535==by 0x40D94B: do_spec_1(char const*, int, char const*) (gcc.c:5924)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==by 0x40EE3A: handle_braces(char const*) (gcc.c:6507)
==29535==by 0x40D94B: do_spec_1(char const*, int, char const*) (gcc.c:5924)
==29535==by 0x40DD59: do_spec_1(char const*, int, char const*) (gcc.c:6039)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==
==29535== 3 bytes in 1 blocks are still reachable in loss record 3 of 69
==29535==at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==29535==by 0x4E5E37: xmalloc (xmalloc.c:147)
==29535==by 0x414186: save_string(char const*, int) (gcc.c:8495)
==29535==by 0x40CAEF: do_spec_1(char const*, int, char const*) (gcc.c:5611)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==by 0x40EE3A: handle_braces(char const*) (gcc.c:6507)
==29535==by 0x40D94B: do_spec_1(char const*, int, char const*) (gcc.c:5924)
==29535==by 0x40DD59: do_spec_1(char const*, int, char const*) (gcc.c:6039)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==by 0x40EE3A: handle_braces(char const*) (gcc.c:6507)
==29535==by 0x40D94B: do_spec_1(char const*, int, char const*) (gcc.c:5924)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==
==29535== 5 bytes in 1 blocks are still reachable in loss record 4 of 69
==29535==at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==29535==by 0x4E5E37: xmalloc (xmalloc.c:147)
==29535==by 0x414186: save_string(char const*, int) (gcc.c:8495)
==29535==by 0x40CAEF: do_spec_1(char const*, int, char const*) (gcc.c:5611)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==by 0x40EE3A: handle_braces(char const*) (gcc.c:6507)
==29535==by 0x40D94B: do_spec_1(char const*, int, char const*) (gcc.c:5924)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==by 0x40EE3A: handle_braces(char const*) (gcc.c:6507)
==29535==by 0x40D94B: do_spec_1(char const*, int, char const*) (gcc.c:5924)
==29535==by 0x40F02E: process_brace_body(char const*, char const*, char
const*, int, int) (gcc.c:6599)
==29535==by 0x40EE3A: handle_braces(char const*) (gcc.c:6507)
==29535==
==29535== 6 bytes in 1 blocks are still reachable in loss record 5 of 69
==29535==at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==29535==by 0x4E5E37: xmalloc (xmalloc.c:147)
==29535==by 0x4E5FB0: xstrdup (xstrdup
[Bug sanitizer/89832] confusing error message when there is a problem with ASAN_OPTIONS "ERROR: expected '='"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 --- Comment #11 from qinzhao at gcc dot gnu.org --- Hi, (In reply to Martin Liška from comment #10) > Fixed on trunk. I am trying to back port the fix for 89832 into our company's gcc8.2.1 release. by looking at the patch, it's huge, and it's include the patches for both 89832 and 91325. when I generated the patch from gcc trunk and applied it into our gcc8.2.1 release, a lot of issues. So, I am wondering whether there is any better way to do this: 1. Can I just simply replace all the files under gcc/libsantinizer in gcc8.2.1 with the new files? 2. if not, what is the patch ONLY for 89832?
[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #5 from qinzhao at gcc dot gnu.org --- the patch has been put back into trunk as revision 261039: https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=261039
[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from qinzhao at gcc dot gnu.org --- the change is in trunk, I am closing this bug.
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 83026, which changed state. Bug 83026 Summary: missing strlen optimization for strcmp of unequal strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #35 from qinzhao at gcc dot gnu.org --- the second part of the implementation is checked into gcc9 today as: https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=261039
[Bug gcov-profile/91971] New: Profile directory concatenated with object file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 Bug ID: 91971 Summary: Profile directory concatenated with object file path Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- we noticed that the profile directory will be concatenated with object file path. the following small example explain this behavior: [qinzhao@localhost small]$ cat t #! /bin/bash CC=/home/qinzhao/Install/latest/bin/gcc opt="-O3 -fprofile-generate" opt="$opt -fprofile-dir=/home/qinzhao/prof_dir" opt="$opt -c -o /home/qinzhao/obj_dir/t.o" tf="t.c" echo $CC $opt $tf $CC $opt $tf strings /home/qinzhao/obj_dir/t.o | grep prof_dir [qinzhao@localhost small]$ sh t /home/qinzhao/Install/latest/bin/gcc -O3 -fprofile-generate -fprofile-dir=/home/qinzhao/prof_dir -c -o /home/qinzhao/obj_dir/t.o t.c /home/qinzhao/prof_dir//home/qinzhao/obj_dir/t.gcda [qinzhao@localhost small]$ From the above, we can see: when specifying the profiling directory with -fprofile-dir as “/home/qinzhao/prof_dir”, the user expects that the profiling data will be stored in this specific directory. However, GCC concatenates the profiling directory “/home/qinzhao/prof_dir” with the path for the object file “/home/qinzhao/obj_dir” together. As a result, the profiling data will be stored to: /home/qinzhao/prof_dir/home/qinzhao/obj_dir/ instead of /home/qinzhao/prof_dir This looks like a bug to me.
[Bug c/91973] New: gcc failed for Multiple level macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
Bug ID: 91973
Summary: gcc failed for Multiple level macro expansion
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
GCC cannot compile the following small testing case:
[qinzhao@localhost]$ cat t1.c
extern void boo (void *addr);
#define foo(addr) \
boo (addr)
#define bar(instr, addr) \
(instr) (addr)
void check (void *addr)
{
bar(foo, addr);
}
[qinzhao@localhost]$ sh t
/home/qinzhao/Install/latest/bin/gcc -O -S t1.c
t1.c: In function ‘check’:
t1.c:11:7: error: ‘foo’ undeclared (first use in this function); did you mean
‘boo’?
11 | bar(foo, addr);
| ^~~
t1.c:7:4: note: in definition of macro ‘bar’
7 | (instr) (addr)
|^
t1.c:11:7: note: each undeclared identifier is reported only once for each
function it appears in
11 | bar(foo, addr);
| ^~~
t1.c:7:4: note: in definition of macro ‘bar’
7 | (instr) (addr)
|^
However, if I delete the parantheses from the macro bar as following:
#define bar(instr, addr) \
instr (addr)
The compilation succeed.
also icc can successfully compile the original small testing case.
[Bug c/91973] gcc failed for Multiple level macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973 --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Joseph S. Myers from comment #1) > This is not a bug in GCC, it's how the preprocessor is defined to work. So, this is an user error? is there any C language rules on this? why icc works on this?
[Bug c/91973] gcc failed for Multiple level macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973 --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #3) > Macro replacement for function-like macros is defined in C17 6.10.3. > Note in paragraph 10 the words "the function-like macro name followed by a > ( as the next preprocessing token". In your example foo ends up followed > by ) not ( as the next preprocessing token. could you please explain a little more of the above, for the following macro definition: #define foo(addr) \ boo (addr) foo is followed by ( but not ), right? do I miss anything here?
[Bug c/91973] gcc failed for Multiple level macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973 --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #5) > We're talking about the sequence of pp-tokens in the expansion of bar(foo, > addr), which is (foo) (addr), where foo is followed by ), not about the > definition. okay, now I understand and agree. > > Please take any further questions on this to gcc-help; this question is > not appropriate for Bugzilla since it does not involve a bug or any other > kind of deficiency in GCC. Okay.
[Bug gcov-profile/91971] Profile directory concatenated with object file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971
--- Comment #1 from qinzhao at gcc dot gnu.org ---
the following simple patch will fix this issue:
$ git diff coverage.c
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 0d5138f..a80337e 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1229,6 +1229,11 @@ coverage_init (const char *filename)
else
profile_data_prefix = getpwd ();
}
+ else
+{
+ filename = mangle_path (filename);
+ len = strlen (filename);
+}
if (profile_data_prefix)
prefix_len = strlen (profile_data_prefix);
[Bug tree-optimization/89730] New: -flive-patching=inline-only-static should grant always_inline attribute for extern function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89730
Bug ID: 89730
Summary: -flive-patching=inline-only-static should grant
always_inline attribute for extern function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
for the following small testing case:
extern int sum, n, m;
extern inline __attribute__((always_inline)) int foo (int a);
inline __attribute__((always_inline)) int foo (int a)
{
return a + n;
}
static int bar (int b)
{
return b * m;
}
int main()
{
sum = foo (m) + bar (n);
return 0;
}
with the latest upstream gcc9:
/home/qinzhao/Install/latest/bin/gcc -O3 -flive-patching=inline-only-static
-fdump-tree-einline -fdump-ipa-inline -fopt-info-inline-all=inline.txt t.c
t.c: In function ‘main’:
t.c:7:43: error: inlining failed in call to always_inline ‘foo’: function has
external linkage when the user requests only inlining static for live patching
7 | inline __attribute__((always_inline)) int foo (int a)
| ^~~
t.c:20:9: note: called from here
20 | sum = foo (m) + bar (n);
| ^~~
t.c:7:43: error: inlining failed in call to always_inline ‘foo’: function has
external linkage when the user requests only inlining static for live patching
7 | inline __attribute__((always_inline)) int foo (int a)
| ^~~
t.c:20:9: note: called from here
20 | sum = foo (m) + bar (n);
| ^~~
We should grant extern alway_inline routine to be inlined even with
-flive-patching=inline-only-static.
[Bug tree-optimization/89730] -flive-patching=inline-only-static should grant always_inline attribute for extern function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89730 --- Comment #2 from qinzhao at gcc dot gnu.org --- Author: qinzhao Date: Wed Apr 3 19:00:25 2019 New Revision: 270134 URL: https://gcc.gnu.org/viewcvs?rev=270134&root=gcc&view=rev Log: 2019-04-03 qing zhao PR tree-optimization/89730 * ipa-inline.c (can_inline_edge_p): Delete the checking for -flive-patching=inline-only-static. (can_inline_edge_by_limits_p): Add the checking for -flive-patching=inline-only-static and grant always_inline even when -flive-patching=inline-only-static is specified. * gcc.dg/live-patching-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/live-patching-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/89832] confusing error message when there is a problem with ASAN_OPTIONS "ERROR: expected '='"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 --- Comment #6 from qinzhao at gcc dot gnu.org --- one question to Martin: has the proposed patch been committed in gcc9 upstream? my understanding is the proposed patch is for LLVM source base, not for GCC. are you planning to port the patch to gcc9?
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #23 from qinzhao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #7) > Created attachment 27869 [details] > Patch for adding merge-gcda > > here is the patch which adds merge-gcda . I don't add any testcases as it > is currently designed only for how Cavium's Simple-exec works in that each > core writes out its own gcda file. I recently found this bug due to a similar problem. looks like that there are two parts of work for this problem: 1. GCC's new feature to guarantee that all pre-merged files are saved with different names for different instances of the same process. 2. a merge tool to merge all the gcda files afterwards. from my understanding, the patch for the above 1 has been committed into GCC9. How about the patch for the above 2? has it been committed?
[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 --- Comment #25 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #24) > > > How about the patch for the above 2? has it been committed? > > It has been there for a while, please take a look at: > > $ gcov-tool merge --help > merge: unrecognized option '--help' > Merge subcomand usage: merge [options] Merge coverage > file contents > -o, --output Output directory > -v, --verbose Verbose mode > -w, --weight Set weights (float point values) two more questions on this merge tool: 1. it can only merge two directories at one time. So, for multiple directories, for example "n", we have to invoke gcov-tool merge n-1 times in order to merge all of them? 2. Intel compiler (icc)'s profmerge is able to merge all the .dyn files under one directory, does gcc have such functionality currently?
[Bug preprocessor/90581] New: provide an option to adjust the maximum depth of nested #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 Bug ID: 90581 Summary: provide an option to adjust the maximum depth of nested #include Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: --- for some large complicate applications, sometimes the depth of nested #include might be very big, exceeding the current hard-coded limit 200: directives.c: if (pfile->line_table->depth >= CPP_STACK_MAX) cpp_error (pfile, CPP_DL_ERROR, "#include nested too deeply"); internal.h: #define CPP_STACK_MAX 200 This PR is to request a first class option for users to adjust this limit during compilation time in order to compile the large application successfully.
[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > Confirmed. Just curious - were you able to simply up this limit > successfully? Yes, one of our applications' depth of nested #include is 202
[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 --- Comment #3 from qinzhao at gcc dot gnu.org --- Author: qinzhao Date: Tue Jul 2 20:23:30 2019 New Revision: 272948 URL: https://gcc.gnu.org/viewcvs?rev=272948&root=gcc&view=rev Log: PR preprocessor/90581 Add a cpp option -fmax-include-depth to set the maximum depth of the nested #include. Added: trunk/gcc/testsuite/c-c++-common/cpp/fmax-include-depth-1a.h trunk/gcc/testsuite/c-c++-common/cpp/fmax-include-depth-1b.h trunk/gcc/testsuite/c-c++-common/cpp/fmax-include-depth.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/doc/cppopts.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/include/cpplib.h trunk/libcpp/init.c trunk/libcpp/internal.h
[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 qinzhao at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot gnu.org --- Comment #4 from qinzhao at gcc dot gnu.org --- the patch has been committed into upstream as today.
[Bug ipa/86395] New: add support of -fopt-info-inline in early inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395
Bug ID: 86395
Summary: add support of -fopt-info-inline in early inliner
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
currently, -fopt-info-inline does not report any info from early inliner.
for example:
[qinzhao@localhost inline_report]$ cat inline_1.c
static int foo (int a)
{
return a + 10;
}
static int bar (int b)
{
return b - 20;
}
static int boo (int a, int b)
{
return foo (a) + bar (b);
}
extern int v_a, v_b;
extern int result;
int compute ()
{
result = boo (v_a, v_b);
return result;
}
[qinzhao@localhost inline_report]$ /home/qinzhao/Install/latest/bin/gcc -O3
-fopt-info-inline-optimized-missed=inline.txt inline_1.c -S
[qinzhao@localhost inline_report]$ ls -l inline.txt
-rw-rw-r--. 1 qinzhao qinzhao 0 Jul 3 11:25 inline.txt
[qinzhao@localhost inline_report]$ cat inline_1.s
.file "inline_1.c"
.text
.p2align 4,,15
.globl compute
.type compute, @function
compute:
.LFB3:
.cfi_startproc
movlv_a(%rip), %edx
movlv_b(%rip), %eax
leal-10(%rdx,%rax), %eax
movl%eax, result(%rip)
ret
.cfi_endproc
.LFE3:
.size compute, .-compute
.ident "GCC: (GNU) 9.0.0 20180702 (experimental)"
.section.note.GNU-stack,"",@progbits
From the above, we can see:
1. the call chains to —>“boo”->”foo”, “bar” in the routine “compute” are
completely inlined by early inliner into “compute”;
2. However, there is NO any inline information is dumped into “inline.txt”.
This PR is to request -fopt-info-inline support for early inliner
[Bug middle-end/86467] New: inlining strcmp with small known length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86467 Bug ID: 86467 Summary: inlining strcmp with small known length array Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: --- from Martin Sebor: an enhancement to this optimization implemented for 78809 that might be worth considering is inlining even non-constant calls with array arguments whose size is no greater than the limit. As in: extern char a[4], *b; int n = strcmp (a, b); Because strcmp arguments are required to be nul-terminated strings, a's length above must be at most 3. This is analogous to similar optimizations GCC performs, such as folding to zero calls to strlen() with one-element arrays.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #36 from qinzhao at gcc dot gnu.org --- the 3rd part (the last part) of this PR was checked into GCC 9 today as: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262636
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #37 from qinzhao at gcc dot gnu.org --- since all the implementation were in trunk. can I close this PR now?
[Bug testsuite/86519] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #1 from qinzhao at gcc dot gnu.org --- I cannot repeat this issue on a powerPc machine: Native configuration is powerpc64-unknown-linux-gnu === gcc tests === Schedule of variations: unix Running target unix Running /home/qinzhao/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/dg.exp ... PASS: gcc.dg/strcmpopt_6.c (test for excess errors) PASS: gcc.dg/strcmpopt_6.c execution test PASS: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 4
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-17 Ever confirmed|0 |1 --- Comment #6 from qinzhao at gcc dot gnu.org --- Yes, I can repeat the failure on gcc112. will continue debugging it
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #42 from qinzhao at gcc dot gnu.org --- just checked in the patch for fixing the unsigned char issue as: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262907
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #7 from qinzhao at gcc dot gnu.org --- the root cause for this bug is: for the following call to memcmp: __builtin_memcmp (s->s, "a", 3); the specified length 3 is larger than the length of "a", it's clearly a out-of-bound access. This new testing case is try to claim that, For such out-of-bound access, we should NOT expand this call at all. The new added in-lining expansion was prohibited under such situation, However, the expansion to hardware compare insn (old code) is NOT prohibited under such situation. on powerPC, the above call to memcmp is expanded to hardware compare insn. therefore, the testing case failed.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #46 from qinzhao at gcc dot gnu.org --- https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263028 was to fix the optimization level issue.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #14 from qinzhao at gcc dot gnu.org --- reported by christophe.l...@linaro.org: After this change,(disable strcmp/strncmp inlining with O2 below and Os), I've noticed that: FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 6 on arm-none-linux-gnueabi --with-mode thumb --with-cpu cortex-a9 and forcing -march=armv5t via RUNTESTFLAGS The log says: gcc.dg/strcmpopt_6.c: pattern found 4 times FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 6 although this is NOT the exactly same bug as this PR, I listed here to fix the testcase all together with this PR.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #15 from qinzhao at gcc dot gnu.org --- Created attachment 44516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44516&action=edit proposed patch
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #16 from qinzhao at gcc dot gnu.org --- please test the proposed patch on your platform, let me know the result.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #17 from qinzhao at gcc dot gnu.org --- the patch has been committed as: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #19 from qinzhao at gcc dot gnu.org --- which sparc machine was used to repeat the failure, and what's the configure and make options?
[Bug jit/64949] jit linking fails when building with in-tree libraries (mpc etc...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64949 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #1 from qinzhao at gcc dot gnu.org --- GCC7, 8, and 9 all have the same issue as my latest experiments. Will a fix to this issue be available soon?
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #21 from qinzhao at gcc dot gnu.org --- the latest patch to this test bug has just been checked in at: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263983
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #47 from qinzhao at gcc dot gnu.org --- all the issues triggered by the previous patch have been fixed. I am planing to close this PR as fixed.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from qinzhao at gcc dot gnu.org --- the fix has been committed into upstream.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #48 from qinzhao at gcc dot gnu.org --- all the issues have been resolved. close this one as fixed.
[Bug gcov-profile/86957] gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 --- Comment #6 from qinzhao at gcc dot gnu.org --- Author: qinzhao Date: Wed Sep 26 22:29:54 2018 New Revision: 264657 URL: https://gcc.gnu.org/viewcvs?rev=264657&root=gcc&view=rev Log: 2018-09-26 Indu Bhagat PR gcov-profile/86957 * common.opt: New warning option -Wmissing-profile. * coverage.c (get_coverage_counts): Add warning for missing .gcda file. * doc/invoke.texi: Document -Wmissing-profile. Added: trunk/gcc/testsuite/gcc.dg/Wmissing-profile.c Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/coverage.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/99328] New: ICE: in verify_target_availability, at sel-sched.c:1557 with -fselective-scheduling2 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99328
Bug ID: 99328
Summary: ICE: in verify_target_availability, at
sel-sched.c:1557 with -fselective-scheduling2 on
aarch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gcc11 has the following ICE:
$ cat t.c
long a;
double b, c;
double fn1(double);
void fn2(long *);
void fn3(int p1) {
fn2(&a);
if (fn1(0) >= p1)
b = c;
}
$ sh t
/data1/qing/Install/latest/bin/gcc -fprofile-generate -Ofast
-fselective-scheduling -fselective-scheduling2 -c -o t.o t.c
during RTL pass: sched2
t.c: In function 'fn3':
t.c:9:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1557
9 | }
| ^
0xd86fbb verify_target_availability
../../latest_gcc/gcc/sel-sched.c:1553
0xd86fbb find_best_reg_for_expr
../../latest_gcc/gcc/sel-sched.c:1667
0xd89f33 fill_vec_av_set
../../latest_gcc/gcc/sel-sched.c:3784
0xd89f33 fill_ready_list
../../latest_gcc/gcc/sel-sched.c:4014
0xd89f33 find_best_expr
../../latest_gcc/gcc/sel-sched.c:4374
0xd89f33 fill_insns
../../latest_gcc/gcc/sel-sched.c:5535
0xd8ba17 schedule_on_fences
../../latest_gcc/gcc/sel-sched.c:7353
0xd8ba17 sel_sched_region_2
../../latest_gcc/gcc/sel-sched.c:7491
0xd8c517 sel_sched_region_1
../../latest_gcc/gcc/sel-sched.c:7533
0xd8e573 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7634
0xd8f1b7 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0xd6a32f rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0xd6a32f execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
this is a reduced testing case from CPU2017 511.povray.
gcc10 has the same issue.
[Bug rtl-optimization/99332] New: ICE:inreset_sched_cycles_in_current_ebb, at sel-sched.c:7147 with -fprofile-generate -O3 -fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99332
Bug ID: 99332
Summary: ICE:inreset_sched_cycles_in_current_ebb, at
sel-sched.c:7147 with -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2
-fsel-sched-pipelining
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
This testing case is reduced from CPU2017 511.povray, it appears on aarch64
with both gcc11 and gcc10:
$ cat t.C
class OStream {
public:
void printf(...);
};
typedef double VECTOR[3];
enum { X, Y, Z };
typedef struct ot_block_struct OT_BLOCK;
typedef int OT_NODE;
struct ot_block_struct {
OT_BLOCK *next;
VECTOR Point, S_Normal;
VECTOR To_Nearest_Surface;
short Bounce_Depth;
};
bool ot_write_block(OT_BLOCK *, void *);
bool ot_traverse(OT_NODE *, bool function(OT_BLOCK *, void *), void *handle) {
bool oksofar;
OT_BLOCK *this_block;
while (this_block) {
function(this_block, handle);
this_block = this_block->next;
}
return oksofar;
}
bool ot_save_tree() {
int *fd, *root;
ot_traverse(root, ot_write_block, fd);
}
bool ot_write_block(OT_BLOCK *bl, void *fd) {
((OStream *)fd)->printf(
bl[Z], bl->S_Normal[X] * int(bl->S_Normal[Z] * .5 * 254. + .49),
bl[Z], int(bl->To_Nearest_Surface[X]),
int((bl->To_Nearest_Surface[Y] + 1.) * .5 * 254. + .49),
int((bl->To_Nearest_Surface[Z] + 1.) * .5 * 254. + .49));
return true;
}
[qzlocal@ca-dev-arm06 bug_2]$ sh t
/data1/qing/Install/latest/bin/g++ -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining -c -o t.o
t.C
t.C: In function 'bool ot_save_tree()':
t.C:29:1: warning: no return statement in function returning non-void
[-Wreturn-type]
29 | }
| ^
during RTL pass: sched2
t.C:29:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7147
0x1063387 reset_sched_cycles_in_current_ebb
../../latest_gcc/gcc/sel-sched.c:7147
0x1063387 sel_region_target_finish
../../latest_gcc/gcc/sel-sched.c:7220
0x1063387 sel_region_finish
../../latest_gcc/gcc/sel-sched.c:7276
0x1063387 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7645
0x1063593 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0x103e70b rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0x103e70b execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
CPU2017 511.povray cannot be compiled on aarch64 due to this bug.
[Bug rtl-optimization/99421] New: ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421 Bug ID: 99421 Summary: ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: --- with the attached tar file, (from CPU2017 502.gcc_r) untar it, cd bug_3 sh t during RTL pass: sched2 predict.c: In function ‘expr_expected_value_1’: predict.c:1263:1: internal compiler error: in code_motion_process_successors, at sel-sched.c:6389 0xd83883 code_motion_process_successors ../../latest_gcc_2/gcc/sel-sched.c:6386 0xd83883 code_motion_path_driver ../../latest_gcc_2/gcc/sel-sched.c:6609 0xd834f7 code_motion_process_successors ../../latest_gcc_2/gcc/sel-sched.c:6343 0xd834f7 code_motion_path_driver ../../latest_gcc_2/gcc/sel-sched.c:6609 0xd8645f move_op ../../latest_gcc_2/gcc/sel-sched.c:6702 0xd8645f move_exprs_to_boundary ../../latest_gcc_2/gcc/sel-sched.c:5224 0xd8645f schedule_expr_on_boundary ../../latest_gcc_2/gcc/sel-sched.c:5436 0xd87be3 fill_insns ../../latest_gcc_2/gcc/sel-sched.c:5578 0xd8a143 schedule_on_fences ../../latest_gcc_2/gcc/sel-sched.c:7353 0xd8a143 sel_sched_region_2 ../../latest_gcc_2/gcc/sel-sched.c:7491 0xd8ac43 sel_sched_region_1 ../../latest_gcc_2/gcc/sel-sched.c:7533 0xd8cc83 sel_sched_region(int) ../../latest_gcc_2/gcc/sel-sched.c:7634 0xd8d8d7 run_selective_scheduling() ../../latest_gcc_2/gcc/sel-sched.c:7720 0xd68977 rest_of_handle_sched2 ../../latest_gcc_2/gcc/sched-rgn.c:3738 0xd68977 execute ../../latest_gcc_2/gcc/sched-rgn.c:3882 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. NOTE, this error is repeated with -fprofile-use, and the pre-generated profiling data file predict.gcda is generated with gcc11 as following: Target: aarch64-unknown-linux-gnu Configured with: ../latest_gcc_2/configure --prefix=/home/qinzhao/Install/latest-2 --enable-languages=c,c++,fortran,lto --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.1 20210304 (experimental) (GCC) since the error depends on the profiling feedback data, the testing case cannot be reduced by hand or by tool (Creduce), I have to attach the complete preprocessed file to repeat the error.
[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421 --- Comment #2 from qinzhao at gcc dot gnu.org --- Created attachment 50318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50318&action=edit tar ball to repeat the failure
[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421 --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) > Confirmed, reduced test-case: > just curious, how did you reduce the testing case with -fprofile-use? (I tried Creduce, but failed) another question, how to repeat the failure with this reduced testing case?
[Bug rtl-optimization/99627] New: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627 Bug ID: 99627 Summary: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-aliasing Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: qinzhao at gcc dot gnu.org Target Milestone: --- Another selective scheduler's bug with profiling feedback from CPU2017. reduced testing case attached. to reproduce: download the *.tar.xz file; untar it; cd bug_4 sh t qinzhao@gcc113:~/Bugs/bug_4$ sh t during RTL pass: sched1 cfgloop.h: In function ‘loop_optimizer_finalize’: cfgloop.h:41:1: internal compiler error: in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 0xcb24b3 sel_is_loop_preheader_p(basic_block_def*) ../../latest_gcc/gcc/sel-sched-ir.c:6347 0xcc5307 sel_sched_region_1 ../../latest_gcc/gcc/sel-sched.c:7588 0xcc68bb sel_sched_region(int) ../../latest_gcc/gcc/sel-sched.c:7634 0xcc68bb sel_sched_region(int) ../../latest_gcc/gcc/sel-sched.c:7619 0xcc6ae7 run_selective_scheduling() ../../latest_gcc/gcc/sel-sched.c:7720 0xca511f rest_of_handle_sched ../../latest_gcc/gcc/sched-rgn.c:3724 0xca511f execute ../../latest_gcc/gcc/sched-rgn.c:3834 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627 --- Comment #1 from qinzhao at gcc dot gnu.org --- Created attachment 50411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50411&action=edit testing case and script testing case and script
[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627 --- Comment #2 from qinzhao at gcc dot gnu.org --- NOTE, this failure is on aarch64.
[Bug tree-optimization/100053] New: tree-fre incorrectly delete a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
Bug ID: 100053
Summary: tree-fre incorrectly delete a condition
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
hi, this is a bug with tree-fre optimization that caused run-time segmentation
fault.
the original testing case cannot be posted.
the following is the reduced testing case through Creduce.
ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ cat ksm.i
typedef a;
typedef struct b b;
struct {
char c
} typedef d;
struct e {
int f;
char g
} typedef aa;
struct {
int ad;
char ae
} typedef ab;
struct {
int ac;
char ah;
int ai;
a *h;
b *ag
} typedef af;
struct b {
af i;
struct e *j
} m;
k, o, q, r, s, t, u;
typedef l[];
l n;
*p;
ab al;
v(init) {
d *aj;
int ak;
if (!init) {
w();
aj = q;
if (p[t])
goto aq;
af am = (&m)->i;
if (_setjmp())
if ((&m)->i.h) {
a an, ao;
aa *ap = am.h[(&m)->i.ai];
void *au;
if ((&m)->i.ai) {
if (x())
an += (long)au % (&m)->i.ag->j->f;
if ((a)__builtin_alloca)
ao = au = an;
ap->g = "";
}
y(ao);
}
ak |= z(n[k], ak, init ? 0 : ((int *)o)[t]);
(&al)->ad = (&m)->i.ac & (&m)->i.ah;
(&m)->i.ac = (&al)->ae = &al;
}
if (!init)
aj->c = s;
ar(u, r, s);
aq:
if (!init)
as(((int *)o)[t]);
}
ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ cat t
/home/ubuntu/Install/latest-debug/bin/gcc ksm.i -c -o ksm.o -O2
-fdump-tree-optimized
ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ sh t
there are quite some warnings during compilation, please ignore them.
check the ksm.i.244t.optimized, you will find that the last "if (!init)" is
completely deleted;
if you add -fno-tree-fre to the compilation line, the last "if (!init)" will
not be deleted anymore.
[Bug tree-optimization/100053] [9/10 Regression] tree-fre incorrectly delete a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> It would be nice if the reduced testcase could be sanitized to throw less
> diagnostics with -Wall, likewise if it were a runtime testcase.
>
> Reduced:
>
> int __attribute__((returns_twice,noipa)) x() { return 0; }
> void __attribute__((noipa)) ar() {}
> void __attribute__((noipa)) as() { __builtin_abort (); }
> int a1, a2, a3;
> void __attribute__((noipa)) v(int init)
> {
> if (!init) {
> as();
> if (a1)
> goto aq;
> if (x ())
> if (a2)
> as();
> }
> if (!init)
> a3 = 1;
> ar();
> aq:
> if (!init)
> as();
> }
>
> int main()
> {
> v(1);
> return 0;
> }
Hi, thanks for the further reduced testing case.
I am wondering whether you did the above further reducing manually?
[Bug tree-optimization/100053] [9/10 Regression] tree-fre incorrectly delete a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053 --- Comment #11 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) > Created attachment 50579 [details] > fix for the issue > > I am testing this patch - maybe you can test it on the original testcase you > cannot disclose. > I tested this patch with the original test case, and it resolved the runtime error. thanks.
[Bug middle-end/97357] New: Unable to coalesce ssa_names which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
Bug ID: 97357
Summary: Unable to coalesce ssa_names which are marked as MUST
COALESCE.
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
the latest gcc10.2.1 failed with SSA corruption on multiple c modules of our
important application on O3. disabling -fsplit-loops cures the failure.
I was able to reduce the huge routine to the following simple one to reproduce
the failure:
#include
#include
static void * my_malloc (size_t size);
typedef struct glk {
struct glk *nxt;
} glk;
typedef struct Lock
{
glk ByteLock;
} Lock;
static Lock *l, *lk;
void bytelocks(glk *rethead, jmp_buf jb)
{
glk *cur, *cur_lk;
if (( _setjmp (jb)) == 0)
for (cur = &l->ByteLock; cur != ((glk *)0) ; cur = (cur)->nxt)
for (cur_lk = &lk->ByteLock; cur_lk != ((glk *)0); cur_lk =
cur_lk->nxt)
{
glk *retrng;
if(!rethead)
rethead = (glk *) my_malloc (sizeof(glk));
retrng = (glk *) my_malloc (sizeof(glk));
retrng->nxt = rethead;
}
return;
}
/home/qinzhao/Install/latest/bin/gcc -O3 t.c
t.c:4:15: warning: ‘my_malloc’ used but never defined
4 | static void * my_malloc (size_t size);
| ^
Unable to coalesce ssa_names 5 and 6 which are marked as MUST COALESCE.
rethead_5(ab) and rethead_6(ab)
during RTL pass: expand
t.c: In function ‘bytelocks’:
t.c:17:6: internal compiler error: SSA corruption
17 | void bytelocks(glk *rethead, jmp_buf jb)
| ^
0xbcca65 fail_abnormal_edge_coalesce
../../latest_gcc/gcc/tree-ssa-coalesce.c:1003
0xbcca65 coalesce_partitions
../../latest_gcc/gcc/tree-ssa-coalesce.c:1425
0xbcca65 coalesce_ssa_name(_var_map*)
../../latest_gcc/gcc/tree-ssa-coalesce.c:1755
0xb7d597 remove_ssa_form
../../latest_gcc/gcc/tree-outof-ssa.c:1065
0xb7d597 rewrite_out_of_ssa(ssaexpand*)
../../latest_gcc/gcc/tree-outof-ssa.c:1323
0x6fb5d5 execute
../../latest_gcc/gcc/cfgexpand.c:6352
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug middle-end/97357] Unable to coalesce ssa_names which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357 --- Comment #1 from qinzhao at gcc dot gnu.org --- /home/qinzhao/Install/latest/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/qinzhao/Install/latest/bin/gcc COLLECT_LTO_WRAPPER=/home/qinzhao/Install/latest/libexec/gcc/x86_64-pc-linux-gnu/10.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../latest_gcc/configure --prefix=/home/qinzhao/Install/latest -enable-languages=c,c++,fortran,lto Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.1 20201009 (GCC)
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #7 from qinzhao at gcc dot gnu.org --- as we noticed, when using gcc10.2.1 compile our application, 528 C++ modules failed with this bug. looks like a high priority bug to me.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 qinzhao at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/97357] [10 Regression] Unable to coalesce ssa_names which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357 --- Comment #9 from qinzhao at gcc dot gnu.org --- with the patch, all the C modules in our application that failed with this bug passed without any issue.
[Bug testsuite/97680] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #1 from qinzhao at gcc dot gnu.org --- (In reply to seurer from comment #0) > commit d10f3e900b0377b4760a090b0f90371bcef01686 > Author: qing zhao > Date: Fri Oct 30 20:41:38 2020 +0100 > > If looks like the errors are all like this: > > FAIL: c-c++-common/zero-scratch-regs-10.c -std=gnu++98 (test for excess > errors) > Excess errors: > /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/zero-scratch-regs- > 10.c:77:1: sorry, unimplemented: '-fzero-call-used_regs' not supported on > this target Hi, this is an expected error on this platform since the middle-end implementation of -fzero-call-used-regs doesn't work for it. Please mark these testing case as expected failure on this platform, or finish the implementation on powerpc backend
[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #3 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > Err, please dg-skip the tests for ! supported targets. They also fail on > x86_64 with -m32 btw. x86_64 with -m32 failure should be already fixed by Uros already.
[Bug testsuite/97699] [11 regression] zero-scratch-regs tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #2 from qinzhao at gcc dot gnu.org --- this might be expected behavior since the implementation should work for aarch64 and x86. other platforms either need to skip this testing or finish the implementation at backend.
[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #1 from qinzhao at gcc dot gnu.org --- for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit mode, However, command line option force no 80387 mode, the following insn generated to zero st registers is not recognized: (insn 27 67 28 2 (set (reg:XF 8 st) (const_double:XF 0.0 [0x0.0p+0])) "zero-scratch-regs-10.c":8:1 -1 (nil))
[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #5 from qinzhao at gcc dot gnu.org --- (In reply to H.J. Lu from comment #2) > (In reply to qinzhao from comment #1) > > for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit > > mode, However, command line option force no 80387 mode, the following insn > > generated to zero st registers is not recognized: > > > > (insn 27 67 28 2 (set (reg:XF 8 st) > > (const_double:XF 0.0 [0x0.0p+0])) "zero-scratch-regs-10.c":8:1 -1 > > (nil)) > > You should avoid zeroing fixed registers. fixed registers should already be excluded from zeroing. are ST registers considered FIXED registers when -mno-80387 is specified?
[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) > ;; Floating-point register constraints. > (define_register_constraint "f" > "TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FLOAT_REGS : NO_REGS" > "Any 80387 floating-point (stack) register.") > > So, zero_all_st_registers really should just > if (!TARGET_80387 && !TARGET_FLOAT_RETURNS_IN_80387) > return false; > somewhere early. I can do this to avoid the ICE. however, the st/mm register set will NOT be zeroed under such situation when user requests to zero them with -fzero-call-used-regs=all.
[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #22 from qinzhao at gcc dot gnu.org ---
proposed patch:
This change fixes a bug in the i386 backend when adding
-fzero-call-used-regs=all on a target that has no x87
registers.
When there is no x87 registers available, we should not
zero stack registers.
gcc/Changelog:
PR target/97715
* config/i386/i386.c (zero_all_st_registers): Return
earlier when the FPU is disabled.
gcc/testsuite/ChnageLog:
PR target/97715
* gcc.target/i386/zero-scratch-regs-32.c: New test.
---
gcc/config/i386/i386.c | 5 +
gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c | 11 +++
2 files changed, 16 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6fc6228a26e..789ef727cf8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3640,6 +3640,11 @@ zero_all_vector_registers (HARD_REG_SET
need_zeroed_hardregs)
static bool
zero_all_st_registers (HARD_REG_SET need_zeroed_hardregs)
{
+
+ /* If the FPU is disabled, no need to zero all st registers. */
+ if (! (TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387))
+return false;
+
unsigned int num_of_st = 0;
for (unsigned int regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
if ((STACK_REGNO_P (regno) || MMX_REGNO_P (regno))
diff --git a/gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c
b/gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c
new file mode 100644
index 000..ca3261fe5ea
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/zero-scratch-regs-32.c
@@ -0,0 +1,11 @@
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fzero-call-used-regs=all -mno-80387" } */
+
+int
+foo (int x)
+{
+ return (x + 1);
+}
+
+/* { dg-final { scan-assembler-not "fldz" } } */
+
--
[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from qinzhao at gcc dot gnu.org --- fixed in gcc11
[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #2 from qinzhao at gcc dot gnu.org --- when configured the gcc with --enable-checking=df, I can repeat the failure. will check what's wrong with the data flow information.
[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #3 from qinzhao at gcc dot gnu.org ---
This does not look like a bug in the new -fzero-call-used-regs implemenation.
it's more likely an existing bug in data flow analysis.
I made the following change in gcc/function.c to make the new pass to do
nothing except a df_analyze:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff function.c
diff --git a/gcc/function.c b/gcc/function.c
index 004fa389207..658b08ae215 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6658,13 +6658,14 @@ pass_zero_call_used_regs::execute (function *fun)
/* Iterate over the function's return instructions and insert any
register zeroing required by the -fzero-call-used-regs command-line
option or the "zero_call_used_regs" function attribute. */
+#if 0
FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
{
rtx_insn *insn = BB_END (e->src);
if (JUMP_P (insn) && ANY_RETURN_P (JUMP_LABEL (insn)))
gen_call_used_regs_seq (insn, zero_regs_type);
}
-
+#endif
return 0;
}
with this gcc, the exactly same ICE still there.
[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #4 from qinzhao at gcc dot gnu.org --- this should be a bug in the pass "stack". if I modify the file "reg-stack.c" as following: qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c index 8f98bd85750..3d6519c95c9 100644 --- a/gcc/reg-stack.c +++ b/gcc/reg-stack.c @@ -3428,6 +3428,7 @@ rest_of_handle_stack_regs (void) #ifdef STACK_REGS reg_to_stack (); regstack_completed = 1; + df_analyze (); #endif return 0; } the testing case will core dump at: t.c: In function ‘foo’: t.c:5:1: internal compiler error: in df_refs_verify, at df-scan.c:3991 5 | } | ^ 0xc3e634 df_refs_verify ../../write_gcc/gcc/df-scan.c:3991 0xc3e8a5 df_insn_refs_verify ../../write_gcc/gcc/df-scan.c:4075 0xc3ea83 df_bb_verify ../../write_gcc/gcc/df-scan.c:4107 0xc3f046 df_scan_verify() ../../write_gcc/gcc/df-scan.c:4228 0xc2576c df_verify() ../../write_gcc/gcc/df-core.c:1818 0xc23fdd df_analyze_1 ../../write_gcc/gcc/df-core.c:1214 0xc2439e df_analyze() ../../write_gcc/gcc/df-core.c:1290 0x115d581 rest_of_handle_stack_regs ../../write_gcc/gcc/reg-stack.c:3431 0x115d5d2 execute ../../write_gcc/gcc/reg-stack.c:3461 looks like that the pass reg stack does not maintain the df information correctly during its transformation.
[Bug rtl-optimization/97777] ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #5 from qinzhao at gcc dot gnu.org ---
the following patch in reg-stack.c fixed the failure:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c
index 8f98bd85750..3dab843f803 100644
--- a/gcc/reg-stack.c
+++ b/gcc/reg-stack.c
@@ -3426,7 +3426,8 @@ static unsigned int
rest_of_handle_stack_regs (void)
{
#ifdef STACK_REGS
- reg_to_stack ();
+ if (reg_to_stack ())
+df_insn_rescan_all ();
regstack_completed = 1;
#endif
return 0;
