http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636
--- Comment #1 from Stefan Sørensen stefan at astylos dot dk ---
Created attachment 30318
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30318action=edit
Simple testcase that triggers the ICE when built with -Os -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
--- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com ---
(In reply to Richard Biener from comment #1)
I don't think it works that way, hidden visibility makes it non-exported from
the dynamic object but it's still visible inside the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Dmitry G. Dyachenko dimhen at gmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Tue Jun 18 07:41:19 2013
New Revision: 200163
URL: http://gcc.gnu.org/viewcvs?rev=200163root=gccview=rev
Log:
PR c/57630
* c-decl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
I am testing
Index: lto-symtab.c
===
--- lto-symtab.c(revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Thanks, Zhenqiang.
For me, it's a segfault in function DGETF2. gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0001d964 in dgetf2_ ()
(gdb) bt
#0 0x0001d964 in dgetf2_ ()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773
--- Comment #6 from Mikael Pettersson mikpe at it dot uu.se ---
Created attachment 30319
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30319action=edit
reduced test case
Still ICEs 4.9-20130616, 4.8-20130613, and 4.7-20130615. Needs -O1 (or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
Bug 57483 depends on bug 57334, which changed state.
Bug 57334 Summary: [4.9 regression] ICE: in input_gimple_stmt, at
gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617
Nick Maclaren nmm1 at cam dot ac.uk changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403
--- Comment #5 from Nick Maclaren nmm1 at cam dot ac.uk ---
Because of the last comment, I am not going to close this as resolved,
invalid, but please do so if appropriate.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
--- Comment #2 from vijay Nag vijunag at gmail dot com ---
With the compiler flag -fno-var-tracking, it compiles in less than a minute.
Although it is quite conspicuous from back-trace I thought it is worth
mentioning this info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Bug ID: 57641
Summary: std::timed_mutex.try_lock_until() is broken
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
I agree that code assumes the epochs are the same, but what you describe
doesn't make sense since high_resolution_clock and steady_clock have the same
epoch in our implementation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #2 from Hristo Venev mustrumr97 at gmail dot com ---
Am I very stupid, or is
#include mutex
#include chrono
using Clock=std::chrono::steady_clock;
int main(){
std::timed_mutex m;
m.lock();
Clock::time_point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Testcase using clock with an earlier epoch:
#include chrono
#include thread
#include mutex
#include assert.h
namespace C = std::chrono;
struct clock
{
typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
It's undefined behaviour because you try to lock the same mutex twice in the
same thread, see my testcase for a well-defined way to do it, calling
try_lock_until in a new thread.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
Bug ID: 57642
Summary: vectorizer not working with function templates
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
--- Comment #1 from Yale Zhang yzhang1985 at gmail dot com ---
I would like to know if there's an easy work around for this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643
Bug ID: 57643
Summary: libitm.c/reentrant.c hangs on POWER8 with HTM
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609
Jan-Benedict Glaw jbg...@lug-owl.de changed:
What|Removed |Added
CC||jbg...@lug-owl.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
Yale Zhang yzhang1985 at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317
Joseph S. Myers jsm28 at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.2
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #2)
Patch works great for me and passes testing. Are you going to submit it? In
fact, I don't think you really need an approval.
If you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
No problem, patch sent.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #2 from Martin Liška marxin.liska at gmail dot com ---
Works for me, could be marker as fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644
Bug ID: 57644
Summary: [C++1y] Cannot bind bitfield to lvalue reference
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645
Bug ID: 57645
Summary: Explicitly-declared destructor with no exception
specification is always noexcept(true)
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57646
Bug ID: 57646
Summary: bogus warning about uninitialized ‘saved_stack.1’ with
gotos and VLAs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
38 matches
Mail list logo
