http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636
--- Comment #1 from Stefan Sørensen ---
Created attachment 30318
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30318&action=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 ---
(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 object. You probably
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Dmitry G. Dyachenko changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Tue Jun 18 07:41:19 2013
New Revision: 200163
URL: http://gcc.gnu.org/viewcvs?rev=200163&root=gcc&view=rev
Log:
PR c/57630
* c-decl.c (check_for_loop_decls): Improve diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637
--- Comment #1 from zhenqiang.chen at linaro dot org ---
I had reproduced it on chrome book. It failed due to "alignment exception" for
O3.
I will do more investigation.
If this bug blocks your work, please try "-fno-shrink-wrap" to disable the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #10 from Richard Biener ---
(In reply to Jan Hubicka from comment #6)
> I am testing
> Index: lto-symtab.c
> ===
> --- lto-symtab.c(revision 200151)
> +++ lto-symt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
--- Comment #11 from Richard Biene
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 ---
Created attachment 30319
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30319&action=edit
reduced test case
Still ICEs 4.9-20130616, 4.8-20130613, and 4.7-20130615. Needs -O1 (or higher)
-funroll-lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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 |Ad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617
Nick Maclaren changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403
--- Comment #5 from Nick Maclaren ---
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 ---
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: libstd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #1 from Jonathan Wakely ---
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. Are you seeing the first p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #2 from Hristo Venev ---
Am I very stupid, or is
#include
#include
using Clock=std::chrono::steady_clock;
int main(){
std::timed_mutex m;
m.lock();
Clock::time_point tp=Clock::now()+std::chrono::seconds(2);
if(m.try_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #3 from Jonathan Wakely ---
Testcase using clock with an earlier epoch:
#include
#include
#include
#include
namespace C = std::chrono;
struct clock
{
typedef C::system_clock::rep rep;
typedef C::system_clock::period per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #4 from Jonathan Wakely ---
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 changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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: tre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
--- Comment #1 from Yale Zhang ---
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: libi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609
Jan-Benedict Glaw changed:
What|Removed |Added
CC||jbg...@lug-owl.de
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
Yale Zhang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|i.nixman at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317
Joseph S. Myers changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Joseph S. Myers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |4.8.2
--- Comment #6 from Jonathan Wake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
--- Comment #3 from Manuel López-Ibáñez ---
(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 could do that for me,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
--- Comment #4 from Paolo Carlini ---
No problem, patch sent.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #2 from Martin Liška ---
Works for me, could be marker as fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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: c
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
Se
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647
Bug ID: 57647
Summary: lvalue required as increment operand
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
--- Comment #3 from Andreas Krebbel ---
(In reply to Vladimir Makarov from comment #2)
Thanks! Btw. the Ada and Java bootstraps started failing with enabling LRA for
S/390 (also without --with-arch=...). I'll wait for a patch for this PR before
h
41 matches
Mail list logo
