[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
--- Comment #2 from jyasskin at gmail dot com 2010-07-20 00:43 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01538.html. Please review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
[Bug rtl-optimization/42621] [4.4 Regression] Computed gotos on AMD 800% slower
--- Comment #11 from jyasskin at gmail dot com 2010-07-14 20:49 --- Is this the same bug as PR 39284? -- jyasskin at gmail dot com changed: What|Removed |Added CC||jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
--- Comment #1 from jyasskin at gmail dot com 2010-07-15 00:34 --- My current guess is that the bug is at parser.c:16741, at the end of cp_parser_class_head(): DECL_SOURCE_LOCATION (TYPE_NAME (type)) = type_start_token-location; This updates the template's location, but it doesn't update the locations of any instantiations that have already been created. I'm going to try to find the existing instantiations to update them there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
--- Comment #7 from jyasskin at gmail dot com 2010-07-13 22:56 --- I'm working on a patch for this at http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01116.html. It works by emitting a fake use of the key method any time a translation unit depends on an imported vtable or typeinfo. -- jyasskin at gmail dot com changed: What|Removed |Added CC||jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
[Bug c++/44641] New: Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
$ cat test.ii
# 1 bad.h 1
template class A struct MisplacedDbg;
# 1 good.cc
struct Arg;
typedef MisplacedDbgArg Typedef;
templatetypename T struct Base {
virtual ~Base() {
}
};
template class A struct MisplacedDbg : public Baseint {
};
static MisplacedDbgArg static_var;
$ g++-4.6svn -c -g test.ii
$ objdump -d -l test.o|grep -B2 'bad.h:1'
_ZN12MisplacedDbgI3ArgEC1Ev:
MisplacedDbg():
/home/jyasskin/tmp/bad.h:1
--
_ZN12MisplacedDbgI3ArgED1Ev:
~MisplacedDbg():
/home/jyasskin/tmp/bad.h:1
$
This causes problems for Gold's ODR violation detector.
--
Summary: Generated constructors and destructors get wrong debug
location when a typedef uses a forward declaration of
the type before the definition
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
[Bug c++/44244] Provide -f flags to turn on individual C++0x features
--- Comment #3 from jyasskin at gmail dot com 2010-06-04 17:56 --- Thanks for the prompt answers. I understand that you've picked the right direction for gcc as a whole, even though it'll inconvenience me temporarily. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44244
[Bug c++/44244] New: Provide -f flags to turn on individual C++0x features
Right now, gcc provides --std=c++0x to turn on all the features from C++0x that it's implemented. However, it would be useful for organizations migrating to C++0x to turn on one feature at a time as that feature becomes stable. For example, we might turn on -fenable-c++0x-auto before -fenable-c++0x-lambdas. -- Summary: Provide -f flags to turn on individual C++0x features Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44244
[Bug libstdc++/43813] New: vectorT*(3, NULL) fails to compile
--- #include vector std::vectordouble* v(7, 0); --- lands on the template class InputIterator vector(InputIterator first, InputIterator last, const Allocator = Allocator()); constructor instead of explicit vector(size_type n, const T value = T(), const Allocator = Allocator()); which the user intended. The InputIterator constructor tries to forward to _M_fill_initialize because both arguments are integral, but the 0 has now been permanently bound to the int type, stopping it from converting to a null double*. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1234 indicates that the current behavior is conformant, but that the committee seems to want to require the call to do what the user intended in a future standard. Passing NULL instead of 0 makes the error depend on the build target. For example, NULL appears to be an int on x86-32 but a long on x86-64, meaning the error appears on x86-32 but not on x86-64. -- Summary: vectorT*(3, NULL) fails to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
[Bug libstdc++/43813] [DR1234] vectorT*(3, NULL) fails to compile
--- Comment #4 from jyasskin at gmail dot com 2010-04-20 16:34 --- It seems like a QoI issue until the C++ issue is resolved, since the expected behavior is also allowed by the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
[Bug libstdc++/43813] [DR1234] vectorT*(3, NULL) fails to compile
--- Comment #7 from jyasskin at gmail dot com 2010-04-20 20:04 --- Patch request acknowledged. :) My plan if I do get around to writing it is to use enable_if!is_integralInputIterator since that's the rule [lib.sequence.reqmts]p9 asks for. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
[Bug c++/43105] New: Need documentation for restrictions on programs compiled with mixed -fno-rtti and -frtti
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/C_002b_002b-Dialect-Options.html#index-fno_002drtti-148 doesn't mention any restrictions on compiling programs with some translation units compiled with -frtti, and others compiled with -fno-rtti. Yet there are such restrictions. For example, programs don't link when a -frtti class is derived from a -fno-rtti base class. Any restrictions like that should be documented or fixed. -- Summary: Need documentation for restrictions on programs compiled with mixed -fno-rtti and -frtti Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jyasskin at gmail dot com GCC target triplet: i386-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43105
[Bug c++/41874] New: Incorrect dereferencing type-punned pointer will break strict-aliasing rules warning
$ cat test.cc
#include new
struct APInt {
int i;
};
int main() {
APInt I;
char Data[sizeof(APInt)];
new((void*)Data)APInt();
*(APInt*)Data = I;
}
$ g++ -O3 -Wstrict-aliasing test.cc -o /dev/null
test.cc: In function 'int main()':
test.cc:9: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test.cc:9: warning: dereferencing type-punned pointer will break
strict-aliasing rules
$ g++ -v
Using built-in specs.
Target: i386-apple-darwin9
Configured with: ../gcc-4.4.1/configure --prefix=/opt/local
--build=i386-apple-darwin9 --enable-languages=c,c++,objc,obj-c++,java,fortran
--libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.4.1 (GCC)
The warning goes away if I change *(APInt*)Data = I; to *(APInt*)(void*)Data
= I; even though an extra cast through void* can't improve the situation wrt
strict-aliasing.
--
Summary: Incorrect dereferencing type-punned pointer will break
strict-aliasing rules warning
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
[Bug c++/41838] Incorrect dereferencing pointer 'anonymous' does break strict-aliasing rules
--- Comment #1 from jyasskin at gmail dot com 2009-10-26 23:04 --- Created an attachment (id=18908) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18908action=view) File with incorrect strict-aliasing warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41838
[Bug c++/41838] New: Incorrect dereferencing pointer 'anonymous' does break strict-aliasing rules
The attached Triple.i, when compiled with `g++ -c -O2 -Wstrict-aliasing Triple.i`, returns: Triple.i: In function 'void setOSName(const StringRef)': Triple.i:9: warning: dereferencing pointer 'anonymous' does break strict-aliasing rules Triple.i:9: note: initialized from here Line 9 is: if (LHSKind == TwineKind) return static_castconst Twine *(LHS)-LHSKind; I believe the warning is incorrect since when LHSKind == TwineKind, LHS is only assigned a Twine*. There's no aliasing through the void*. (And in this subprogram, LHSKind is in fact never ==TwineKind.) The warning goes away if I delete the __builtin_expect. $ g++ -v Using built-in specs. Target: i386-apple-darwin9 Configured with: ../gcc-4.4.1/configure --prefix=/opt/local --build=i386-apple-darwin9 --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local Thread model: posix gcc version 4.4.1 (GCC) -- Summary: Incorrect dereferencing pointer 'anonymous' does break strict-aliasing rules Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41838
[Bug middle-end/39284] Computed gotos combined too aggressively
--- Comment #7 from jyasskin at gmail dot com 2009-02-24 15:26 --- I'd like to get gcc not to combine any of them, which I believe would produce 130, as many as the asm volatiles that survived optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
[Bug middle-end/39284] Computed gotos combined too aggressively
--- Comment #4 from jyasskin at gmail dot com 2009-02-23 22:58 --- Taking out -fno-gcse doesn't change the result. $ gcc-4.4 -m32 -pthread -fno-strict-aliasing -g -fwrapv -O3 --param max-goto-duplication-insns=10 -S -dA ceval.i -o ceval.s $ egrep -c 'jmp[[:space:]]*\*' ceval.s 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
[Bug c++/4131] The C++ compiler don't place a const class object to .rodata section with non trivial constructor
--- Comment #22 from jyasskin at gmail dot com 2008-06-11 18:05 ---
This is related to generalized constant expressions
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf) in C++0x.
Those will be marked by the explicit 'constexpr' keyword and will require the
initialization to be done at static rather than dynamic initialization time,
while this bug is about the optional optimization of moving some extra objects
from dynamic to static time.
If I understand it correctly, in C++0x, the following code will require f to be
placed in either the .rodata or .data sections, rather than .bss as it's placed
now.
struct Foo
{
constexpr Foo(int a) { t = a; }
int t;
}
constexpr Foo f(1);
I'd also like to point out that with the extra optimization described here, the
following code could also place f in the .data section:
struct Foo
{
constexpr Foo(int a) { t = a; }
int t;
}
Foo f(1); // Note that f is non-const.
This would be useful for getting atomic variables initialized before anything
else starts up, but it may well belong in a separate feature request.
--
jyasskin at gmail dot com changed:
What|Removed |Added
CC||jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug c++/29939] New: Please implement rvalue references
Rvalue references as described in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html were voted into the C++0x working draft at the 2006 Portland meeting, and I'd like to use them. -- Summary: Please implement rvalue references Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
