--- 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&
/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
Sever
--- 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
--- 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:]]*\*&
--- 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
--- 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
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41838
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
oduct: 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/sh
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813
--- 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
--- 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
--- 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
--- 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
--- 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
t gnu dot org
ReportedBy: jyasskin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44244
--- 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
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
--- 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 typ
--- 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 r
: 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
21 matches
Mail list logo
