[Bug c++/40694] ICE while building clang
--- Comment #3 from jyasskin at gmail dot com 2009-07-09 00:57 --- It does not reproduce with Ubuntu gcc-4.3. I didn't try 4.4. If anyone cares, I submitted a workaround at http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/IRBuilder.h?r1=75084&r2=75083&pathrev=75084 which may point to the underlying problem. -- jyasskin at gmail dot com changed: What|Removed |Added CC| |jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40694
[Bug c/39284] New: Computed gotos combined too aggressively
The following uses a file "ceval.i" that I'll upload shortly and a nightly
build of gcc-4.4.0-20090223. The file is a version of Python's core
interpretation loop modified to use computed gotos in order to help the
processor's branch predictor do a better job than with a switch statement.
However, gcc combines the computed gotos into only a few instructions,
producing a result nearly as bad as the switch.
The computed gotos are all of the form "goto *next_label;". About half of the
instances counted are reachable, as measured by the asm volatile farther down.
$ grep -c -F 'goto *next_label' ceval.i
256
I compile with -fno-gcse because
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#index-fgcse-646
says it helps and with "--param max-goto-duplication-insns=10" because
Diego Novillo suggested tweaking that parameter.
$ gcc-4.4 -m32 -pthread -fno-strict-aliasing -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fno-gcse --param max-goto-duplication-insns=10 -S -dA
ceval.i -o ceval.s
$ egrep -c 'jmp[[:space:]]*\*' ceval.s
4
I tried to make the common instruction sequence leading up to the indirection
jump shorter by putting an asm volatile before it, but that didn't work. You
can see the result by running:
$ sed 's!goto \*next_label!asm volatile ("/* Computed goto */":::"memory");goto
*next_label!' < ceval.i > ceval-asm.i
$ gcc-4.4 -m32 -pthread -fno-strict-aliasing -g -fwrapv -O3 -fno-gcse --param
max-goto-duplication-insns=10 -S -dA ceval-asm.i -o ceval-asm.s
$ egrep -c 'Computed goto' ceval-asm.s
130
$ egrep -c 'jmp[[:space:]]*\*' ceval-asm.s
4
One of the relevant bits of assembly (search for "Computed goto" in
ceval-asm.s) is:
.L1125:
# basic block 66
.LBE835:
# ../src/Python/ceval.c:1000
.loc 1 1000 0
jmp *-72(%ebp)
.LVL558:
.p2align 4,,7
.p2align 3
.L1433:
# basic block 67
...
# basic block 114
#APP
# 11 "../src/Include/ceval-vm.i" 1
/* Computed goto */
# 0 "" 2
#NO_APP
movl%esi, %ebx
.LVL599:
.p2align 4,,7
.p2align 3
.L484:
# basic block 115
# ../src/Python/ceval.c:1000
.loc 1 1000 0
movl$1, %eax
.LVL600:
movl%ebx, %esi
.LVL601:
jmp .L1125
The documentation for max-goto-duplication-insns says:
The maximum number of instructions to duplicate to a block that jumps to a
computed goto. To avoid O(N^2) behavior in a number of passes, GCC factors
computed gotos early in the compilation process, and unfactors them as late as
possible. Only computed jumps at the end of a basic blocks with no more than
max-goto-duplication-insns are unfactored. The default value is 8.
Since .L1125 and basic block 66 have only a single instruction, the computed
goto should have been unfactored.
$ gcc-4.4 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/dnovillo/perf/sbox/gcc/local.x86_64/src/configure
--prefix=/home/dnovillo/perf/sbox/gcc/local.x86_64/inst
--srcdir=/home/dnovillo/perf/sbox/gcc/local.x86_64/src
--with-gmp=/home/dnovillo/i686 --with-mpfr=/home/dnovillo/i686
--build=i686-pc-linux-gnu --enable-languages=c++,fortran,objc,obj-c++
Thread model: posix
gcc version 4.4.0 20090223 (experimental) (GCC)
--
Summary: Computed gotos combined too aggressively
Product: gcc
Version: 4.4.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=39284
[Bug c/39284] Computed gotos combined too aggressively
--- Comment #1 from jyasskin at gmail dot com 2009-02-23 22:44 --- Created an attachment (id=17354) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17354&action=view) ceval.i -- 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 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 c++/41838] Incorrect "dereferencing pointer '' 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=18908&action=view) File with incorrect strict-aliasing warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41838
[Bug c++/41838] New: Incorrect "dereferencing pointer '' 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 '' does break strict-aliasing rules Triple.i:9: note: initialized from here Line 9 is: if (LHSKind == TwineKind) return static_cast(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 '' 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 c++/41874] New: Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
$ cat test.cc
#include
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++/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 libstdc++/43813] New: vector(3, NULL) fails to compile
---
#include
std::vector v(7, 0);
---
lands on the
template 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: vector(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] vector(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] vector(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> since that's the rule [lib.sequence.reqmts]p9 asks for. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
[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 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 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 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++/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 struct MisplacedDbg;
# 1 "good.cc"
struct Arg;
typedef MisplacedDbg Typedef;
template struct Base {
virtual ~Base() {
}
};
template struct MisplacedDbg : public Base {
};
static MisplacedDbg 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 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++/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
