https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70991
--- Comment #2 from bennet brauer ---
By the way, this bug mentions classes specifically, because the same idea but
with a simple "int" assignment generates a warning:
error: ‘foo’ is used uninitialized in this function [-Werror=uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70991
--- Comment #1 from bennet brauer ---
Created attachment 38433
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38433=edit
two similar test cases in one cpp file
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: appfault at hotmail dot com
Target Milestone: ---
g++ allows uninitialized class to be used for member variables (hitting
uninitialized memory), if the class
: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42733
--- Comment #1 from appfault at hotmail dot com 2010-01-13 17:56 ---
Created an attachment (id=19577)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19577action=view)
code to reproduce
Strangely double-forking seems to also make this go away. I can't find any
previous zilla
--- Comment #3 from appfault at hotmail dot com 2010-01-13 18:30 ---
#0 __gnu_cxx::__exchange_and_add (__mem=0xb3e005a8, __val=-1) at
atomicity.cc:58
#1 0x0804957f in std::string::reserve (this=0xbfffbe20, __res=3017803168) at
basic_string.h:217
#2 0x08049aa2 in std::string::append
--- Comment #5 from appfault at hotmail dot com 2010-01-13 18:50 ---
I see that it's auto-generated, but when I did so the file was only 53 lines
long. The function is assembler anyway, so I'm not sure the line numbers would
mean much.
As far as the asm goes, it loops between offsets
--- Comment #6 from appfault at hotmail dot com 2010-01-13 18:52 ---
How could this be marked resolved when no one has even speculated on what the
fix could be? It may still be broken, but more difficult to repro for some
reason.
--
appfault at hotmail dot com changed
--- Comment #8 from appfault at hotmail dot com 2010-01-13 20:07 ---
Is there already a test case somewhere else to ensure that pthread_atfork and
such works?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42733
--- Comment #10 from appfault at hotmail dot com 2010-01-13 21:09 ---
I didn't mean a test that the pthread_atfork() call works at the pthread layer,
but that GCC's use of pthread_atfork() etc was appropriate, given GCC's use of
pthread_mutex.
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from appfault at hotmail dot com 2008-11-04 23:47 ---
Reopen to at least consider comment 7.
--
appfault at hotmail dot com changed:
What|Removed |Added
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35278
--- Comment #7 from appfault at hotmail dot com 2007-12-06 17:26 ---
Instead of trying to lock down the full and complete list of acceptable glibs,
you could at least give a hint as to what GCC was using at the time a given
release did work.
A known working version list seems very
--- Comment #12 from appfault at hotmail dot com 2007-09-24 17:48 ---
Due to lack of responsiveness, a separate Bug 33394 was opened for the missing
test case. Verified this is generically in concept a duplicate of bug 21334,
although the technical details are in fact not the same
: appfault at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33394
--- Comment #11 from appfault at hotmail dot com 2007-07-09 23:21 ---
I've been unable to reproduce any issues in 3.4.6, even with tests that do not
rely on the empty string. I suspect there is something more specific that was
fixed somewhere between 3.3.x and 3.4.6.
It doesn't seem
--- Comment #9 from appfault at hotmail dot com 2007-06-25 23:41 ---
So does this being marked dupe of bug 21334 mean that as long as string (not
ext/vstring.h) is in use, that std::string is subject to other possible race
conditions, even if the original test case succeeds in gcc 3.4.x
--- Comment #4 from appfault at hotmail dot com 2007-06-13 17:38 ---
Yes in addition to the issue of adding a test case, it is quite unsettling to
not know what might have fixed it. Reopening pending response to comment 2 and
comment 3.
--
appfault at hotmail dot com changed
--- Comment #5 from appfault at hotmail dot com 2007-06-13 17:56 ---
Ok well, I'll take your word on that, since I can't really tell where gcc and
ld end and glibc begins. It's perhaps glibc that is in need of better
documentation then. However if I file such a zilla I suspect
--- Comment #2 from appfault at hotmail dot com 2007-06-11 16:01 ---
I wouldn't consider the bugzilla itself to be fixed until a regression test has
been added to the gcc test suite.
Can you confirm that this test case has been added to the gcc regression test
suite? I searched
--- Comment #3 from appfault at hotmail dot com 2007-06-11 16:35 ---
Well here's one example:
http://foo-projects.org/pipermail/lunar-dev/2006-July/005821.html is the error
you get when bootstrapping using binutils 2.17 with gcc 3.4.6 and glibc 2.3.6.
Reverting to binutils 2.15 fixes
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com
GCC host triplet: 2.4.21-32.ELsmp #1 SMP Fri Apr 15 21:17:59 EDT 2005 i686
i686 i3
http://gcc.gnu.org
: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32263
--- Comment #5 from appfault at hotmail dot com 2006-06-06 18:20 ---
Created an attachment (id=11611)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11611action=view)
test case
Attaching relatively bare-bones test case. It could perhaps be whittled down a
bit more
with -O
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com
http://gcc.gnu.org/bugzilla
--- Comment #1 from appfault at hotmail dot com 2006-06-05 01:14 ---
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release
--- Comment #3 from appfault at hotmail dot com 2006-06-05 01:48 ---
Yeah - the website wouldn't let me uploaded it at first cause it was too large.
So I decided I'd get a script running to strip down the lines of the file to
get a bare-bones repro case. It should be complete
--- Comment #25 from appfault at hotmail dot com 2005-11-06 07:26 ---
How does stopping violate the standard? If the standard says behavior is
undefined, then you can do anything you want, including stopping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
--- Additional Comments From appfault at hotmail dot com 2005-09-14 16:09
---
Ok, so that's the best code it can generate, fine. So if instant segfault is
the best possible generated code, I think NOT generating any code is far more
helpful to the user. If not generating any code
--- Additional Comments From appfault at hotmail dot com 2005-09-15 04:22
---
Yes well I don't think you should have to go out of your way to ask the
compiler to not generate invalid code. Not generating invalid code should be
the default behavior.
We're talking about the difference
--- Additional Comments From appfault at hotmail dot com 2005-09-14 00:16
---
Ok, disregard comment 16, the issue I saw was the same as comment 0.
Unfortunately, there was a '-w' sneakily in a 3rd-party makefile which hid the
warning. Maybe I should open another zilla for warning
--- Additional Comments From appfault at hotmail dot com 2005-09-12 23:34
---
Oh? I had -Werror on, and was not getting any warning at all from my code that
was generating 'int $0x5' with gcc 3.4.1. It's perhaps a slightly different
case than comment 0, because I was casting an int
--- Additional Comments From appfault at hotmail dot com 2005-09-11 08:04
---
Invalid? So whenever behavior is undefined by the C standard, would it be ok
to delete the user's harddrive as well? This is ridiculous - fix the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From appfault at hotmail dot com 2005-08-16 20:03
---
I compiled 4.0.1 using 'make bootstrap' and the make and install succeeded.
I'm not certain whether the symbols in libstdc++.a are correct. I tried
running 'nm' on various files, but GNU nm seems
--- Additional Comments From appfault at hotmail dot com 2005-08-17 00:14
---
Ok, well that's good to know. I didn't find anything to say that AIX wasn't
supported.
I've moved the GNU binutils, rm'd my gcc-4.0.1-build and am now trying make
bootstrap again.
On the box
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-ibm
--- Additional Comments From appfault at hotmail dot com 2005-08-15 21:07
---
Created an attachment (id=9500)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9500action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23406
37 matches
Mail list logo
