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
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
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
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
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 scovich at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656
--- Comment #3 from Ryan Johnson scovich at gmail dot com ---
(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=222531root=gccview=rev
Log
++
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 cstdio
int main(int argc, char *argv[]) {
constexpr bool x = __builtin_constant_p(argc);
std::printf(x=%d\n, x
: 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 scovich at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #6 from Ryan Johnson scovich at gmail dot com ---
(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
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 execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14932
Ryan Johnson scovich at gmail dot com changed:
What|Removed |Added
CC||scovich at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
--- Comment #18 from Ryan Johnson scovich at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
--- Comment #20 from Ryan Johnson scovich at gmail dot com ---
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
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
function
: 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 C void puts(char const
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:
// --- begin bug.cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022
--- Comment #3 from Ryan Johnson scovich at gmail dot com ---
(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
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 cstdio
struct foo
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288
--- Comment #2 from Ryan Johnson scovich at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #3 from Ryan Johnson scovich at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074
--- Comment #5 from Ryan Johnson scovich at gmail dot com 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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513
--- Comment #2 from Ryan Johnson scovich at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
--- Comment #6 from Ryan Johnson scovich at gmail dot com 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 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
--- Comment #8 from Ryan Johnson scovich at gmail dot com 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 from
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
--- Comment #4 from Ryan Johnson scovich at gmail dot com 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
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 scovich at gmail dot com 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
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
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=49035
--- Comment #1 from Ryan Johnson scovich at gmail dot com 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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143
Ryan Johnson scovich at gmail dot com changed:
What|Removed |Added
Attachment #22129|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143
--- Comment #4 from Ryan Johnson scovich at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45959
Ryan Johnson scovich at gmail dot com changed:
What|Removed |Added
CC||scovich at gmail
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
--- 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 #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 volatile
--- 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; 4.1 and later do
in
stack traces
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
--- 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
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 #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_FOR_TARGET
--- 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 gmail dot
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 #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?
--
http
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 #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
--- 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 #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 the compiler will have
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
--- 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
--- 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
primitives
--- 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 #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
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 #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
--- 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 think
at gmail dot com
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40078
--- 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 info pages, nor
--- 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 Link
--- 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 fooT::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 in
mainline
(would be 4.3.0
--- 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-Macros.html
--- 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 here and if so
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
: 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 #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.
Which is a stupid
--- 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 default arch for i686-linux-gnu
--- 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't cooperate
--- 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=14050action=view)
Output of readelf -wf
I'm attaching the output of `readelf -wf' This time around some of offending PC
are 0x41ac8c
--- 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 the problem
--- 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
: 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
code generated for anonymous union
Product: gcc
Version: 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
: 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
org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32870
--- 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 |Added
--- 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 emmintrin.h
long vector2long(__m128i* src) { return
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 target triplet
--- 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()
Adding
--- 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 #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_tables.pdf
: 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
Status: UNCONFIRMED
Severity: enhancement
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=32708
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
--- 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, xm seems to have the desired effect
--- 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 gives
dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32660
--- Comment #1 from scovich at gmail dot com 2007-07-06 23:11 ---
Oops.. forgot to include the error message
g++ -Wall -msse3 -O3 -S union-bug.C
union-bug.C: In function long int foo(long long int __vector__):
union-bug.C:4: error: unrecognizable insn:
(insn 12 7 13 0 (set (reg:DI 61
1 - 100 of 112 matches
Mail list logo
