[Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021 --- Comment #10 from ishikawa,chiaki --- It would be great if the problem is fixed in later versions. I observe the error with gcc-12 on my computer yet. *BUT* compiling with -O instead of -O2 succeeds !? gcc-12 version. gcc-12 (Debian 12.2.0-14) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. No error with -O !? ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 -c -O -Wall /tmp/pr94021.c Error with -O2 as before. ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 -c -O2 -Wall /tmp/pr94021.c /tmp/pr94021.c: In function ‘format_utc_offset’: /tmp/pr94021.c:14:45: warning: ‘%02i’ directive output may be truncated writing 2 bytes into a region of size between 1 and 5 [-Wformat-truncation=] 14 | __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m); | ^~~~ /tmp/pr94021.c:14:38: note: directive argument in the range [0, 59] 14 | __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m); | ^~~~ /tmp/pr94021.c:14:5: note: ‘__builtin_snprintf’ output between 6 and 10 bytes into a destination of size 8 14 | __builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m); | ^ ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$
[Bug c++/109480] New: g++-12 and g++-11 failed to compile the attached source file while g++-10 and clang can.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109480
Bug ID: 109480
Summary: g++-12 and g++-11 failed to compile the attached
source file while g++-10 and clang can.
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ishikawa at yk dot rim.or.jp
Target Milestone: ---
Created attachment 54837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54837=edit
target.cpp: this shows the compiler issue for g++-10 and g++-11
I am reporting a reduced case of a compilation issue noticed when we compile
mozilla firefox browser, and thunderbird mail client software.
For the original problem report and the workaround (basically rewriting the
source code), see the bugzilla entry at mozilla's bugzilla,
https://bugzilla.mozilla.org/show_bug.cgi?id=1825516
Now, I am a newbie to c-vise source coded reduction tool, but managed to create
the attached reduced source file.
That file shows the symptom.
I am using the following compiler for testing.
Version Info:
g++-10 --version
g++-10 (Debian 10.4.0-7) 10.4.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-11 --version
g++-11 (Debian 11.3.0-12) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-12 --version
g++-12 (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ clang --version
clang version 15.0.5 (taskcluster-ETTsfeYjQ76jbYk0xzOrPA)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/ishikawa/.mozbuild/clang/bin
The clang compiler I use is a version compiled by mozilla to facilitate that
the developer community uses the same clang everywhere.
g++-10 can compile it.
g++-11 can not.
g++-12 can not.
clang can.
See the console log below.
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-10 -c target.cpp
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-11 -c target.cpp
target.cpp: In member function ‘void
mozilla::a11y::RemoteAccessibleBase::BoundsWithOffset() const’:
target.cpp:14:57: error: ‘bool
mozilla::a11y::RemoteAccessibleBase::ApplyScrollOffset(nsRect&) const
[with Derived = mozilla::a11y::RemoteAccessible]’ is protected within this
context
14 | const bool hasScrollArea = remoteAcc.ApplyScrollOffset(bounds);
| ~~~^~~~
target.cpp:6:14: note: declared protected here
6 | bool ApplyScrollOffset(nsRect & a) const { return a.x > 0 ?
true: false; } ;
| ^
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-12 -c target.cpp
target.cpp: In member function ‘void
mozilla::a11y::RemoteAccessibleBase::BoundsWithOffset() const’:
target.cpp:14:57: error: ‘bool
mozilla::a11y::RemoteAccessibleBase::ApplyScrollOffset(nsRect&) const
[with Derived = mozilla::a11y::RemoteAccessible]’ is protected within this
context
14 | const bool hasScrollArea = remoteAcc.ApplyScrollOffset(bounds);
| ~~~^~~~
target.cpp:6:14: note: declared protected here
6 | bool ApplyScrollOffset(nsRect & a) const { return a.x > 0 ?
true: false; } ;
| ^
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ clang -c target.cpp
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$
Thank you for sharing the great compiler suite with the developer community.
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 --- Comment #9 from ishikawa,chiaki --- Thank you for the confirmation for the fix in GCC-12. Now I have to figure out how GCC-12 seems to miscompile something in Thunderbird mail client to report a run-time assertion error. (Compiling Thunderbird mail client with earlier version did not show the runtime assertion error. So I wanted to weed out possible source problem from mozilla source code and thunderbird mail client code by using -Werror with due caution.) Thank you again for the confirmation of the fix in GCC-12.
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 --- Comment #7 from ishikawa,chiaki --- If I change gcc-11 into gcc-12 in the attached script, I get the different warning. My version of gcc-12 is: ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 --version gcc-12 (Debian 12.2.0-14) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 --- Comment #6 from ishikawa,chiaki --- Created attachment 54610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54610=edit The script to produce the warning in the original report with gcc-11. The source file needs to be in /tmp/sqlite3-preprocessed-2.c Run this script with bash this-script and it will print something like this on my linux PC. Here I put the script into t83.sh: bash ~/Dropbox/TB-DIR/WALL-PATCH-DIR/t83.sh /tmp/sqlite3-preprocessed-2.c: In function ‘posixUnlock’: /tmp/sqlite3-preprocessed-2.c:22632:42: error: self-comparison always evaluates to true [-Werror=tautological-compare] 22632 | sqlite3PendingByte+1==(sqlite3PendingByte+1) | ^~ In function ‘memset’, inlined from ‘pager_playback’ at /tmp/sqlite3-preprocessed-2.c:32113:4: /tmp/sqlite3-preprocessed-2.c:4273:10: error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 4273 | return __builtin___memset_chk (__dest, __ch, __len, __builtin_object_size (__dest, 0)); | ^~~ /tmp/sqlite3-preprocessed-2.c: In function ‘pager_playback’: /tmp/sqlite3-preprocessed-2.c:32089:30: note: destination object ‘*pPager.pTmpSpace’ of size [0, 9223372036854775807] 32089 | zSuper = (void *) >pTmpSpace[4]; |~~^~~ /tmp/sqlite3-preprocessed-2.c:32089:30: note: destination object ‘*pPager.pTmpSpace’ of size [0, 9223372036854775807] cc1: all warnings being treated as errors ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 --- Comment #4 from ishikawa,chiaki --- Right, when I replaced gcc-11 with gcc-12 in my script, I got the following warnings. One of them was there before, the other is new. /tmp/sqlite3-preprocessed-2.c: In function ‘posixUnlock’: /tmp/sqlite3-preprocessed-2.c:22632:42: error: self-comparison always evaluates to true [-Werror=tautological-compare] 22632 | sqlite3PendingByte+1==(sqlite3PendingByte+1) | ^~ /tmp/sqlite3-preprocessed-2.c: In function ‘vtabCallConstructor’: /tmp/sqlite3-preprocessed-2.c:121095:4: error: the comparison will always evaluate as ‘true’ for the address of ‘pVtabCtx’ will never be NULL [-Werror=address] 121095 | ) ? (void) (0) : __assert_fail ( |^ /tmp/sqlite3-preprocessed-2.c:5226:12: note: ‘pVtabCtx’ declared here 5226 | VtabCtx *pVtabCtx; |^~~~ cc1: all warnings being treated as errors The latter one is a new one. Not sure why it was not triggered with gcc-11. Anyway, actually, I have found out that there is a runtime assertion triggered by thunderbird mail client when it is compiled with gcc-12, and not with gcc-10|gcc-11. So, I wanted to check the source code as much as possible with -Werror before I dive into runtime code generation issues. "-Werror" signals so many dubious constructs, and it has been an uphill battle to make the code compile. I found a missing "break" statement (implicit fallthrough), and strange size check (3rd argument to strncpy) already, but I am close to being able to compile mozilla source tree with more compile time check right now. Thank you again for making advanced compiler available free of charge.
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 ishikawa,chiaki changed: What|Removed |Added CC||ishikawa at yk dot rim.or.jp --- Comment #2 from ishikawa,chiaki --- Created attachment 54600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54600=edit Compressed preprocessed file (less file linenumber directives) Sorry, I did not realize my attempt to attach the preprocess file failed when I filed the bug report. I am compressing the preprocessed file this time. (Right, uncompressed it was more than 4MB, and now compressed it is like 740KB.) Hope this helps.
[Bug c/109041] New: Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 Bug ID: 109041 Summary: Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ishikawa at yk dot rim.or.jp Target Milestone: --- I am compiling sqlite3.c included in mozilla firefox source tree with gcc -Werror and -Wall flag (with some exclusion of certain warnings). Then the compiler spewed out the following warning treated as error, which, I think, is bogus, but not so sure. Since the code works without the compile time check, I suppose it works :-) Gcc version is 11.3. I am compiling under Debian GNU/Linux. ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-11 --version gcc-11 (Debian 11.3.0-12) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You see, a region of size 0 looks obviously bogus. When I look at the original code that references a character pointer with negative index (-4), I am tempted to think that a bug is triggered by the negative index. The line 32113 is memset([-4], 0, 4); The error printed: In function ‘memset’, inlined from ‘pager_playback’ at /tmp/sqlite3-preprocessed-2.c:32113:5: /tmp/sqlite3-preprocessed-2.c:4273:10: error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 4273 | return __builtin___memset_chk (__dest, __ch, __len, __builtin_object_size (__dest, 0)); | ^~~ /tmp/sqlite3-preprocessed-2.c: In function ‘pager_playback’: /tmp/sqlite3-preprocessed-2.c:32089:21: note: destination object ‘*pPager.pTmpSpace’ of size [0, 9223372036854775807] 32089 | zSuper = >pTmpSpace[4]; | ~~^~~ /tmp/sqlite3-preprocessed-2.c:32089:21: note: destination object ‘*pPager.pTmpSpace’ of size [0, 9223372036854775807] cc1: all warnings being treated as errors I am attaching the preprocessed file which needs to be stored into /tmp/sqlite3-preprocessed-2.c, and the following script was used to compile it. (I have removed the file line number directive because it was so confusing to figure out where the error occurs. But if someone needs to track down which header files to blame, etc., I can upload the original preprocessed file.) /usr/bin/gcc-11 -o /tmp/sqlite3-preprocessed-2.o -c -fstack-protector-strong -ldl -fno-builtin-strlen -g -Werror=sign-compare -Werror=unused-result -Werror=unused-variable -Werror=format -fuse-ld=gold -ldl -fno-builtin-strlen -g -Werror -Wmaybe-uninitialized -Wsign-compare -Wunused-result -Wunused-variable -Wformat -Wno-unknown-pragmas -Wno-switch -Wno-address-of-packed-member -fuse-ld=gold -fPIC -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -g -g -Og -fvar-tracking -gdwarf-4 -fvar-tracking-assignments -freorder-blocks -fno-omit-frame-pointer -funwind-tables -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wformat -Wformat-overflow=2 -Werror=implicit-function-declaration -Wno-psabi -Wno-sign-compare -Wno-type-limits -fno-strict-aliasing -ffp-contract=off -fdiagnostics-color /tmp/sqlite3-preprocessed-2.c Actually there is another error printed, but that is an internal integrity check which holds, and that must be taken care of by the developer somehow. I.e., this must be ignored. /tmp/sqlite3-preprocessed-2.c: In function ‘posixUnlock’: /tmp/sqlite3-preprocessed-2.c:22632:42: error: self-comparison always evaluates to true [-Werror=tautological-compare] 22632 | sqlite3PendingByte+1==(sqlite3PendingByte+1) | ^~ Thank you in advance for your attention.
[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 --- Comment #18 from ishikawa,chiaki --- I reported the issue to the following github for a very fast hashing function library. https://github.com/Cyan4973/xxHash/issues/800 >From the discussion there, I figured -Og does not define __NO_INLINE__ as -O0 would define it. Well the discussion refers to the problem mentioned earlier about the same issue. In there, the following mentions something about __NO_INLINE__. https://github.com/Cyan4973/xxHash/pull/720#issuecomment-1414481935 So I settled on manually define __NO_INLINE__ on the compiler command line. This makes it the compilation succeed. (The code seems to be written in such a manner that always_inline is not declared for the two functions if __NO_INLINE__ is defiend.) It would be great if -Og can define macro __NO_INLINE__ as -O0 does. Oh wait, -fno-inline has the same effect(?).
[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 --- Comment #14 from ishikawa,chiaki --- (In reply to Andrew Pinski from comment #13) > (In reply to ishikawa,chiaki from comment #11) > > What is exactly the compiler-defined macro when "-Og" is used on the command > > line? > > There is not one ... Thank you for the information. I see we may have to create a protocol by creating a commonly used macro to handle the situation. The bugzilla I created at mozilla is https://bugzilla.mozilla.org/show_bug.cgi?id=1817565 And the code seems to be a third party code and I was advised to report the issue to the originating github also. I will. Thank you again. PS: Given the manual description, it could be gcc-10 and gcc-11 may not have inlined the functions, but the errors were not reported as such. Oh well.
[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 --- Comment #11 from ishikawa,chiaki --- Created attachment 54484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54484=edit Script to compile the previous source file. The previous source file ought to be named 't-failure-always-inline-simplified.c'. This script compiles it. With -Og the compilation fails since always_inline functions do not get inlined. Without -Og, the compilation succeeds. Of course, we can conditionalize the use of always_inline to avoid the issue. What is exactly the compiler-defined macro when "-Og" is used on the command line?
[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 ishikawa,chiaki changed: What|Removed |Added CC||ishikawa at yk dot rim.or.jp --- Comment #10 from ishikawa,chiaki --- Created attachment 54483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54483=edit The source file that exhibits the failure to inline always_inline functions. I have a similar problem compiling Thunderbird mail client with GCC-12. A couple of always_inline functions cannot be inlined and errors are diagnosed. I am a bit perplexed that gcc-10 and gcc-11 did not seem to have the problem. Also, I am wondering if I am seeing the same issue discussed here or not because I think the functions are declared in the proper topological order (that is, the function that is called is declared in a manner that the callee is defined before the caller.) Yes, there is an indirect function call, that may be the reason of the failure. I am attaching a preprocessed source file and the script to compile it to cause the failure. The presence of -Og is essential. If we remove -Og, the compilation succeeds.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #5 from ishikawa,chiaki --- (In reply to Martin Sebor from comment #3) > The warning works as designed but the range information it depends on is > less than perfect. As discussed in pr94021 that's a known limitation of the > current range propagation infrastructure. GCC 11 adds an improved range > engine known as the Ranger that's expected to remedy this but it is yet to > be integrated with the sprintf/strlen pass. The argument ranges can be > constrained by using a "narrower" directive such as %hhu. > Thank you for the detailed explanation. It would be great to see this Ranger incorporated into the sprintf/strlen pass. I say this because I found a bug in a popular code which this feature could have found. (The bug was found by the dynamic check done by ASAN-build.) Thank you for continuously developing GCC with these new features. Happy festive season to all.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #4 from ishikawa,chiaki --- (In reply to Martin Sebor from comment #3) > The warning works as designed but the range information it depends on is > less than perfect. As discussed in pr94021 that's a known limitation of the > current range propagation infrastructure. GCC 11 adds an improved range > engine known as the Ranger that's expected to remedy this but it is yet to > be integrated with the sprintf/strlen pass. The argument ranges can be > constrained by using a "narrower" directive such as %hhu. > Thank you for the detailed explanation. It would be great to see this Ranger incorporated into the sprintf/strlen pass. I say this because I found a bug in a popular code which this feature could have found. (The bug was found by the dynamic check done by ASAN-build.) Thank you for continuously developing GCC with these new features. Happy festive season to all.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #2 from ishikawa,chiaki --- Created attachment 49764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49764=edit The patch that I had for 94021 Funny I thought this was gone for a while with gcc-9 and an earlier 10 (?) I say this because I had a patch as attached locally (which I produced since I reported bug 94021). But I could compile the source without the patch this Fall., it seems. Yeah, I took it out from my local patch queeu. Maybe something changed. Also, please notice that the first part of the patch is for the case quite similar to bug 94021 comment 4 test example, and I think that was somehow taken care of (?) Anyway, the bug(s) still persist for the static snprintf format check.
[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281 --- Comment #1 from ishikawa,chiaki --- The command to compile the source file uploaded. (Place it in /tmp) cd tmp export TERM=dumb /usr/bin/gcc-10 -std=gnu99 -o /tmp/Unified_c_libical_src_libical1.o -c -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers -include /NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DDEBUG=1 -DHAVE_CONFIG_H -DHAVE_SNPRINTF -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical -I/NEW-SSD/moz-obj-dir/objdir-tb3/comm/calendar/libical/src/libical -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nspr -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nss -fPIC -include /NEW-SSD/moz-obj-dir/objdir-tb3/mozilla-config.h -DMOZILLA_CLIENT -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -DUSEVALGRIND=1 -DDEBUG -g -gsplit-dwarf -Werror=sign-compare -Werror=unused-result -Werror=unused-variable -Werror=format -fuse-ld=gold -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -g -g -Og -fvar-tracking -gdwarf-4 -fvar-tracking-assignments -freorder-blocks -fno-omit-frame-pointer -funwind-tables -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -Werror=implicit-function-declaration -Wno-psabi -MD -MP -MF .deps/Unified_c_libical_src_libical1.o.ppUnified_c_libical_src_libical1.c We get the following error at the end, but please ignore it. Unified_c_libical_src_libical1.c: At top level: Unified_c_libical_src_libical1.c:48: fatal error: opening dependency file .deps/Unified_c_libical_src_libical1.o.pp: No such file or directory 48 | #pragma GCC visibility pop
[Bug tree-optimization/98281] New: - -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98281
Bug ID: 98281
Summary: - -Wformat-truncation false positive due to excessive
integer range
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishikawa at yk dot rim.or.jp
Target Milestone: ---
Created attachment 49763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49763=edit
Code that triggered the error.
Actually there was bug 94021 but that was for 9.2.1, and this is with 10.2.0,
and the error is subtly different. So I am submitting this bug entry.
Compared with the example in bug 94021 comment 4, the bug is slightly
different.
gcc --version
gcc (Debian 10.2.0-19) 10.2.0
The source code is from mozilla's thunderbird.
The error I observed is:
In file included from Unified_c_libical_src_libical1.c:20:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:
In function ‘icalvalue_utcoffset_as_ical_string_r’:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:897:20:
error: ‘%02d’ directive output may be truncated writing between 2 and 6 bytes
into a region of size between 2 and 4 [-Werror=format-truncation=]
897 | snprintf(str,9,"%c%02d%02d%02d",sign,abs(h),abs(m),abs(s));
|^~~~
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:897:20:
note: directive argument in the range [1, 338339]
In file included from /usr/include/stdio.h:867,
from
/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers/stdio.h:3,
from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:34,
from Unified_c_libical_src_libical1.c:2:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note:
‘__builtin___snprintf_chk’ output between 8 and 14 bytes into a destination of
size 9
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
68 |__bos (__s), __fmt, __va_arg_pack ());
|~~
This does not make sense, since the value(s) ought to be constrained
to fit into the final string.
Also, I am not sure what this [1, 338339] is valid for WHICH variable.
The code snippet from the affected function: Sorry, I could no reproduce the
problem with a simplified source code. There must be an optimization issue
involved.
--- begin quote
static char* icalvalue_utcoffset_as_ical_string_r(const icalvalue* value)
{
int data,h,m,s;
char sign;
char* str;
if(!((value!=0))) { icalerror_set_errno(ICAL_BADARG_ERROR); return 0;};
str = (char*)icalmemory_new_buffer(9);
data = icalvalue_get_utcoffset(value);
if (abs(data) == data){
sign = '+';
} else {
sign = '-';
}
if (data >= 3600 * 24 || data <= - 3600 * 24) {
snprintf(str,9,"+");
return str;
}
if(data < 0)
data = - data;
h = data/3600;
m = (data - (h*3600))/ 60;
s = (data - (h*3600) - (m*60));
if (s > 0)
snprintf(str,9,"%c%02d%02d%02d",sign,abs(h),abs(m),abs(s));
else
snprintf(str,9,"%c%02d%02d",sign,abs(h),abs(m));
return str;
}
--- end quote
The intention is that the following conditions hold before snprintf is invoked.
h is in [0, 24)
m is in [0, 60)
s is in [0, 60)
I wonder where "[1, 338339]" comes from.
Yes, I know the original code does something funny like abs(data) == data,
The preprocessed source file is in the attachment.
The command script to compile the source file is in another comment.
[Bug ipa/98000] [10/11 Regression] ICE verify_cgraph_node failed since r10-7306-g72b3bc895f023bf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000 --- Comment #5 from ishikawa,chiaki --- (In reply to Martin Liška from comment #3) > Thank you for the report, it's very likely a different issue. > I'm reducing that right now.. You are very welcome and thank you for the reduction to simpler case in comment 4. I used to work on compilers, interpreters, assemblers, etc. many moons ago, but the current complexity of g++-10, and for that matter C++ and complex software like mozilla thunderbird, is beyond a mere user like myself, especially trying to reduce the memory usage by means of "clone on demand" sounds a very hairy approach (hairy as in the old Hacker's dictionary meaning). I AM impressed. Thank you again. (I would have used "Happy Hacking" in the old days, but nowadays, hacking only seems to be taken to carry a very negative sense. Sad.)
[Bug ipa/98000] g++-10 internal compiler error: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000 --- Comment #2 from ishikawa,chiaki --- I forgot. The g++-10 version is as follows. ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc --version gcc (Debian 10.2.0-16) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug ipa/98000] g++-10 internal compiler error: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000 --- Comment #1 from ishikawa,chiaki --- I noticed a similar Bug 97551. But I seem to be using different options and I think I may be using a different construct that triggers the ICE, and thus filed this entry. I believe more reproducible cases would help.
[Bug ipa/98000] New: g++-10 internal compiler error: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000 Bug ID: 98000 Summary: g++-10 internal compiler error: verify_cgraph_node failed Product: gcc Version: og10 (devel/omp/gcc-10) Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ishikawa at yk dot rim.or.jp CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 49631 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49631=edit Gzipped preprocessed source file that led to the internal compiler error. While compillng mozilla thunderbird mail client for local build, I get the following error. hh:1466:16: internal compiler error: verify_cgraph_node failed 0xdb670e cgraph_node::verify_node() ../../src/gcc/cgraph.c:3812 0xda9914 symtab_node::verify() ../../src/gcc/symtab.c:1312 0x12caa34 optimize_inline_calls(tree_node*) ../../src/gcc/tree-inline.c:5432 0x100c9a3 inline_transform(cgraph_node*) ../../src/gcc/ipa-inline-transform.c:736 0x115652d execute_one_ipa_transform_pass ../../src/gcc/passes.c:2233 0x115652d execute_all_ipa_transforms(bool) ../../src/gcc/passes.c:2272 0xdbc0d3 cgraph_node::expand() ../../src/gcc/cgraphunit.c:2293 0xdbd67f expand_all_functions ../../src/gcc/cgraphunit.c:2471 0xdbd67f symbol_table::compile() ../../src/gcc/cgraphunit.c:2834 0xdbfa6c symbol_table::compile() ../../src/gcc/cgraphunit.c:2747 0xdbfa6c symbol_table::finalize_compilation_unit() ../../src/gcc/cgraphunit.c:3014 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. I am attaching the preprocessed source file. The command that led to this bug is as follows (assuming the preprocessed file is placed in /tmp ) /usr/bin/g++-10 -std=gnu++17 -o Unified_cpp_gfx_harfbuzz_src0.o -c -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/stl_wrappers -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers -include /NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -UDEBUG '-DPACKAGE_VERSION="moz"' '-DPACKAGE_BUGREPORT="http://bugzilla.mozilla.org/;' -DHAVE_OT=1 -DHAVE_ROUND=1 -DHB_NO_FALLBACK_SHAPE -DHB_NO_MT -DHB_NO_UCD -DHB_NO_UNICODE_FUNCS -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/gfx/harfbuzz/src -I/NEW-SSD/moz-obj-dir/objdir-tb3/gfx/harfbuzz/src -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nspr -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /NEW-SSD/moz-obj-dir/objdir-tb3/mozilla-config.h -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -Wno-psabi -fno-sized-deallocation -fno-aligned-new -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -DUSEVALGRIND=1 -DDEBUG -g -gsplit-dwarf -Werror=sign-compare -Werror=unused-result -Werror=unused-variable -Werror=format -fuse-ld=gold -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -g -Og -fvar-tracking -gdwarf-4 -fvar-tracking-assignments -freorder-blocks -fno-omit-frame-pointer -funwind-tables -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -MD -MP -MF .deps/Unified_cpp_gfx_harfbuzz_src0.o.pp -fdiagnostics-color Unified_cpp_gfx_harfbuzz_src0.cpp
[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781 --- Comment #10 from ishikawa,chiaki --- (In reply to Martin Liška from comment #9) > Thanks. > I've made a more permanent link here: > https://drive.google.com/file/d/1s9i_l68CR8UGhqPfq0pdgQTH26G7YEFW/ > view?usp=sharing > > I get these numbers for g++ UnifiedBindings23-v7.cpp -c -std=c++17 -O2 > -fno-checking -fmax-errors=1 -Wno-invalid-offsetof: > > 7.4.0 (adafdb1e7212d53a)(06 Dec 2018 10:00): [took: 68.766s] result: OK > 7.5.0 (b2d961e7342b5ba4)(14 Nov 2019 07:40): [took: 68.694s] result: OK > 8.1.0 (406c2abec3f998e9)(02 May 2018 10:13): [took: 73.308s] result: OK > 8.2.0 (ddeb81e76461fc00)(26 Jul 2018 09:47): [took: 72.738s] result: OK > 8.3.0 (4c44b708f11eec6f)(22 Feb 2019 14:20): [took: 72.058s] result: OK > 8.4.0 (8cd3bffead2ed1d1)(04 Mar 2020 08:30): [took: 71.730s] result: OK > 9.1.0 (c8913260b0756f97)(03 May 2019 07:59): [took: 77.404s] result: OK > 9.2.0 (a0c06cc27d2146b7)(12 Aug 2019 09:38): [took: 76.432s] result: OK > 9.3.0 (4212a6a3e44f8704)(12 Mar 2020 11:08): [took: 76.636s] result: OK > > current master: > 438085cc66ed5801(05 May 2020 12:24)(Michael Meissner > meiss...@linux.ibm.com): [took: 78.698s] result: OK > > Which is a regression of ~12% and one can't point to a single point where it > jumped rapidly. Note that we do more inlining and more optimizations in > general. I will try to see if assigning more CPU cores to VirtualBox image I am using locally can improve the situation. I am not sure how CPU cache is handled in such a setting, but there may be some improvement. Thank you again for your attention on this matter. I have been using GCC for quite a long time on workstations and embedded systems. Thank you for making the great package available to the wide developer community. Chiaki
[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781 --- Comment #8 from ishikawa,chiaki --- (In reply to ishikawa,chiaki from comment #7) > (In reply to Martin Liška from comment #6) > > (In reply to ishikawa,chiaki from comment #3) > > > https://send.firefox.com/download/bdf77223953903fa/#WMrJbMYdsL7AXf2vXYm82g > > > > > > I uploaded the file, UnifiedBindings23-v7.cpp, to the link above. > > > > > > > Sorry, the link has expired. Can you please re-upload it? > > Thank you for your attention on this matter. > > I have re-upload it now. > > https://send.firefox.com/download/496fe37075c2429f/#izMu3peg8oBwFQhg1RXuLQ > > > If we can make "phase last asm" elapsed time as short as v7, the total build > time of thunderbird mailer would be shorter, I suppose. > > TIA Sorry I did not set the expiration condition properly.: https://send.firefox.com/download/c1e1bef0d9c360a6/#TWmiEAGr3zFfRIEDAcOsIQ The above link should work for one week or 20 downloads, which ever comes first. TIA
[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781 --- Comment #7 from ishikawa,chiaki --- (In reply to Martin Liška from comment #6) > (In reply to ishikawa,chiaki from comment #3) > > https://send.firefox.com/download/bdf77223953903fa/#WMrJbMYdsL7AXf2vXYm82g > > > > I uploaded the file, UnifiedBindings23-v7.cpp, to the link above. > > > > Sorry, the link has expired. Can you please re-upload it? Thank you for your attention on this matter. I have re-upload it now. https://send.firefox.com/download/496fe37075c2429f/#izMu3peg8oBwFQhg1RXuLQ If we can make "phase last asm" elapsed time as short as v7, the total build time of thunderbird mailer would be shorter, I suppose. TIA
[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781 --- Comment #5 from ishikawa,chiaki --- Thank you for your comment. (In reply to Richard Biener from comment #4) > The time-report you attached is mostly flat and I don't see anything > eye-popping pointing at a regression. With -O0 my GCC9 is faster (well, > noise). I was concerned with the ELAPSED time, and I notice that, in my testing, "phase last asm" of v9 and v8 spent a tad long time than v7. v9 phase last asm : 6.03 ( 5%) 0.24 ( 2%) 19.07 ( 12%) 127204 kB ( 2%) v8 phase last asm : 5.62 ( 4%) 0.24 ( 2%) 15.43 ( 10%) 103215 kB ( 2%) v7 phase last asm : 4.03 ( 3%) usr 0.16 ( 1%) sys 6.51 ( 5%) wall 101000 kB ( 2%) ggc v9 spends more than 12 seconds and v8 spends about 9 seconds longer than v7. But I am not sure what this "phase last asm" does and why it spends more ELAPSED time in v9 and v8 than in v7. > Confirmed for -O2: > > > /usr/bin/time /space/rguenther/install/gcc-7.5/bin/g++ -S > > UnifiedBindings23-v7.cpp -std=gnu++1z -w -O2 > 112.50user 1.83system 2:01.65elapsed 93%CPU (0avgtext+0avgdata > 2732664maxresident)k > 1952inputs+36528outputs (6major+678054minor)pagefaults 0swaps > > /usr/bin/time /space/rguenther/install/gcc-8.4/bin/g++ -S > > UnifiedBindings23-v7.cpp -std=gnu++1z -w -O2 > 83.44user 1.27system 1:26.34elapsed 98%CPU (0avgtext+0avgdata > 2789396maxresident)k > 48640inputs+41088outputs (62major+687702minor)pagefaults 0swaps > > /usr/bin/time /space/rguenther/install/gcc-9.3/bin/g++ -S > > UnifiedBindings23-v7.cpp -std=gnu++1z -w -O2 > 128.28user 1.90system 2:19.51elapsed 93%CPU (0avgtext+0avgdata > 2695708maxresident)k > > Note how my GCC 8 build is significantly faster than GCC 7! Hmm... Did you use special flag to create your compiler? I am using AMD Ryzen 7 1700 eight core CPU (my linux runs inside VirtualBox image under Windows 10 and it is assigned 7 virtual CPU core.). Maybe I need to build my own G++ compiler tuned for AMD Ryzen 7 if you used a special compiler flags when you built your V8 and V9 compiler because the elapsed time difference between v7 and v9 is rather smallish in comparison to the difference I observed on my PC (module the option difference.) > > note that this kind of regression can easily happen because we generate > more code because of some different optimization decisions. For example > the GCC 8 generated object is > > > size UnifiedBindings23-v7.o >textdata bss dec hex filename > 2502864 10136 37392 2550392 26ea78 UnifiedBindings23-v7.o > > while GCC 9 generates > > > size UnifiedBindings23-v7.o >textdata bss dec hex filename > 2788944 16488 37392 2842824 2b60c8 UnifiedBindings23-v7.o > > I realize I didn't use the full set of options you did (in particular I > omitted > -g). The few extra options I needed to omit for v7 and v8 might explain the slow down. I will check for this by removing the options from v9 compilation as well. > My tests also seem noisy (machine isn't idle, 2nd run of the GCC 9 > compile > dialed in at 100s) I bet you are using very fast CPU :-)
[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781 --- Comment #3 from ishikawa,chiaki --- https://send.firefox.com/download/bdf77223953903fa/#WMrJbMYdsL7AXf2vXYm82g I uploaded the file, UnifiedBindings23-v7.cpp, to the link above. It is huge as I explained. Approximately 28MB. The compiler options I used for each version of the g++ compiler is in the attachment: https://gcc.gnu.org/bugzilla/attachment.cgi?id=48380 -ftime-print log for V9, V8 and V7 g++ compiler compiling preprocessed UnifiedBindings23.cpp Since the file was already preprocessed, -I options won't have any meaning, but I simply copied from the original build command. Thank you again for your attention on this matter.
[Bug c++/94781] version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781 --- Comment #1 from ishikawa,chiaki --- BTW, UnifiedBindings23.cpp is huge. It is about 28MB and more than 3MB compressed (by gzip). I can send the compressed file by e-mail to anyone interested in this issue. As the name suggests, the source file is a clever concatenation of source files to avoid the duplicated processing of include files in each source file by lumping them together and run the compiler once. I don't know if there is a time consumer that takes non-linear time of its input source file size in g++, but there may be... OTOH, the "phase last asm" elapsed time may explain the most of the elapsed time slow down, and so it should be the first target of investigation.
[Bug c++/94781] New: version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781 Bug ID: 94781 Summary: version 9.3 g++ compilation time is slower by 20% or much more (closer to 50 % sometimes) in comparison to v7. Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ishikawa at yk dot rim.or.jp Target Milestone: --- Created attachment 48380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48380=edit -ftime-print log for V9, V8 and V7 g++ compiler compiling preprocessed UnifiedBindings23.cpp Thank you for maintaining the great package. I use GCC for PC and embedded systems development. I compile mozilla Thunderbird mail client source files using GCC to create patches to fix the bugs of the mail client. Lately, when I switched from GCC V7 to GCC v9, I noticed a great slowdown of compilation time. I was hampered with other bugs which I sorted out and then the slow compilation time became very apparent. I created a small awk script to check the compilation time of thunderbird source files. The following is what I found. top 20 in terms of elapsed time for g++-7 compilation time. 165.097862 : UnifiedBindings23.cpp 102.842003 : UnifiedBindings1.cpp 102.387905 : Unified_cpp_dom_base2.cpp 79.692992 : Unified_cpp_layout_generic2.cpp 78.299717 : UnifiedBindings4.cpp 78.239538 : Unified_cpp_dom_ipc0.cpp 77.236254 : Unified_cpp_src_peerconnection0.cpp 75.737330 : UnifiedBindings12.cpp 72.586055 : Unified_cpp_dom_canvas0.cpp 72.564836 : UnifiedBindings10.cpp 72.556511 : UnifiedProtocols12.cpp 71.924969 : Unified_cpp_layout_painting0.cpp 70.908968 : /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/indexedDB/ActorsParent.cpp 70.167488 : UnifiedBindings3.cpp 69.194670 : UnifiedBindings22.cpp 68.657080 : UnifiedBindings21.cpp 68.106164 : Unified_cpp_docshell_base0.cpp 67.494041 : Unified_cpp_layout_base1.cpp 65.638745 : Unified_cpp_dom_canvas4.cpp top 20 in terms of elapsed time for g++-9 compilation time. Elapsed time 259.956334 : UnifiedBindings23.cpp Elapsed time 149.609287 : UnifiedBindings1.cpp Elapsed time 132.656618 : Unified_cpp_layout_generic2.cpp Elapsed time 125.823251 : Unified_cpp_dom_base2.cpp Elapsed time 113.072732 : UnifiedBindings4.cpp Elapsed time 107.252363 : Unified_cpp_layout_painting0.cpp Elapsed time 100.176409 : /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/indexedDB/ActorsParent.cpp Elapsed time 99.760067 : UnifiedProtocols12.cpp Elapsed time 99.549702 : Unified_cpp_dom_canvas0.cpp Elapsed time 99.372578 : Unified_cpp_dom_ipc0.cpp Elapsed time 97.947955 : Unified_cpp_image_test_gtest0.cpp Elapsed time 97.134518 : UnifiedBindings21.cpp Elapsed time 95.530481 : UnifiedBindings3.cpp Elapsed time 94.182883 : UnifiedBindings12.cpp Elapsed time 92.836375 : Unified_cpp_src_peerconnection0.cpp Elapsed time 92.755637 : Unified_cpp_editor_libeditor1.cpp Elapsed time 91.168096 : UnifiedBindings7.cpp Elapsed time 90.080235 : UnifiedBindings10.cpp Elapsed time 89.838960 : Unified_cpp_layout_base1.cpp You can see that the compilation time slows down by about 20 % most of the time and 30, 50% slow down can be observed for the top two files. I am going to show the -ftime-print output for the compilation of V9, V8, V7 g++ compiler of the same file in the attachment. But do note that mozilla Thunderbird configure script is very clever and try to add as many options as supported to each version of the compiler and thus, obviously v9 compiler may be doing a bit more than other version. Oh, yes, the slowdown has happened in v8 already (!) In the attachment, you can see that v8 and v9 are equally slow in terms of elapsed time. I can see that "phase last asm" has large elapsed time for v8 and v9 in comparison to v7. Otherwise, I could not see a clear smoking gun. The elapsed time of v7 and V9 arey 133 and 159sec for UnifiedBindings23.cpp (prepressed). But this difference is obviously inflated in real world workload when the compilation is run in parallel with "make -j6" in a 7 hypercore VirtualBox image. In any case, a single thread run has about 26 second difference which is about 20% slower already. Any possible hint or fix for speedup is appreciated. The compilation time slowdown hurts.: now building thunderbird in my spare time is a one night job after modifying a few source file. I used to check the behavior of modified binary before going to bed at least shortly and let a test suite run. I can't do that any more. Any checking needs to be done the next day...
[Bug c/94021] -Werror=format-truncation= seems to cause incorrect warning, thus error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021 --- Comment #3 from ishikawa,chiaki --- Created attachment 47965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47965=edit A short program that does NOT produce the error/warning. A simple problem that does NOT produce error/warning. So I am at a loss as to create a simple sample program. This source needs to be copied to /tmp/t-format-issue.c The original attachment, the preprocessed file needs to be copied to /tmp/Unified_c_libical_src_libical1.preprocessed.c for the script I uploaded in 47962. TIA
[Bug c/94021] -Werror=format-truncation= seems to cause incorrect warning, thus error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021 --- Comment #2 from ishikawa,chiaki --- Created attachment 47964 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47964=edit The script to issue gcc-9 with the original option setting. This is the command to invoke gcc-9 on my PC with the original option. The preprcessed source needs to be copied under /tmp directory. Also, it tries to compile t-format-issue.c (I called it incorrectly in my original post), which it succeeds to do so.
[Bug c/94021] -Werror=format-truncation= seems to cause incorrect warning, thus error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021 --- Comment #1 from ishikawa,chiaki --- Created attachment 47962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47962=edit This is the full compiler log I got. The is the full compiler error/warning log I got.
[Bug c/94021] New: -Werror=format-truncation= seems to cause incorrect warning, thus error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021
Bug ID: 94021
Summary: -Werror=format-truncation= seems to cause incorrect
warning, thus error.
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ishikawa at yk dot rim.or.jp
Target Milestone: ---
Created attachment 47961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47961=edit
preprocessed input file.
I am attaching the preprocessed source file,
and the exact command that produced the error.
And the error log in the following.
The crux of the "bogus" error is as follows.:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:1913:35:
error: ‘%02i’ directive output may be truncated writing 2 bytes into a region
of size between 1 and 5 [-Werror=format-truncation=]
1913 |snprintf (buffer, buffer_size, "%s%02i%02i%02i", sign, hours,
minutes, seconds);
| ^~~~
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:1913:35:
note: directive argument in the range [0, 59]
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:1913:35:
note: directive argument in the range [1, 59]
In file included from /usr/include/stdio.h:867,
from
/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers/stdio.h:3,
from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:34,
from Unified_c_libical_src_libical1.c:2:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note:
‘__builtin___snprintf_chk’ output between 8 and 12 bytes into a destination of
size 8
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
68 |__bos (__s), __fmt, __va_arg_pack ());
|~~
In file included from Unified_c_libical_src_libical1.c:2:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:1911:35:
error: ‘%02i’ directive output may be truncated writing 2 bytes into a region
of size between 1 and 5 [-Werror=format-truncation=]
1911 |snprintf (buffer, buffer_size, "%s%02i%02i", sign, hours, minutes);
| ^~~~
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:1911:35:
note: directive argument in the range [0, 59]
In file included from /usr/include/stdio.h:867,
from
/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers/stdio.h:3,
from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:34,
from Unified_c_libical_src_libical1.c:2:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note:
‘__builtin___snprintf_chk’ output between 6 and 10 bytes into a destination of
size 8
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
68 |__bos (__s), __fmt, __va_arg_pack ());
|~~
This comes from the source (unprocessed).: |sign| is either "+" or "-", and
the |hours|, |minutes|, and |seconds| are limited to [0,24), [0, 60).
if ((0 <= minutes && minutes <= 60) &&
(0 <= hours && hours <= 24) &&
(0 <= seconds && seconds <= 60)) {
if (seconds == 0)
snprintf (buffer, buffer_size, "%s%02i%02i", sign, hours, minutes);
else
snprintf (buffer, buffer_size, "%s%02i%02i%02i", sign, hours, minutes,
seconds);
} else {
Please note that in the error/warning message, the range is reported slightly
differently in a place.
/icaltimezone.c:1913:35: note: directive argument in the range [0, 59]
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:1913:35:
note: directive argument in the range [1, 59]
I suspect some kind of internal data corruption.
A very simple program source code, t-snrpintf-issue.c does not cause the
problem to manifest. So I think the problem is caused by a combination of
large source file and maybe inlining?
The source code is part of mozilla thunderbird (its calendar subsystem).
In another instance where such error/warning was observed,
when I added the constraint of the form of
if ((0 <= minutes && minutes <= 60) &&
(0 <= hours && hours <= 24) &&
(0 <= seconds && seconds <= 60))
the compilation worked without the truncation error/warning message.
But here even though I added the if-expr to constrain the values to only two
decimal digits, the error/warning persists.
TIA
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342 --- Comment #6 from ishikawa,chiaki --- Sorry, forgot to mention that Redhat bugzilla has a one line C source program that does not trip the compiler (no ICE), but obviously generates a wrong dwarf info. These certainly look related to me. TIA
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342 ishikawa,chiaki changed: What|Removed |Added CC||ishikawa at yk dot rim.or.jp --- Comment #5 from ishikawa,chiaki --- I think the combination of "-g3" *AND* "-gsplit-dwarf" seem to be the culprit. I noticed that there is a similar report in redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1377697 Summary: gcc debug info is broken with -gsplit-dwarf -g3
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #8 from ishikawa,chiaki --- As for gcc-5 ICE, I observe an important thing after a little experimentation. This is a shortened command line that causes the ICE. /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 -DTRIMMED=1 \ -DHAVE_CONFIG_H=vpx_config.h -fPIC -DMOZILLA_CLIENT \ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync\ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1\ -gsplit-dwarf -g3 -Og ./vp9_dsubexp.i If I remove -gsplit-dwarf, I don't get the ICE. ishikawa@debian-vbox-ci:/tmp$ /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 -DTRIMMED=1 \ -DHAVE_CONFIG_H=vpx_config.h -fPIC -DMOZILLA_CLIENT \ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync\ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1\ -g3 -Og ./vp9_dsubexp.i > > > > ishikawa@debian-vbox-ci:/tmp$ But then, leaving -gsplit-dwarf intact, if I change "-g3" to "-g", I don't get an ICE. ishikawa@debian-vbox-ci:/tmp$ /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 -DTRIMMED=1 \ -DHAVE_CONFIG_H=vpx_config.h -fPIC -DMOZILLA_CLIENT \ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync\ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1\ -gsplit-dwarf -g -Og ./vp9_dsubexp.i > > > > ishikawa@debian-vbox-ci:/tmp$ So it could be a combination of -gsplit-dwarf and -g3 in my GCC-5 case. I have no idea what the cause of ICE for G++-6 case, though. TIA
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #7 from ishikawa,chiaki --- Created attachment 40643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40643=edit preprocessed file that caused gcc-5 to experience the similar ICE. The uploaded file was created by passing -savetemps option when gcc-5 experienced the ICE as reported earlier. The following simplified command line caused gcc-5 to experience the ICE. /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 \ -DTRIMMED=1 -DHAVE_CONFIG_H=vpx_config.h\ -fPIC \ -DMOZILLA_CLIENT\ -Wall -Wempty-body -Wignored-qualifiers \ -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code \ -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations \ -Wno-error=array-bounds -fno-builtin-strlen -Wl,--gdb-index \ -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 \ -Werror=sign-compare -fno-strict-aliasing -fno-math-errno -pthread \ -pipe -gsplit-dwarf -g3 -Og -freorder-blocks -fno-omit-frame-pointer\ -Wno-sign-compare -Wno-unused-function \ ./vp9_dsubexp.i > > > > > > > > > > > > /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx/vp9/decoder/vp9_dsubexp.c:72:1: > > > > > > > > > > > > internal compiler error: in output_index_string, at > > > > > > > > > > > > dwarf2out.c:22895 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gcc-5 -v Using built-in specs. COLLECT_GCC=gcc-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.1-4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.1 20161202 (Debian 5.4.1-4) ishikawa@debian-vbox-ci:/tmp$ TIA
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #6 from ishikawa,chiaki --- (In reply to ishikawa,chiaki from comment #5) > I have found that g++-5 can compile this without ICE. > So this is a regression in gcc-6. > > The version that worked is: > > g++-5 -v > Using built-in specs. > COLLECT_GCC=g++-5 > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.1-4' > --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs > --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-5 --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --with-default-libstdcxx-abi=new --enable-gnu-unique-object > --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib > --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 > --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic > --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu > Thread model: posix > gcc version 5.4.1 20161202 (Debian 5.4.1-4) > ishikawa@debian-vbox-ci:/tmp$ Ouch, NO. GCC-5 is also vulnerable. gcc-5 also experienced an ICE on a different source file. So it is a problem with deeper root. /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx/vp9/decoder/vp9_dsubexp.c:72:1: internal compiler error: in output_index_string, at dwarf2out.c:22895 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. In the directory /home/ishikawa/objdir-tb3/media/libvpx The following command failed to execute properly: /usr/bin/ccache /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -I/home/ishikawa/objdir-tb3/dist/system_wrappers -include /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DHAVE_CONFIG_H=vpx_config.h -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx -I/home/ishikawa/objdir-tb3/media/libvpx -I/home/ishikawa/objdir-tb3/dist/include -I/home/ishikawa/objdir-tb3/dist/include/nspr -I/home/ishikawa/objdir-tb3/dist/include/nss -fPIC -include /home/ishikawa/objdir-tb3/mozilla-config.h -DMOZILLA_CLIENT -MD -MP -MF .deps/vp9_dsubexp.o.pp -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -Werror=sign-compare -fno-strict-aliasing -fno-math-errno -pthread -pipe -gsplit-dwarf -g3 -Og -freorder-blocks -fno-omit-frame-pointer -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/config/linux/x64/ -Wno-sign-compare -Wno-unused-function -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/config /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx/vp9/decoder/vp9_dsubexp.c I am going to upload the preprocessed file.
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #5 from ishikawa,chiaki --- I have found that g++-5 can compile this without ICE. So this is a regression in gcc-6. The version that worked is: g++-5 -v Using built-in specs. COLLECT_GCC=g++-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.1-4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.1 20161202 (Debian 5.4.1-4) ishikawa@debian-vbox-ci:/tmp$
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #4 from ishikawa,chiaki --- I found that the following simplified command line causes ICE while the next command line where I have removed "-fno-exception" does not cause ICE even though I still keep -gdwarf-output. Hope this may shed some light on the issue. command line and output ICE. /usr/bin/g++-6 -std=gnu++11 -o uvectr64.o -c-gsplit-dwarf -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DLOCALE_SNAME=92 -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DU_CHARSET_IS_UTF8 -MD -MP -MF -Wall -Wc++11-compat -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -fno-strict-aliasing -fno-rtti -fno-exceptions -pthread -g3 -Og uvectr64.ii /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/intl/icu/source/common/uvectr64.cpp:213:3: internal compiler error: in output_index_string, at dwarf2out.c:25635 U_NAMESPACE_END ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Command line without ICE. /usr/bin/g++-6 -std=gnu++11 -o uvectr64.o -c-gsplit-dwarf -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DLOCALE_SNAME=92 -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DU_CHARSET_IS_UTF8 -MD -MP -MF -Wall -Wc++11-compat -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -fno-strict-aliasing -fno-rtti -pthread -g3 -Og uvectr64.ii (Not sure though, if the object is correct or not.) TIA
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578
--- Comment #3 from ishikawa,chiaki ---
I noticed that in my case, it could be related to a name space issue since
U_NAMESPACE_END "}}" is to close the corresponding U_NAMESPACE_BEGIN "extern
"C++" "{ namespace U_ICU_NAMESPACE {".
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 ishikawa,chiaki changed: What|Removed |Added CC||ishikawa at yk dot rim.or.jp --- Comment #2 from ishikawa,chiaki --- Created attachment 40633 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40633=edit preprocessed file that triggers the ICE. I have also seen this bug with gcc version 6.3.0 20170124 (Debian 6.3.0-5) I am attaching a preprocessed file uvectr64.ii gcc version (distributed under Debian GNU/Linux) gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-5' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.3.0 20170124 (Debian 6.3.0-5) ishikawa@debian-vbox-ci:/tmp$ I encountered a bug during a compilation of mozilla thunderbird. I used the following command to compile the attached .ii file, and I got the following ICE. COMMAND LINE: /usr/bin/g++-6 -std=gnu++11 -o uvectr64.o -c-gsplit-dwarf \ -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DLOCALE_SNAME=92 \ -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_TRANSLITERATION \ -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION \ -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 \ -DU_CHARSET_IS_UTF8 -MD -MP -MF -Wall -Wc++11-compat\ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync \ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -fno-exceptions \ -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno \ -pthread -g3 -Og -freorder-blocks \ -fno-omit-frame-pointer -frtti -fdiagnostics-color \ ./uvectr64.ii ICE error: new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/intl/icu/source/common/uvectr64.cpp:213:3: internal compiler error: in output_index_string, at dwarf2out.c:25635 U_NAMESPACE_END ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. However, if I remove "-gsplit-dwarf" from my command line, it seems to compile. TIA
