https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #5 from Ryan Johnson ---
In an ideal world, C++ would disallow such behavior by default, with a function
attribute of some kind that flags cases where a type change might occur (kind
of like how c++11 assumes `nothrow()` for destructo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #4 from Ryan Johnson ---
Yikes. That explains it, all right.
I never would have thought of an object destroying itself and changing its type
with placement new... I guess it must be subject to the same restrictions as
`delete this`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
--- Comment #1 from Ryan Johnson ---
It appears that multiple calls to different virtual functions of the same
object are not optimized, either (each performs the same load-load-jump
operation).
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Target Milestone: ---
C++ virtual function calls normally require two memory loads followed by an
indirect jump: one load fetches the vtable from the object, another to fetch
the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68859
--- Comment #1 from Ryan Johnson ---
(I would be happy to do some legwork on this if somebody is willing to send a
few pointers by PM. I know the code in gcc/cp/init.c, particularly functions
`perform_member_init` and `sort_mem_initializers` are
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Target Milestone: ---
I am working with a large legacy code base that triggers a huge number of
warnings when compiled with -Wreorder (or -Wall, which enables it).
I am not making any excuses
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Target Milestone: ---
The following code snippet evokes an obviously unhelpful warning:
bug.cpp
template
unsigned long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61991
--- Comment #1 from Ryan Johnson ---
C++14 (N3652 [1]) specifically alters the Standard to state that a thread_local
object with static or constexpr initialization may have a non-trivial
destructor (implying that such a destructor should actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656
--- Comment #3 from Ryan Johnson ---
(In reply to Jason Merrill from comment #2)
> Author: jason
> Date: Tue Apr 28 14:43:59 2015
> New Revision: 222531
>
> URL: https://gcc.gnu.org/viewcvs?rev=222531&root=gcc&view=rev
> Log:
> PR c++/6565
++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Consider the following program compiled with `gcc -std=c++11'
= bug.cpp =
#include
int main(int argc, char *argv[]) {
constexpr bool x = __builtin_constant_p(argc);
std::printf("
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
If a thread_local object is statically initialized---trivial or constexpr
constructor---but has a non-trivial destructor, the destructor will only run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #9 from Ryan Johnson ---
(In reply to Andi Kleen from comment #7)
> You can do many of these things these days with asm goto, however it
> typically requires non-structured control flow (goto labels).
I filed this bug after determinin
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
The C++11 standard adds the "noexcept" specification that lets the programmer
assert that a function does not throw any exceptions (terminating executi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #6 from Ryan Johnson ---
(In reply to Jeremy from comment #5)
> It may not be possible, but perhaps a simpler thing might be for
> the asm() to notionally "return" a single boolean value which
> reflects ONE flag only.
Interesting!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14932
Ryan Johnson changed:
What|Removed |Added
CC||scovich at gmail dot com
--- Comment #16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
--- Comment #20 from Ryan Johnson ---
Hi Martin,
(PM reply because I don't have up-to-date information to file a proper
bug report with)
On 25/11/2013 9:57 AM, jamborm at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1047
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
--- Comment #18 from Ryan Johnson ---
(In reply to Martin Jambor from comment #17)
> The testcase is now shrink-wrapped on ppc64 and x86_64, it is not on
> others such as i?86 because parameter-passing ABI basically prevents
> it. If any of the t
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
The following test case introduces an extra object copy, even though none
should be required:
// <<<--- bug.cpp --->>>
extern
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Return value optimization is not applied when calling a static member function
via an unnamed temporary (value or pointer, it doesn't matter). Calling the
fun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022
--- Comment #3 from Ryan Johnson ---
(In reply to Paolo Carlini from comment #1)
> Please try to reduce the testcase further, no includes. You have a number of
> options here: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
Sorry, I thought
normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
First, apologies for the vague subject line, I really don't know what to call
this bug...
Consider the following test case:
// <<&
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Hi all,
In the testcase below, bar() and baz() perform copy elision as expected, but
blah() does not, in spite of its being functionally identical to baz():
#include
struct foo {
foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288
--- Comment #2 from Ryan Johnson 2012-11-12 21:11:43
UTC ---
(In reply to comment #1)
> Why don't just initialize the variable? It seems simpler than implementing yet
> another special attribute in GCC.
In the original program, the "var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288
Bug #: 55288
Summary: Improve handling/suppression of maybe-uninitialized
warnings
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #3 from Ryan Johnson 2012-04-12 16:39:32
UTC ---
FYI: based on a discussion from quite some time ago [1], it seems that the
Linux kernel folks would be "tickled pink" to have this feature, and discussed
several potential ways to imple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074
--- Comment #5 from Ryan Johnson 2012-03-29 02:46:50
UTC ---
(In reply to comment #4)
> We have __builtin_unreachable() now which should allow for this optimization.
I've been using __builtin_unreachable() for some time now, and it's very nice
f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52637
Bug #: 52637
Summary: ICE producing debug info for c++11 code using
templates/decltype/lambda
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52529
Bug #: 52529
Summary: Compiler rejects template code inconsistently
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
--- Comment #8 from Ryan Johnson 2012-03-07 14:28:29
UTC ---
(In reply to comment #7)
> On Wed, 7 Mar 2012, scovich at gmail dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> >
> > --- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
--- Comment #6 from Ryan Johnson 2012-03-07 13:31:19
UTC ---
(In reply to comment #5)
> On Wed, 12 Oct 2011, scovich at gmail dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> >
> > --- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513
--- Comment #2 from Ryan Johnson 2012-03-07 13:02:50
UTC ---
(In reply to comment #1)
> 4.6 should be broken as well for you?
Oops. I reported wrong in my OP. I've actually been using a home-built 4.6.2
for some time now... and it is the host com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513
Bug #: 52513
Summary: gcc-4.7.0-RC-20120302 fails to build for
i686-pc-cygwin
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52166
Bug #: 52166
Summary: c++0x required to import standard c++ headers?
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
--- Comment #4 from Ryan Johnson 2011-10-12 12:40:25
UTC ---
(In reply to comment #3)
> Well, it's a tree optimization issue. It's simple - the local aggregate f
> escapes the function via the member function call to baz:
>
> :
> foo::baz (&f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
Bug #: 50346
Summary: Function call foils VRP/jump-threading of redundant
predicate on struct member
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50312
Bug #: 50312
Summary: ICE when calling offsetof() illegally on incomplete
template class
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #2 from Ryan Johnson 2011-07-04 20:32:01
UTC ---
(In reply to comment #1)
> Making this work reliably is probably more work than making GCC use the flags
> from more cases from regular C code.
Does that mean each such case would need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
Summary: Inline asm should support input/output of flags
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: inline-asm
Assi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49035
--- Comment #1 from Ryan Johnson 2011-05-18 02:56:23
UTC ---
Update: using __attribute__((noinline)) it is actually possible to force the
compiler to do the right thing, though it makes the code significantly less
readable:
=== example.cpp =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49035
Summary: Avoid setting up stack frame for short, hot code paths
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143
--- Comment #4 from Ryan Johnson 2010-10-22 23:06:53
UTC ---
As I said, the stack smashing was only there to make the behavior consistent.
If the offending stack location happens to contain zero, the bug would go
unnoticed (try adding 'long n[1]'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143
Ryan Johnson changed:
What|Removed |Added
Attachment #22129|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143
Summary: __attribute__((optimize)) emits wrong code
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45968
Summary: ICE: tree code 'template_type_parm' is not supported
in gimple streams with -flto
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45959
Ryan Johnson changed:
What|Removed |Added
CC||scovich at gmail dot com
--- Comment #6
--- Comment #6 from scovich at gmail dot com 2010-05-07 21:20 ---
Aha! The problem is not that gcc fails to emit the proper debug info, it's that
it doesn't always track well which instructions came from which function.
For example, if we compile this toy program:
int
--- Comment #5 from scovich at gmail dot com 2010-05-07 20:12 ---
Belated follow-up: I just tried to use sparc-sun-solaris2.10-gcc-4.4.0 (built
from sources) and it does not emit the DW_AT_call_* debug attributes which gdb
expects in order to unwind inlined functions.
I have searched
--- Comment #4 from scovich at gmail dot com 2010-04-23 23:29 ---
> Try the -i option of addr2line.
Ah, very nice. It turns out I was using a 4.0-series gcc, which according to
gdb's docs doesn't output quite enough debug information to reconstruct inlined
stack traces;
--- Comment #1 from scovich at gmail dot com 2010-04-21 09:29 ---
(In reply to comment #0)
One more way debugging would improve: it would become possible to set
breakpoints in inlined functions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
y: Emit debug info allowing inlined functions to show in
stack traces
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu
--- Comment #1 from scovich at gmail dot com 2010-03-09 01:04 ---
(In reply to comment #0)
> Let's just say this led to extremely frustrating behavior until I decided to
> start digging...
To be more specific, the gcc/as wrapper is generated with:
ORIGINAL_AS
gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC host triplet: i686-pc-cygwin
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301
--- Comment #2 from scovich at gmail dot com 2009-11-27 07:45 ---
I've also run into this. Perhaps the machinery which tracks strict aliasing
(and generates best-effort warnings) could be used here?
... adding this comment instead of filing a duplicate :P
--
scovich at gmai
--- Comment #10 from scovich at gmail dot com 2009-11-17 11:16 ---
(In reply to comment #3)
> the warning is for dead code. Thus this is not a
> wrong-code problem.
Just to verify, does this (and comment #7) mean that the warning is harmless
and can be ignored?
--
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42077
--- Comment #1 from scovich at gmail dot com 2009-11-13 10:35 ---
Hmm.. it seems the final executable depends on mpfr and gmp as well... I could
have sworn the docs said it was a build-time dependency only.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42028
y: trivial
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42028
--- Comment #11 from scovich at gmail dot com 2009-05-13 09:51 ---
> If you allow inline asms to change control flow, even just
> to labels whose address has been taken through &&label, you
> penalize a lot of code which doesn't change the control
> flow, as
--- Comment #9 from scovich at gmail dot com 2009-05-13 07:55 ---
RE: __builtin_expect -- Thanks! It did help quite a bit, even though the
compiler was already emitting not-taken branch hints on its own.
RE: Filing bugs -- I have. This RFE arose out of Bug #40078, which was
triggered
--- Comment #7 from scovich at gmail dot com 2009-05-12 17:01 ---
Isn't __builtin_expect a way to send branch prediction hints? I'm not having
trouble with that AFAIK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
--- Comment #4 from scovich at gmail dot com 2009-05-12 16:36 ---
I'm actually running sparcv9-sun-solaris2.10 (the examples used x86 because
more people know it and its asm is easier to read).
My use case is the following: I'm implementing high-performance synchronization
--- Comment #2 from scovich at gmail dot com 2009-05-12 16:13 ---
Overflow and adc were only examples. Other instructions that set cc, or other
conditions (e.g. parity) would not have that optimization.
Another use is the ability to jump out of an inline asm to handle an uncommon
case
labels.1894(%rip), %rax
jmp *%rax
.p2align 4,,7
.L5:
leaq12(%rsp), %rdx
callhandle_overflow
.L4:
movl12(%rsp), %eax
movq16(%rsp), %rbx
movq24(%rsp), %rbp
addq$32, %rsp
ret
--
Summary:
--- Comment #2 from scovich at gmail dot com 2009-05-09 08:16 ---
Computed gotos can easily make it impossible for the compiler to call
constructors and destructors consistently. This is a major gotcha of computed
gotos for people who have used normal gotos in C++ and expect destructors
--- Comment #2 from scovich at gmail dot com 2009-05-08 23:24 ---
Sorry to bring this back up, but I'm not sure if comments show up in a
meaningful way on closed bugs...
1. where does is it documented that inline asm can't change control flow? I
can't find it in the
D
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40078
--- Comment #3 from scovich at gmail dot com 2009-05-08 11:30 ---
> What|Removed |Added
>
> GCC target triplet|sparc-sun-solaris2.10 |sparc64-sun-solaris2.10
I t
--- Comment #1 from scovich at gmail dot com 2009-05-08 09:38 ---
Sorry, the C code should have been:
long spin(int volatile* ptr) {
long rval=0;
while(*ptr) rval++;
return rval;
}
--
scovich at gmail dot com changed:
What|Removed
possible
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: sparc-sun
--- Comment #4 from scovich at gmail dot com 2008-04-09 15:18 ---
If it's any help, adding some inline asm to the file makes the Sun toolchain
croak on my machine.
SunOS 5.10 Generic_118833-23 sun4v sparc SUNW,Sun-Fire-T200
Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
Solaris
--- Comment #4 from scovich at gmail dot com 2007-12-11 17:27 ---
(In reply to comment #3)
> Note you can declare a specialization of foo::bar which shows that the code
> is really dependent.
>
Duh! That's perfect. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34184
--- Comment #9 from scovich at gmail dot com 2007-11-28 14:20 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Too bad they aren't defined for any machine I've tried so far...
>
> The explanation is very simple: the new macros are implemented only i
--- Comment #7 from scovich at gmail dot com 2007-11-28 01:56 ---
(In reply to comment #2)
> I think this is essentially invalid. Note that now we also have the various
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros:
>
> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined
--- Comment #2 from scovich at gmail dot com 2007-11-23 02:06 ---
Subject: Re: Scope broken for inherited members inside template class?
On 22 Nov 2007 21:03:11 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The issue comes down to if bar is dependent he
ass?
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34184
--- Comment #6 from scovich at gmail dot com 2007-11-16 01:04 ---
(In reply to comment #5)
> Subject: Re: atomic builtins not supported on i686?
>
> On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com
> <[EMAIL PROTECTED]> wrote:
> > > Because the
--- Comment #5 from scovich at gmail dot com 2007-11-16 01:00 ---
Subject: Re: atomic builtins not supported on i686?
On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com
<[EMAIL PROTECTED]> wrote:
> > Because the default arch for i686-linux-gnu is i386.
> Wh
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC host triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
--- Comment #7 from scovich at gmail dot com 2007-08-13 21:10 ---
(In reply to comment #6)
> Sorry, my mistake. I meant readelf -wi (lowercase I).
>
Unfortunately, I recompiled with 4.1 to get on with debugging, and also updated
to 20070810 later that day. Now the bug won'
--- Comment #5 from scovich at gmail dot com 2007-08-10 16:50 ---
Murphy strikes again -- 5 minutes after closing this bug it popped back up in
spite of a clean compile. Apparently `make clean' can change which PC causes
complaints but doesn't necessarily fix t
--- Comment #4 from scovich at gmail dot com 2007-08-10 16:39 ---
The problem comes from adding a member function to a header file and only
recompiling some of the source files that include it (make depend missed
something). It looked like a regression because changing versions of gcc
--- Comment #3 from scovich at gmail dot com 2007-08-10 16:20 ---
Created an attachment (id=14050)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14050&action=view)
Output of readelf -wf
I'm attaching the output of `readelf -wf' This time around some of offendin
nt) b._array[1], (int)
b._array[2]);
printf("A={%d,%d,%d}\n", (int) a._a, (int) a._b, (int) a._c);
return 0;
}
--
Summary: Incorrect code generated for anonymous union
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority:
4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32912
--- Comment #6 from scovich at gmail dot com 2007-07-26 22:51 ---
I've observed several more pieces of code where this bug comes up, and it
always seems to be a case of (a) the compiler duplicating a register to
preserve the value after a 2-operand insn can clobbers the original,
onent: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32870
--- Comment #6 from scovich at gmail dot com 2007-07-11 20:27 ---
(In reply to comment #5)
> SImode moves will be a bit harder, because shufps insn pattern is involved in
> the vector expansion.
IIRC, shufps takes 3 cycles on Core2
(http://www.agner.org/optimize/instruction_tabl
--- Comment #2 from scovich at gmail dot com 2007-07-11 16:37 ---
Regression: gcc-4.1.2 outputs the expected code for all test cases
--
scovich at gmail dot com changed:
What|Removed |Added
--- Comment #1 from scovich at gmail dot com 2007-07-11 16:36 ---
(In reply to comment #0)
> // g++ -mtune=core2 -O3 -S -dp
Oops... that doesn't actually unroll loop() all, though it still peels
loop_few().
Adding -funroll-loops (supposedly enabled by -O3?) unrolls loop(
oop
bound
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC tar
--- Comment #3 from scovich at gmail dot com 2007-07-11 15:10 ---
This bug also causes _mm_cvtsi128_si64x() (which calls
__builtin_ia32_vec_ext_v2di) to emit suboptimal code.
// g++-4.3-070710 -mtune=core2 -O3 -S -dp
#include
long vector2long(__m128i* src) { return _mm_cvtsi128_si64x
--- Comment #2 from scovich at gmail dot com 2007-07-11 15:03 ---
(In reply to comment #1)
> Confirmed, not a regression.
>
Also affects 4.3. Changing target
--
scovich at gmail dot com changed:
What|Removed
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725
--- Comment #2 from scovich at gmail dot com 2007-07-09 23:27 ---
(In reply to comment #1)
> "X" constraint means anything matches. Now why we are ICEing is a bit weird.
I started using it because "g" doesn't seem to allow xmm references.
Fortunately, &q
traint "X"
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32711
inefficient
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC t
--- Comment #3 from scovich at gmail dot com 2007-07-07 14:55 ---
While it's nice that the new optimization framework can eliminate the redundant
IMUL instruction(s), why were they being generated in the first place?
Compiling the simpler foo() without optimizations
d
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
or pointer/ref args
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target tripl
1 - 100 of 112 matches
Mail list logo
