http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479
--- Comment #4 from Jakub Jelinek ---
I don't see why do you think nobody would try to look at t[x][y][z] in the
debugger.
Anyway, I think we can do two things here. Obviously we can't give up on
cunrolling it because that would be a clear -fcomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838
--- Comment #10 from Marek Polacek ---
Author: mpolacek
Date: Mon Jan 20 10:42:29 2014
New Revision: 206795
URL: http://gcc.gnu.org/viewcvs?rev=206795&root=gcc&view=rev
Log:
PR c++/59838
cp/
* cvt.c (ocp_convert): Don't segfault on non-ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #8 from algrant at acm dot org ---
I don't see how f can not be 0 or 1 here, but to make this even more clear
that there is no UB, define flag this way:
static std::atomic flag(0);
and calculate the address this way:
d = *(&d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57481
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479
--- Comment #3 from Richard Biener ---
Or rather -fvar-tracking-assignments. The slowness creeps in
trivially dead code : 0.37 (13%) usr 0.00 ( 0%) sys 0.37 (10%) wall
0 kB ( 0%) ggc
complete unrolling : 0.36 (13%) usr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jakub at gcc dot g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 20 09:52:21 2014
New Revision: 206792
URL: http://gcc.gnu.org/viewcvs?rev=206792&root=gcc&view=rev
Log:
PR target/59880
* config/i386/i386.c (ix86_avoid_lea_for_addr): Retu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59868
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
--- Comment #4 from Samuel Tardieu ---
Note that clang has this bug "in reverse": it unifies the arrays even when
recursive calls are possible and address escapes the defining function
(http://llvm.org/bugs/show_bug.cgi?id=18557).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #11 from Richard Biener ---
If double_type_node is FE dependent then it needs treatment in
tree-streamer.c:preload_common_nodes:
static void
preload_common_nodes (struct streamer_tree_cache_d *cache)
{
unsigned i;
for (i = 0; i <
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Component|c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59885
Bug ID: 59885
Summary: compiler issues incorrect "ambiguous base class" error
message
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
--- Comment #2 from Richard Biener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #24 from Eric Botcazou ---
> IMHO a bug that is known for 2.5 years and unfixed shouldn't be all of
> sudden P1. That doesn't mean the maintainers should ignore the bug, just
> that it isn't a release blocker.
I'm afraid that history
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
--- Comment #3 from Richard Biener ---
This is also simply a gimplification issue. For larger arrays we initialize
the stack with an aggregate copy from the constant pool.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757
Joey Ye changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59868
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
Summary|Extr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #7 from Andrew Pinski ---
>*(&data + f - f);
This could be undefined behavior if f is not 0 or 1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #6 from algrant at acm dot org ---
Here is a complete C++11 test case. The code generated for the two loads
in thread B doesn't maintain the required ordering:
...
ldrbw1, [x0]
uxtbw1, w1
adrp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #23 from Jakub Jelinek ---
IMHO a bug that is known for 2.5 years and unfixed shouldn't be all of sudden
P1. That doesn't mean the maintainers should ignore the bug, just that it
isn't a release blocker.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59857
--- Comment #3 from Jacky Ko ---
You are right. ulv is volatile, the typedef in the code is
typedef unsigned int volatile ulv;
I'm sorry that I didn't provide the definition.
I modify the C code as below,
int TEST_Memread(unsigned int * pSrc,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #22 from Eric Botcazou ---
IMO this bug should be moved to P1 as a regression on a primary platform and
the RMs should up the pressure on the maintainers to have it fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
Yury Gribov changed:
What|Removed |Added
CC||y.gribov at samsung dot com
--- Comment #21
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59853
--- Comment #4 from Sylvain Laperche ---
I downloaded the source of GCC 4.8.2 from here[1].
I compiled it with and without --disable-nls, in both case it works fine. I
cannot reproduce the issue I encounter with the the binary from the official
re
101 - 129 of 129 matches
Mail list logo
