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 t
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 #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
--- 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
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-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
--- 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 #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
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-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,
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
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
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:
--- 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
--- 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 #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 #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
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 #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
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 #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?
--
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
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:
// <<&
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
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
: 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
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=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=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=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=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=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=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=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=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=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=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=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=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
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
mmary: Loop unrolling does not exploit VRP for loop bound
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sco
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=32074
rmal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32186
--- Comment #1 from scovich at gmail dot com 2007-06-02 09:37 ---
It also appears that 'next' is broken and acts like 'step' (enter all
functions), while 'finish' acts like 'continue' (run to completion, barring a
breakpoint).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32186
--- Comment #1 from scovich at gmail dot com 2007-06-06 03:39 ---
Happens on x86_64-unknown-linux-gnu as well, for both 4.2.0 and 4.3 (20070605)
The problem is even worse for 128-bit arithmetic because it has to check two
registers (with associated branches) before making a decision
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32291
: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32292
ed struct inside called function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC targe
--- Comment #2 from scovich at gmail dot com 2007-06-20 17:49 ---
(In reply to comment #1)
> wrapper const &w
>
> You are passing via reference which does not break SRA, just changes the ABI
> and such.
>
> This is a very very hard problem to solve without the
--- Comment #3 from scovich at gmail dot com 2007-06-20 18:22 ---
(In reply to comment #1)
Sorry for the double post, but I just tried creating a wrapper_foo() that
copies the values out of the struct, then passes them on to foo() as scalars.
The problem only appears if foo() gets
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
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
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
--- 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
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
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
--- 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
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-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
--- 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
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 #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(
--- 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_tabl
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=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
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=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).
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 #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=14932
Ryan Johnson changed:
What|Removed |Added
CC||scovich at gmail dot com
--- Comment #16
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!
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 #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
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 #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
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-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
--- 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;
++
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("
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
: 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
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
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
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
--- 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
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 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=45959
Ryan Johnson changed:
What|Removed |Added
CC||scovich at gmail dot com
--- Comment #6
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=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=46143
Ryan Johnson changed:
What|Removed |Added
Attachment #22129|0 |1
is obsolete|
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]'
1 - 100 of 112 matches
Mail list logo
