https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786
dank at kegel dot com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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 |Add
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
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.
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
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
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 thr
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
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 #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 b
--- 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
--- 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 c
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
--- 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
--- 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
--- 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
--- 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.
--- 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 portabili
--- 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
--- 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
--- 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
--- 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.or
--- 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 |
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
rity: 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
--- 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
--- 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
--- 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
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
--- 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,
_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-bug
FIRMED
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
--- 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
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
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
--- 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
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
Reported
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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;
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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 ar
--- 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 do
--- 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
load.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 d
--- 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
--- 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
NCONFIRMED
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_
--- 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
--- 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
--- 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
"-fr
--- 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
--- 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
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
--- 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
--
What|Removed |Added
CC||dank at kegel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
--- 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
--
What|Removed |Added
Component|c++ |preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19027
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
--- 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_fram
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 do
79 matches
Mail list logo
