[Bug c++/59463] Illegal Instruction: min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59463 --- Comment #5 from dank at kegel dot com --- Turns out in my case it was caused by duplicate entries in LD_LIBRARY_PATH. Go figure.
[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61638 dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com --- Comment #6 from dank at kegel dot com --- g++ 5.4.0 from ubuntu 16.04 suffers from this when compiling https://bitbucket.org/chromiumembedded/cef/src/54a015f785c08083c21ec5360e154a5af6f52c57/tests/ceftests/test_util.h : In file included from tests/ceftests/download_unittest.cc:9:0: tests/ceftests/test_util.h:167:1: error: multi-line comment [-Werror=comment] // #define MY_TEST_GROUP(test_name, test_mode) \ ^ It's just a code example, nicely commented out, and the compiler falsely complains of a multiline comment.
[Bug c++/59463] Illegal Instruction: min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59463
dank at kegel dot com changed:
What|Removed |Added
CC||dank at kegel dot com
--- Comment #4 from dank at kegel dot com ---
I saw two other similar problems on the web.
https://bugs.archlinux.org/task/46562 suggests it might be a microcode problem.
http://permalink.gmane.org/gmane.linux.lfs.support/40714 suggests it can
be caused (repeatably) by the compiler's gmp being built for a different
machine.
I just ran into this myself on six jobs in a parallel build on a big
xeon vmware box. It's reproduced in two out of two full runs, but
if I just rerun "make -j8", the build completes correctly, so it may
have to do with cpu load.
The simplified test case in #2 also doesn't seem to reproduce it.
// Thread model: posix
// gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
The error varies; sometimes it's
// /usr/include/c++/5/limits:1598:7: internal compiler error: Illegal
instruction
//min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
and sometimes it's
// /home/buildbot/src/yovo/libLoam/c++/Quat.h:440:3: internal compiler error:
Illegal instruction
//Quat Pow (float64 t, float64 thresh = 0.) const
//^
So in my case it doesn't sound like a gcc problem. Posting here for
completeness only.
[Bug c++/43407] Specifying visibility attribute of C++0x enum class emits warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407 dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com --- Comment #4 from dank at kegel dot com --- Just ran into this in the stock ubuntu 14.04 compiler, gcc-4.8.4. Inserting : int before the attribute works around the problem. Can someone confirm the bug?
[Bug target/19923] [4.0/4.1/4.2/4.3 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #41 from dank at kegel dot com 2007-11-19 12:27 --- OK, I'll see if I can get that done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1/4.2/4.3 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #43 from dank at kegel dot com 2007-11-28 18:01 --- Of the results posted above, the only interesting one that is still slower than gcc-2.95 is a pentium 3 with -fPIC. (Happily, gcc-4.3 is an improvement there, but it's still worse than 2.95.) Oddly, this one does better with athlon-xp tuning. /proc/cpuinfo info pic? tune [t_34/t_295, t_401/t_295, t_43/t_295] cpu family 6,model 11, Intel(R) Pentium(R) III CPU - S 1266MHz, -fPIC tune=pentium3 [1.37, 1.72, 1.20] cpu family 6,model 11, Intel(R) Pentium(R) III CPU - S 1266MHz, -fPIC tune=athlon-xp [2.16, 2.49, 1.10] I'm not sure how important Pentium III performance is anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug middle-end/24786] Missing warning on questionable use of parameter to initialize static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786
dank at kegel dot com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #5 from dank at kegel dot com ---
Methinks it's been fixed:
$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
$ gcc -c blah.c
blah.c: In function ‘blah1’:
blah.c:3:11: warning: function returns address of local variable
[-Wreturn-local-addr]
3 |return &x;
| ^~
blah.c: In function ‘blah2’:
blah.c:8:36: error: initializer element is not constant
8 |static const char *names[1] = { &x };
|^
blah.c:8:36: note: (near initialization for ‘names[0]’)
Also fixed with:
gcc-6 (Ubuntu 6.5.0-2ubuntu1) 6.5.0 20181026
Marking fixed.
But see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69433
[Bug other/90556] [meta-bug] bogus/missing -Wreturn-local-addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556 Bug 90556 depends on bug 24786, which changed state. Bug 24786 Summary: Missing warning on questionable use of parameter to initialize static https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com --- Comment #5 from dank at kegel dot com 2013-04-07 21:29:20 UTC --- What's the status of this patch?
[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com --- Comment #4 from dank at kegel dot com 2013-04-21 14:22:41 UTC --- Austin English said "I did...that's what led to the original commit showing the segfault. IOW: $ git reset --hard c8010b803d34fa7e096747067e33c650b36ecc06 # build gcc/wine - gcc fails to build wine, internal compiler error $ git show d73df2920c77116fd88e03cd95dd352f16511a3f | patch -p1 # build gcc/wine - wine segfaults on launch" So bisecting seems complete. Also, Kirill Smirnov reports that building wine using just -O2 runs into this bug for him, but building wine with "-O2 -fno-builtin-memcpy" doesn't. Next step may be to bisect wine's source code to see which file or files misbehave when built with -O2 but without -fno-builtin-memcpy.
[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #6 from dank at kegel dot com 2013-04-22 16:39:37 UTC ---
You'd think... but I didn't find any obvious memcpy replacement.
I spent some time bisecting the wine source yesterday. There appear to be
at least three or four affected sites. I bisected one of the affected files
with
#pragma GCC optimize("-O2")
...
#pragma GCC optimize("-O1")
and the offending memcpy() there seems to be
http://source.winehq.org/source/dlls/kernel32/process.c#L1316
There are plenty of clues to chase down, hope I have time to spend on it
sometime soon.
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
--- Additional Comments From dank at kegel dot com 2005-03-23 17:06 --- That's the same one I mentioned in http://gcc.gnu.org/ml/gcc/2005-03/msg00991.html I was going to report it, but you beat me to it, and you did a better job of minimizing the test case thank I did. Thanks! What does it take to confirm the bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
-- What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"
--- Additional Comments From dank at kegel dot com 2005-03-25 18:29 --- A patch to gcc-3.3.3 to do exactly what you're asking for was posted by Dave Korn a few months ago, and approved in principle: http://gcc.gnu.org/ml/gcc/2004-07/msg00798.html I'll attach a copy of the patch here. -- What|Removed |Added CC| |dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug rtl-optimization/20815] New: -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
This problem is present in at least gcc-3.4.[123], gcc-3.4-20050401, and
gcc-4.0-20050305. I have not tested a later gcc-4.0 yet.
Create a test file pgo.cc:
#include
namespace {
void
func() {
std::cout << "In func" << std::endl;
}
}
int main() { func(); }
Compile it, run it, and recompile it as follows:
i686-unknown-linux-gnu-g++ -fprofile-generate -o pgo pgo.cc
./pgo
i686-unknown-linux-gnu-g++ -fprofile-use -o pgo pgo.cc
The -fprofile-use compilation fails with
pgo.cc: In function 'void::func()':
pgo.cc:6: error: coverage mismatch for function
'_ZN35_GLOBAL__N_pgo.cc__8B40D3D54funcEv' while reading counter 'arcs'.
pgo.cc:6: error: checksum is 5c057dbb instead of 3746c244
Commenting out the namespace makes the problem go away.
This keeps me from building some real apps with profile-driven optimization,
which may result in switching from gcc to icc for this app.
Thanks to Simon Baldwin for finding such a nice little test case for this.
--
Summary: -fprofile-use barfs with "coverage mismatch for function
'...' while reading counter 'arcs'."
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
[Bug middle-end/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
--- Additional Comments From dank at kegel dot com 2005-04-08 00:03 --- Aha. So this is a duplicate of bug 9393, in essence? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
[Bug middle-end/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
--- Additional Comments From dank at kegel dot com 2005-04-08 00:03 --- Oh, ok, it's not *quite* a dup of 9393, since you could save the seed in the output file from the first run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
[Bug middle-end/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
--- Additional Comments From dank at kegel dot com 2005-04-08 04:17 --- What value should be passed for that option? Would the absolute pathnme of the source file do? In case other people out there have as much trouble reading TFM as I do, I should note that the gcc doc says "-frandom-seed=string ... The string should be different for every file you compile." Thus the suggestion in http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042627.html of using the same string always for this option is probably a bad idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
[Bug middle-end/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."
--- Additional Comments From dank at kegel dot com 2005-04-08 16:38 --- Or should the doc say also that the argument to -frandom-seed should be the same every time anyone compiles the same file? In that case, the relative path of the file within the project would be a better choice. So when compiling mozilla/main.c you would give -frandomSeed=mozilla/main.c right? Don't know how much this matters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
--- Additional Comments From dank at kegel dot com 2005-04-14 05:28 --- Still seeing this on 4.0.0-rc1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug c++/21440] New: [4.0 Regression] ICE with statement-as-expression
The following test program works with gcc-2.95.3 and gcc-3.4.1,
but aborts with this error on gcc-4.0.0:
z.ii: In function 'void bar()':
z.ii:11: internal compiler error: in create_tmp_var, at gimplify.c:368
struct Foo {
~Foo() {}
int i;
operator bool() { return !i; }
};
void bar() {
Foo foo = ({
Foo bletch;
bletch.i = 0;
bletch;
});
}
This popped up in an early run of gcc-4.0.0 on real code.
--
Summary: [4.0 Regression] ICE with statement-as-expression
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21440
[Bug c++/21440] [4.0 Regression] ICE with statement-as-expression
--- Additional Comments From dank at kegel dot com 2005-05-07 08:31 --- Forgot to mention: I have applied the fixes for PR20973 and PR21173 as given in bugzilla. -- What|Removed |Added Summary|[4.0 Regression] ICE with |[4.0 Regression] ICE with |statement-as-expression |statement-as-expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21440
[Bug other/18508] [3.4/4.0 Regression] "basename: too few arguments" when building without bootstrap
--- Additional Comments From dank at kegel dot com 2005-05-14 16:30 --- On Cygwin, the symptoms may be slightly different. Here's a snippet of a build log from Petr Cvachoucek: basename: missing operand Try `basename --help' for more information. mv: `libgcc_s_nof.so.1' and `libgcc_s_nof.so.1.' are the same file make[2]: *** [nof/libgcc_s_nof.so] Error 1 (Yep, Cygwin considers foo and foo. to be the same file.) I only mention this for completeness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18508
[Bug target/21623] New: [4.0 regression] ICE in reload_cse_simplify_operands, at postreload.c:391
Using crosstool-0.34, building glibc-2.3.5 on sh4 is ok with gcc-3.4.3,
fails with gcc-4.0.0. The attached reduced testcase shows the error:
foo2.i: In function 'plural_eval':
foo2.i:78: error: insn does not satisfy its constraints:
(insn 190 188 275 24 (set (reg/v:SI 76 fr12 [orig:169 n ] [169])
(reg:SI 147 t)) 129 {movsi_ie} (insn_list:REG_DEP_TRUE 188 (nil))
(nil))
foo2.i:78: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
--
Summary: [4.0 regression] ICE in reload_cse_simplify_operands, at
postreload.c:391
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sh4-unknown-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21623
[Bug target/21623] [4.0 regression] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From dank at kegel dot com 2005-05-17 14:33 --- Created an attachment (id=8911) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8911&action=view) reduced source from glibc-2.3.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21623
[Bug rtl-optimization/17810] [3.4 Regression] internal compiler error: in verify_local_live_at_start for arm-rtems, arm-linux
--- Additional Comments From dank at kegel dot com 2005-05-20 18:05 --- http://sources.redhat.com/ml/crossgcc/2005-05/msg00154.html is a report of a similar problem with gcc-3.4.3. xfree86-4.5.0's fontutils.c causes an ICE when compiled with -O3 -fno-strict-aliasing. Backing down to xfree86-4.4.0, or using -O2, or not using -no-strict-aliasing, or using gcc-4.0.0, makes the problem go away. I'll attach a reduced testcase. To reproduce, do $ arm-unknown-linux-gnu-gcc -O3 -fno-strict-aliasing -c fontutils.i Error is fontutils.i:44: internal compiler error: in verify_local_live_at_start, at flow.c:546 Is this the same problem, or should I file a new report? -- What|Removed |Added CC| |dank at kegel dot com, ||nagaraja at ncoretech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17810
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From dank at kegel dot com 2005-05-31 03:41 --- See also http://marc.theaimsgroup.com/?l=openssl-dev&m=111238996923252&w=2 which says --- snip --- gcc-4 miscompiles inline assembly bn/asm/x86_64-gcc.c so that the functions bn_add_words and bn_sub_words are broken and segfault. This applies only to the stable branch as in the devel branch there is added initialization of the ret and i variables. However the initialization is unnecessary instead the code should be modified this way: @@ -164,7 +186,7 @@ " leaq1(%2),%2\n" " loop1b \n" " sbbq%0,%0 \n" - : "+a"(ret),"+c"(n),"+r"(i) + : "=&a"(ret),"+c"(n),"=&r"(i) : "r"(rp),"r"(ap),"r"(bp) : "cc" ); @@ -187,7 +209,7 @@ " leaq1(%2),%2\n" " loop1b \n" " sbbq%0,%0 \n" - : "+a"(ret),"+c"(n),"+r"(i) + : "=&a"(ret),"+c"(n),"=&r"(i) : "r"(rp),"r"(ap),"r"(bp) : "cc" ); --- snip --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From dank at kegel dot com 2005-06-03 23:37 --- I'm tempted to start a new PR with summary "std::string slow in multithreaded programs due to COW" so we can focus on the quality of implementation issue, and leave aside the question of correctness. James, could you please participate in these discussions by using the web interface (e.g. http://gcc.gnu.org/PR21334)? That would avoid the boilerplate disclaimer that gets appended to each one of your emails. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug c++/21951] New: [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
Compiling the following code:
#include
std::vector *factory()
{
std::vector *p = new std::vector;
p->reserve(10);
return p;
}
with -Wall -O -fno-exceptions yields the following error in gcc-4.0.0
and gcc-4.0-20050602:
.../include/c++/4.0.0/bits/vector.tcc: In member function 'void std::vector<_Tp,
_Alloc>::reserve(size_t) [with _Tp = int, _Alloc = std::allocator]':
.../include/c++/4.0.0/bits/vector.tcc:78: warning: control may reach end of
non-void function 'typename _Alloc::pointer std::vector<_Tp,
_Alloc>::_M_allocate_and_copy(size_t, _ForwardIterator, _ForwardIterator) [with
_ForwardIterator = int*, _Tp = int, _Alloc = std::allocator]' being inlined
The warning comes from a catch/rethrow block deep in the bowels of stl
which (because of -fno-exceptions) evaluates to if(false).
This is a false positive warning, which would be fine except
for shops whose policy is to always compile with -Werror -Wall;
there, the warning is fatal. And because this problem is not
confined to just one user source file, it's hard to work around.
This problem does not occur in gcc-3.4.3 nor in recent gcc-4.1 snapshots.
cf. discussion here: http://gcc.gnu.org/ml/libstdc++/2005-06/msg00073.html
--
Summary: [gcc-4.0 regression, rejects-valid]
std::vector.reserve() unusable with -Werror -Wall -O -
fno-exceptions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From dank at kegel dot com 2005-06-08 13:57 --- It sure as hell is for those shops that require -Werror. But ok, I'll be happy if it's fixed for 4.0.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From dank at kegel dot com 2005-06-11 11:25 --- OK, I'm testing a patch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From dank at kegel dot com 2005-06-11 19:29 --- Created an attachment (id=9071) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9071&action=view) proposed workaround -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From dank at kegel dot com 2005-09-15 12:39 --- I would dearly love to be able to say -Woverzealous-qualification or something like that to turn on this warning. It would make keeping our code portable much easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From dank at kegel dot com 2005-09-15 13:09 --- Pain. We have a very large application, and we cannot afford to fix all the warnings -pedantic gives. This is another case of "we want to turn on and off individual warnings, please". We're getting mighty tired of having to fix this particular problem in our source over and over again every time we try our app with a non-gcc compiler; pretty please let us turn this warning on by itself... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From dank at kegel dot com 2005-09-15 13:11 --- Also, the non-gcc compiler we're trying our code with supports some but not all gnuisms, so -pedantic would actually cause us to fix much more of our code than is practically neccessary for the kind of portability we want at the moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From dank at kegel dot com 2005-09-15 16:49 --- We build everything with -Werror so errors are flagged as fatal. If we added -pedantic, we'd have to stop using -Werror, and implement the fatal error check ourselves in a wrapper, which would be a huge pain. gcc-4.1 had a stated goal of giving every warning a name, and letting them be turned on and off individually. See http://gcc.gnu.org/wiki/Warning%20Message%20Control I thought I was asking for something along the same lines. I can't understand why anybody would oppose the ability to turn on and off warnings selectively; Jason, are you also opposed to that feature of gcc-4.1? I am all in favor of forcing code to be C++ compliant, but I have to tell you I just spent the last year whipping a codebase into shape in that regard, and I'd really like to be able to pick my battles, and not have to fight the tools to do so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From dank at kegel dot com 2005-09-15 21:39 --- Sounds like we're in violent agreement, then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug middle-end/17886] variable rotate and long long rotate should be better optimized
--- Additional Comments From dank at kegel dot com 2005-09-29 04:36 --- Thanks - I'll try to get this benchmarked on a semi-real app. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
[Bug c++/19756] -Wparentheses doesn't warn on ambiguous if in C++
--- Comment #6 from dank at kegel dot com 2005-11-01 20:22 --- Is this a duplicate of bug 19564 ? -- dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19756
[Bug c++/24786] New: Missing warning on questionable use of parameter to initialize static
gcc only warns on blah1 on the following code:
const char *blah1() {
char x = 7;
return &x;
}
const char *blah2() {
char x = 7;
static const char *names[1] = { &x };
return names[0];
}
returnlocal.cc: In function 'const char* blah1()':
returnlocal.cc:2: warning: address of local variable 'x' returned
Shouldn't it warn on blah2 as well?
Or is that asking too much?
--
Summary: Missing warning on questionable use of parameter to
initialize static
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #22 from dank at kegel dot com 2005-11-18 18:19 --- We just ran into this trying to link a .a compiled with gcc-3.4.x against an app using gcc-4.0.1. Unfortunately, the .a is from a third party, so we can't share it or even look at the source ourselves. Here are a couple other posts which mention a similar bug. One of them almost has a simple test case. http://lists.debian.org/debian-mentors/2005/10/msg00316.html http://groups.google.com/group/de.comp.lang.iso-c++/msg/88f4ecd82239131c -- dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug target/11901] New: set_fpscr isn't PIC even when __PIC__ defined; bad for prelinking, causes glibc-3.2.3 check-textrel test to fail
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11901 Summary: set_fpscr isn't PIC even when __PIC__ defined; bad for prelinking, causes glibc-3.2.3 check-textrel test to fail Product: gcc Version: 3.3.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dank at kegel dot com CC: gcc-bugs at gcc dot gnu dot org,kkojima at rr dot iij4u dot or dot jp GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: sh4-*-linux-gnu set_fpscr contains the line "mov.l LOCAL(set_fpscr_L1),r1" which generates non-PIC code. This causes the glibc-2.3.2 check-textrel regression test to fail, and probably gets in the way of prelinking. A patch by Kaz to fix this is at http://www.kegel.com/crosstool/current/gcc-3.3-patches/sh-pic-set_fpscr.patch It seems to fix the problem for me. Please include this patch in gcc-3.3.2.
[Bug target/9552] accepts invalid code for attribute section
--- Additional Comments From dank at kegel dot com 2004-05-10 21:09 --- With gcc-3.4.0, at least, the ICE depends on the build system's toolchain! You can predict whether the ICE will occur by running with -S and grepping for eh_frame. The ICE occurs if the first eh_frame's w attribute disagrees with the const attribute of the __EH_FRAME_BEGIN__ in the test case. Here's the annoying part: with gcc-3.4.0, at least, the first eh_frame's 'w' attribute *seems to depend on the build system's binutils or glibc*! eh_frame has 'w' when gcc-3.4.0 is built on a system using gcc-3.3.3/glibc-2.1.3/binutils-2.14.90.0.5, and lacks the 'w' when built on a system using gcc-3.2.2/glibc-2.3.2/binutils-2.13.90.0.18. Thus one system's workaround (adding a 'const') seems to be another system's poison. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9552
[Bug c++/19027] New: add keyword 'error:' to remaining error messages that lack it
In building a large application, I ran across the following error messages
that do not contain the string 'error:', which makes them harder to fish
out of the log with a regular expression:
"xxx" redefined
#error "xxx"
#warning "xxx"
xxx: No such file or directory
character constant too long for its type
extra tokens at end of #endif directive
extra tokens at end of #include directive
extra tokens at end of #undef directive
invalid suffix "xxx" on floating constant
invalid suffix "xxx" on integer constant
macro "xxx" passed 3 arguments, but takes just 1
multi-line comment
no newline at end of file
pasting "xxx" and "xxx" does not give a valid preprocessing token
trigraph xxx ignored, use -trigraphs to enable
undefined reference to `xxx'
unterminated argument list invoking macro "xxx"
gcc should emit the word 'error:' in front of each
of these error messages to make it easier to grep for
errors. (OK, one of those is an ld error, but I left it in
anyway :-)
--
Summary: add keyword 'error:' to remaining error messages that
lack it
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19027
[Bug preprocessor/19027] add keyword 'error:' to remaining error messages that lack it
-- What|Removed |Added Component|c++ |preprocessor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19027
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-17 00:59 --- We're learning more about this bug. Anthony Danalis has boiled down the testcase much further; I'll attach the reduced testcase as foo4.i. It looks like it shows up if your /proc/cpuinfo says vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 9 cpu MHz : 2793.051 cache size : 512 KB but not if your /proc/cpuinfo says vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping: 1 cpu MHz : 3200.255 cache size : 1024 KB But here's the fun part: on the newer CPU with the bigger cache, gcc-2.95.3 was just as slow as gcc-3.4.3/gcc-4.0.0. Go figure. We'll add more details once we've got more info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-18 06:24 --- Looks to me like gcc-3.4.3 is known to fail, too, depending on the CPU. Anthony Danalis and I came up with a little script to run foo4.i on various processors with various values for -mtune, which I'll attach; here are the results for four different x86 variants. The last two columns are the time on gcc-3.4.3 and gcc-4.0.0 divided by the time on gcc-2.95.3, so any value above 1.0 in the last column is a performance regression. Rows are sorted by the last column. The first five rows represent performance regressions for gcc-3.4.3; the first three also represent performance regressions for gcc-4.0.0. family,model,name pic? tune [t_295, t_343, t_400] [t_295/t_295, t_343/t_295, t_400/t_295] 6,8, Pentium III (Coppermine), -fPIC athlon-xp [9.25, 16.22, 18.79] [1.00, 1.75, 2.03] 15,2, Xeon(TM) CPU 2.60GHz, -fPIC pentium4 [1.91, 3.89, 3.27][1.00, 2.04, 1.71] 6,8, Pentium III (Coppermine), -fPIC pentium3 [9.15, 10.10, 13.20] [1.00, 1.10, 1.44] 15,2, Xeon(TM) CPU 2.60GHz, -fPIC athlon-xp [1.91, 2.00, 1.95][1.00, 1.05, 1.02] 6,8, Pentium III (Coppermine), -fPIC pentium4 [9.27, 10.49, 8.87] [1.00, 1.13, 0.96] --- ok below this line --- 6,8, Pentium III (Coppermine),pentium4 [14.74, 13.71, 14.12] [1.00, 0.93, 0.96] 15,4, Athlon(tm) 64 3000+, -fPIC pentium4 [4.12, 3.68, 3.74][1.00, 0.89, 0.91] 15,4, Pentium(R) 4 CPU 3.20GHz, -fPIC pentium4 [2.48, 2.18, 2.09][1.00, 0.88, 0.84] 15,4, Athlon(tm) 64 3000+, -fPIC athlon-xp [4.12, 3.50, 3.20][1.00, 0.85, 0.78] 15,4, Pentium(R) 4 CPU 3.20GHz, pentium4 [2.17, 1.07, 1.07][1.00, 0.49, 0.49] 6,8, Pentium III (Coppermine),pentium3 [14.22, 6.26, 6.46] [1.00, 0.44, 0.45] 6,8, Pentium III (Coppermine),athlon-xp [14.93, 6.26, 6.27] [1.00, 0.42, 0.42] 15,4, Athlon(tm) 64 3000+,pentium4 [3.65, 1.39, 1.39][1.00, 0.38, 0.38] 15,4, Athlon(tm) 64 3000+,athlon-xp [3.65, 1.39, 1.40][1.00, 0.38, 0.38] 15,2, Xeon(TM) CPU 2.60GHz, pentium4 [6.42, 0.97, 0.98][1.00, 0.15, 0.15] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-18 06:38 --- To be clear, here are the two most worrying rows from the above table, expanded a bit. These are the runtimes of foo4.i in seconds. The cpu family, model, and name are as shown by /proc/cpuinfo. cpu family 15, model 2, Intel(R) Xeon(TM) CPU 2.60GHz: -fPIC -mtune=pentium4 -O3 gcc-2.95.3: 1.91 seconds gcc-3.4.3: 3.89 gcc-4.0.0: 3.27 cpu family 6, model 8, Pentium III (Coppermine) -fPIC -mtune=pentium3 -O3 gcc-2.95.3: 9.15 gcc-3.4.3: 10.10 gcc-4.0.0: 13.20 gcc-4.0.0 produces code that runs 1.7 and 1.4 times slower than gcc-2.95.3 on these (fairly common!) cpus, even when the proper -mtune is used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-18 17:46 --- The above tests did not use -mcpu on gcc-2.95.3, so they were comparing apples to oranges, kind of. I reran them on a PIII with gcc-2.95.3 -mcpu=$tune -O3 and gcc-[34] -mtune=$tune -O3. The problem persists even when using the most appropriate tuning option for the CPU in question. cpu family 6,model 8, Pentium III (Coppermine): -fPIC -mcpu=pentium -O3 gcc-2.95.3: 7.61 gcc-3.4.3: 27.43 gcc-4.0.0: 17.57 cpu family 6,model 8, Pentium III (Coppermine): -fPIC -mcpu=pentiumpro -O3 gcc-2.95.3: 9.27 gcc-3.4.3: 10.09 gcc-4.0.0: 13.96 cpu family 15, model 2, Intel(R) Xeon(TM) CPU 2.60GHz: -fPIC -mtune=pentium4 -O3 gcc-2.95.3: 1.91 seconds gcc-3.4.3: 3.89 gcc-4.0.0: 3.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-18 22:45 ---
I asked the fellow who posted the original problem report to give
me the results of 'cat /proc/cpuinfo' on the affected machine.
Here it is:
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping: 10
cpu MHz : 896.153
This is the same as one of the two affected CPU types here.
The slow routine appears to be the buffer cleaning routine,
though I haven't verified this with oprofile yet.
Here's its loop:
static char cleanse_ctr;
...
while (len--) {
*(ptr++) = cleanse_ctr;
cleanse_ctr += (17 + (unsigned char) ((int) ptr & 0xF));
}
and the output of -O3 -fPIC for both gcc-2.95.3 and gcc-4.0.0:
--- gcc-2.95.3 ---
.L5:
movl [EMAIL PROTECTED](%ebx),%edi
movb (%edi),%al
movb %al,(%edx)
incl %edx
movb (%edi),%cl
addb $17,%cl
movb %dl,%al
andb $15,%al
addb %al,%cl
movb %cl,(%edi)
subl $1,%esi
jnc .L5
.L4:
--- gcc-4 ---
.L4:
movb(%esi), %al
movb%al, (%edx)
leal(%ecx,%edi), %eax
andl$15, %eax
incl%ecx
addb(%esi), %al
incl%edx
addl$17, %eax
cmpl%ecx, 12(%ebp)
movb%al, (%esi)
jne .L4
It's not obvious to me why the gcc-4.0.0 generated code
should be slower when run on some CPUs, if in fact it is.
Is it the fact that the loop condition is checked with
a cmp against memory instead of a flag being set by subtracting
1 from a register?
(And where's the best place to learn about how to predict
how long assembly snippets like this will take to run
on various modern CPUs, anyway?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-24 15:00 --- Michael Meissner looked at the code, and saw that gcc-2.95.3 converts the loop to a countdown loop, but gcc-3.x doesn't, which wastes a precious register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From dank at kegel dot com 2005-06-24 15:01 --- And, for what it's worth, the latest 4.1 snapshot also suffers from this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug tree-optimization/17863] [4.0/4.1 Regression] threefold performance loss, not inlining as much
--- Additional Comments From dank at kegel dot com 2005-06-27 04:54 --- I just verified the regression here with -march=pentium on a pentium 4. On the original testcase, I got runtimes of 7.0, 4.9, 8.1, and 7.0 seconds with gcc-2.95.3, gcc-3.4.3, gcc-4.0.0, and gcc-4.1-20050603 using just -O3 (no -static). -- What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Additional Comments From dank at kegel dot com 2005-06-27 06:59 --- I just reproduced this on two flavors of pentium 4 using -O3 -mtune=pentium. The regression is worse, sometimes much worse, with -fPIC. Times for gcc-2.95.3, gcc-3.4.3, gcc-4.0.0, gcc-4.1-20050603: test run 1: /proc/cpuinfo: cpu family 15, model 2, Intel Pentium 4 CPU 2.80GHz. no -fPIC: 2.2, 2.7. 0.6. 0.6 seconds with fPIC: 2.2, 2.9, 2.9, 2.9 seconds test run 2: /proc/cpuinfo: cpu family 15, model 4, Intel Pentium 4 CPU 3.20GHz no -fPIC: 1.9, 3.2, 0.5, n/a seconds with fPIC: 1.9, 3.6, 3.6, n/a seconds -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug tree-optimization/17863] [4.0/4.1 Regression] threefold performance loss, not inlining as much
--- Additional Comments From dank at kegel dot com 2005-07-01 03:44 --- Anthony, it looks like the runtimes with the fix match the runtimes from the larger testcase reasonably well; at least they're faster on gcc-3.4.3 where they're supposed to be. So maybe we should try to answer the questions from comment # 22 for the reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From dank at kegel dot com 2005-07-01 19:42 --- That's certainly prettier than my header changes. I'll give it a shot. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
--- Additional Comments From dank at kegel dot com 2005-07-06 05:11 --- Still seeing this on gcc-4.0.1-20050702. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug middle-end/22398] New: ICE in compare_values, at tree-vrp.c:445
Compiling arch/sparc/kernel/process.c from linux-2.6.11.3
with gcc-4.1-20050709 fails with
arch/sparc/kernel/process.c: In function '__show_backtrace':
arch/sparc/kernel/process.c:204: internal compiler error: in compare_values, at
tree-vrp.c:445
Here's the command I use to reproduce:
sparc-unknown-linux-gnu-gcc \
-fno-strict-aliasing -fno-common -ffreestanding \
-O2 -fomit-frame-pointer -m32 -mno-fpu -fcall-used-g5 \
-fcall-used-g7 -c process.i
I haven't reduced process.i; it's 250KB. You can download it
from http://kegel.com/gcc/process.i.txt
--
Summary: ICE in compare_values, at tree-vrp.c:445
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22398
[Bug middle-end/22398] [4.1 Regression] ICE in compare_values, at tree-vrp.c:445
--- Additional Comments From dank at kegel dot com 2005-07-11 05:20 --- Deity on a crutch! That was fast. Thanks; I can test if you like, or just wait for the next snapshot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22398
[Bug bootstrap/22541] New: Building into empty PREFIX causes broken limits.h to be installed
When building gcc-3.4.3 or gcc-4.x into a clean $PREFIX, the configure script happily copies the glibc include files from include to sys-include; here's the line from the log file (with $PREFIX instead of the real prefix): Copying $PREFIX/i686-unknown-linux-gnu/include to $PREFIX/i686-unknown-linux-gnu/sys-include But later, when running fixincludes, it gives the error message The directory that should contain system headers does not exist: $PREFIX/lib/gcc/i686-unknown-linux-gnu/3.4.3/../../../../i686-unknown-linux-gnu/sys-include Nevertheless, it continues building; the header files it installs in $PREFIX/lib/gcc/i686-unknown-linux-gnu/3.4.3/include do not include the boilerplate that would cause it to #include_next the glibc headers in the system header directory. Thus the resulting toolchain can't compile the following program: #include int x = PATH_MAX; because its limits.h doesn't include the glibc header. The problem is that gcc/Makefile.in assumes that it can refer to $PREFIX/i686-unknown-linux-gnu with the path $PREFIX/lib/../i686-unknown-linux-gnu, but that fails because the directory $PREFIX/lib doesn't exist during 'make all'; it is only created later, during 'make install'. (Which makes this problem confusing, since one only notices the breakage well after 'make install', at which point the path configure complained about does exist, and has the right stuff in it.) I posted a proposed fix to http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00751.html -- Summary: Building into empty PREFIX causes broken limits.h to be installed Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dank at kegel dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
[Bug rtl-optimization/22553] New: [4.1 regression] ICE building libstdc++
Building a C/C++ cross-compiler targeting sh4-linux fails with
include/ext/bitmap_allocator.h:1085: internal compiler error: in spill_failure,
at reload1.c:1889
I grabbed the preprocessed source, and was able to reproduce it with
the commandline
gcc-4.1-20050716-glibc-2.3.2/build-gcc/./gcc/xgcc
-B/.../gcc-4.1-20050716-glibc-2.3.2/build-gcc/./gcc/ -O2 -fPIC -c foo.ii
foo.ii: In member function '_Tp*
__gnu_cxx::bitmap_allocator<_Tp>::_M_allocate_single_object() [with _Tp =
wchar_t]':
foo.ii:2206: error: unable to find a register to spill in class 'R0_REGS'
foo.ii:2206: error: this is the insn:
(insn:HI 393 416 746 30 (set (reg/f:SI 2 r2 [388])
(mem/u:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 10 r10 [574])) [0 S4 A32])) 172 {movsi_ie} (nil)
(expr_list:REG_EQUIV (symbol_ref/i:SI
("_ZN9__gnu_cxx16bitmap_allocatorIwE13_S_block_sizeE") )
(nil)))
foo.ii:2206: internal compiler error: in spill_failure, at reload1.c:1889
--
Summary: [4.1 regression] ICE building libstdc++
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sh4-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
[Bug target/22553] [4.1 regression] ICE building libstdc++
--- Additional Comments From dank at kegel dot com 2005-07-18 19:10 --- Created an attachment (id=9303) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9303&action=view) Preprocessed source showing the problem -- What|Removed |Added Component|rtl-optimization|target Keywords||build, ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
[Bug c++/23045] New: ICE in force_decl_die, at dwarf2out.c:12621
In testing gcc-4.1-20050716 for i686:
I originally ran into the following error
internal compiler error: tree check: expected tree that contains 'decl
minimal' structure, have 'record_type' in lookup_decl_die, at dwarf2out.c:5461
on the last line of a program. While starting to come up with
a minimal test case, I was surprised to find that although
I could reproduce that error with preprocessed source,
stripping out the lines starting with # produced a different error:
x.ii: In instantiation of '__gnu_cxx::rope >':
x.ii:42429: instantiated from here
x.ii:41107: internal compiler error: in force_decl_die, at dwarf2out.c:12621
This is probably fortunate, since it now dies much sooner than at the
end of the program.
To reproduce this, unpack http://kegel.com/gcc/ice-rope.ii.gz,
then compile it with
i686-unknown-linux-gnu-gcc -g -Wall -Werror -funsigned-char -c
Apologies for not finding a small testcase,
and for using a week-old snapshot for testing.
Hopefully this is useful anyway.
--
Summary: ICE in force_decl_die, at dwarf2out.c:12621
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045
[Bug c++/23046] New: ICE in set_value_range, at tree-vrp.c:191
While testing gcc-4.1-20050716, I ran across the error
bar.cc: In static member function 'static std::string
Blort::ConstructFullName(const std::string&, const std::vector >*, const std::string&, Blort::TwoValuedEnumType)':
bar.cc:1214: internal compiler error: in set_value_range, at tree-vrp.c:191
This was reproducible with just -O2; no other compiler flags were needed
to get the ICE. (-O wasn't enough.)
It might be hard to provide a sanitized testcase,
but I can try if that's needed to track this down.
--
Summary: ICE in set_value_range, at tree-vrp.c:191
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug c++/23045] ICE in force_decl_die, at dwarf2out.c:12621
--- Additional Comments From dank at kegel dot com 2005-07-24 17:28 --- Yep. Compiling PR22034's testcase yields pr22034.cc:6: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'record_type' in lookup_decl_die, at dwarf2out.c:5461 And compiling pr22514's testcase yields pr22514.cc:11: error: expected unqualified-id before '}' token pr22514.cc: In instantiation of 's::list<1>': pr22514.cc:12: instantiated from here pr22514.cc:8: internal compiler error: in force_decl_die, at dwarf2out.c:12621 So this is a dup. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045
[Bug c++/23056] New: [4.0/4.1 regression] ICE in write_template_arg_literal, at cp/mangle.c
We get an ICE building a real C++ app.
Thanks to mec for the minimized testcase, which I will attach.
Building it with gcc-4.0.1 and last week's gcc-4.1 snapshot
produces the errors shown below.
gcc-4.0.1:
i686-unknown-linux-gnu-g++ -c b2.cc
b2.cc: In instantiation of 'Beta':
b2.cc:40: instantiated from here
b2.cc:8: internal compiler error: in write_template_arg_literal, at
cp/mangle.c:2203
gcc-4.1-20050716:
i686-unknown-linux-gnu-g++ -c b2.cc
b2.cc: In instantiation of 'Beta':
b2.cc:40: instantiated from here
b2.cc:8: internal compiler error: in write_template_arg_literal, at
cp/mangle.c:2228
--
Summary: [4.0/4.1 regression] ICE in write_template_arg_literal,
at cp/mangle.c
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23056
[Bug c++/23056] [4.0/4.1 regression] ICE in write_template_arg_literal, at cp/mangle.c
--- Additional Comments From dank at kegel dot com 2005-07-25 05:27 --- Created an attachment (id=9357) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9357&action=view) Minimal test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23056
[Bug c++/23056] [4.0/4.1 regression] ICE in write_template_arg_literal, at cp/mangle.c
--- Additional Comments From dank at kegel dot com 2005-07-25 05:29 --- Also seems to happen with cvs HEAD at the moment, so it's a live one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23056
[Bug c++/23056] [4.0/4.1 regression] ICE in write_template_arg_literal, at cp/mangle.c
--- Additional Comments From dank at kegel dot com 2005-07-25 05:47 --- Sorry we didn't test with our app before gcc-4.0 was released. We'll try to do better for gcc-4.1. This bug affects the use of libstdc++, too, for what it's worth: .../include/c++/4.0.1/bits/stl_algobase.h: In static member function 'static _OI std::__copy_normal::copy_n(_II, _II, _OI) [with _II = __gnu_cxx::__normal_iterator > >, _OI = __gnu_cxx::__normal_iterator > >]': .../include/c++/4.0.1/bits/stl_algobase.h:387: internal compiler error: in write_template_arg_literal, at cp/mangle.c:2203 .../include/c++/4.0.1/bits/stl_algobase.h: In static member function 'static _OI std::__copy_normal::copy_n(_II, _II, _OI) [with _II = __gnu_cxx::__normal_iterator > >, _OI = __gnu_cxx::__normal_iterator > >]': .../include/c++/4.0.1/bits/stl_algobase.h:387: internal compiler error: in write_template_arg_literal, at cp/mangle.c:2203 .../include/c++/4.0.1/bits/stl_algobase.h: In static member function 'static _OutputIterator std::__fill_n::fill_n(_OutputIterator, _Size, const _Tp&) [with _OutputIterator = const char**, _Size = long unsigned int, _Tp = const char*]': .../include/c++/4.0.1/bits/stl_algobase.h:642: internal compiler error: in write_template_arg_literal, at cp/mangle.c:2203 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23056
[Bug c++/23099] New: [4.0 regression] ICE in build_simple_base_path, at cp/class.c:460
The following test case:
struct Base {
int x;
};
template
struct A {
static const int N = sizeof(static_cast(T()));
};
struct Derived : Base {
A a;
};
gcc 2.95.3: compiles
gcc 3.4.4: compiles
gcc 4.0.1: ICE
b1.cc: In instantiation of 'A':
b1.cc:11: instantiated from here
b1.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:459
gcc-4.1-20050716: ICE
bug.cc: In instantiation of 'A':
bug.cc:11: instantiated from here
bug.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:460
gcc CVS 2005-07-25: ICE
b1.cc: In instantiation of 'A':
b1.cc:11: instantiated from here
b1.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:461
Thanks to mec for uncovering this, and bgibbons for minimizing the
test case.
--
Summary: [4.0 regression] ICE in build_simple_base_path, at
cp/class.c:460
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23099
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dank at kegel dot com 2005-08-01 07:45 --- yup. I hope to try out 'delta' soon. BTW it appears to be x86_64 specific. ppc and pentium didn't seem to show it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug c++/10483] Spurious reference created to integer constant in ternary op
--- Additional Comments From dank at kegel dot com 2005-08-03 05:53 --- Should this be revisited now that gcc-4.x has disallowed ternaries as lvalues? My users are somewhat mystified as to why they need to declare storage for integer constants whose address is never taken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10483
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dank at kegel dot com 2005-08-04 19:18 --- In general, once a ten-line testcase is found, do these get added to the gcc regression testsuite as a matter of course? We would be happy to submit patches to add these to the test suite, but we don't have copyright assignments in. Let us know if we should submit such patches anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug c++/23045] ICE in force_decl_die, at dwarf2out.c:12621
--- Additional Comments From dank at kegel dot com 2005-08-07 06:19 --- And sure enough, gcc-4.1-20050806 fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23045
[Bug c++/22034] [4.1 Regression], ICE on valid, dwarf2
--- Additional Comments From dank at kegel dot com 2005-08-07 06:23 --- Still there in gcc-4.1-20050806. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From dank at kegel dot com 2005-08-22 06:33 --- Yes, Tommy mailed the patch, see http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01195.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From dank at kegel dot com 2005-08-22 06:34 --- I think the patch applies cleanly to gcc-4.0.x; it's so small, seems like the target for this bug ought to be gcc-4.0.2. -- What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dank at kegel dot com 2005-08-29 15:34 --- I think Jim's fold fix/workaround is at http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00371.html I'm using it locally now, and it seems at first glance to get us past this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug bootstrap/22541] Building into empty PREFIX causes broken limits.h to be installed
--- Additional Comments From dank at kegel dot com 2005-09-13 14:31 --- Keating wrote in http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01345.html >Needs a ChangeLog entry, but otherwise OK. > >A key detail that you left out of your patch description is that >SYSTEM_HEADER_DIR is used *only* for fixincludes and similar; it is not actually >put into the compiler. If the path was used in the compiler, this patch would >not be OK, because it would mean the compiler couldn't be moved to a different >place after installation. I haven't looked at the patch again after reading his comment (just saw it now), but I intend to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
