http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
Bug #: 53016
Summary: memcpy optimization can cause unaligned access on ARM
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
--- Comment #1 from Mikael Pettersson 2012-04-17
08:14:49 UTC ---
Created attachment 27175
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27175
reduced test case
Gets alignment faults with both -mthumb and -marm (+ -march=armv5te -O1) using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53011
Richard Guenther changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680
Paolo Carlini changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #8 from Paolo Carli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #10 from Marc Glisse 2012-04-17
10:22:07 UTC ---
Created attachment 27176
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27176
subscript
This patch (a simple copy of a paragraph from the C front-end) seems sufficient
to add vect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
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=47762
Dominique d'Humieres changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53011
--- Comment #4 from Richard Guenther 2012-04-17
11:00:36 UTC ---
EH cleanup turns a loop nest of two into a single loop with multiple latches
by forwarding through an empty EH region.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53017
Bug #: 53017
Summary: Integer constant not constant enough for vector_size
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52715
Andrey Belevantsev changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53017
Richard Guenther changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49843
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #12 from Marc Glisse 2012-04-17
11:59:12 UTC ---
(In reply to comment #11)
> If it is indeed a copy, you should move the code c-common.c and share it. The
> C-family FEs should share as much code as possible.
I agree on the principle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #13 from Manuel López-Ibáñez 2012-04-17
12:13:02 UTC ---
(In reply to comment #12)
> On the other hand, here I am copying a small block of code in the middle of a
> function. Making just that paragraph common wouldn't make much sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53018
Bug #: 53018
Summary: problem with c++0x
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53018
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53018
--- Comment #2 from Manuel López-Ibáñez 2012-04-17
12:32:35 UTC ---
Jack, please read the link:
http://gcc.gnu.org/bugs/#need
and follow the instructions there.
Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #14 from Marc Glisse 2012-04-17
13:06:40 UTC ---
Created attachment 27178
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27178
subscript 2 (Manuel-compliant)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #15 from Manuel López-Ibáñez 2012-04-17
13:23:11 UTC ---
:) Thanks for making me happy and sorry for being a PITA.
Are you planning to send it to gcc-patches for approval or are you not happy
with it yet?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53011
--- Comment #5 from Richard Guenther 2012-04-17
13:42:56 UTC ---
Author: rguenth
Date: Tue Apr 17 13:42:48 2012
New Revision: 186529
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186529
Log:
2012-04-17 Richard Guenther
PR middle-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53011
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015
--- Comment #2 from brainschrat at gmx dot de 2012-04-17 13:46:29 UTC ---
Ok, thanks for your explanation!
Currently, I have one case that always fails and will try the delta approach.
Manually trying to narrow it down would drive me nuts, but de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
--- Comment #6 from Michael Matz 2012-04-17 13:54:36
UTC ---
Author: matz
Date: Tue Apr 17 13:54:26 2012
New Revision: 186530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186530
Log:
PR tree-optimization/18437
* tree-vectorizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #16 from Marc Glisse 2012-04-17
13:57:05 UTC ---
(In reply to comment #15)
> Are you planning to send it to gcc-patches for approval or are you not happy
> with it yet?
There is the problem of moving the testcases. What svn diff prin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38543
--- Comment #4 from Jason Merrill 2012-04-17
14:11:43 UTC ---
Author: jason
Date: Tue Apr 17 14:11:34 2012
New Revision: 186533
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186533
Log:
PR c++/38543
* pt.c (determine_specializati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50830
--- Comment #10 from Jason Merrill 2012-04-17
14:11:24 UTC ---
Author: jason
Date: Tue Apr 17 14:11:13 2012
New Revision: 186532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186532
Log:
PR c++/50830
* pt.c (convert_template_argu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303
--- Comment #7 from Jason Merrill 2012-04-17
14:11:04 UTC ---
Author: jason
Date: Tue Apr 17 14:10:54 2012
New Revision: 186531
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186531
Log:
PR c++/50303
* pt.c (tsubst_pack_expansion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #17 from Manuel López-Ibáñez 2012-04-17
14:11:03 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > Are you planning to send it to gcc-patches for approval or are you not happy
> > with it yet?
>
> There is the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52977
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #75 from H.J. Lu 2012-04-17 14:47:27
UTC ---
(In reply to comment #74)
> We still have an unresolved issue here: we're effectively reversing the order
> in which the ctors are run across translation units. While explicitly
> undefine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #76 from Paul Pluzhnikov 2012-04-17
15:18:56 UTC ---
(In reply to comment #75)
> Can you provide a testcase?
// foo.h
struct Foo {
Foo(Foo *other) : x(other->x) { }
Foo() : x(42) { }
int x;
private:
Foo(const Foo&);
};
ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38543
Jason Merrill changed:
What|Removed |Added
Target Milestone|4.8.0 |4.7.1
--- Comment #5 from Jason Merrill
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50830
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #77 from H.J. Lu 2012-04-17 15:41:04
UTC ---
I believe .init_array keeps the same order of .ctors within
the same translation unit. The proposed --reverse-init-array
switch will only reverse the order across translation units,
while
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
--- Comment #8 from Martin Jambor 2012-04-17
15:45:47 UTC ---
The last case is caused by IPA-SRA, -fno-ipa-sra helps, I belive. All
pre-requesite patches are committed now so I'll concentrate on this
now and hopefully come up with a patch soon.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
Bug #: 53020
Summary: __atomic_fetch_or doesn't generate `1 insn` variant
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
--- Comment #1 from Yukhin Kirill 2012-04-17
16:23:26 UTC ---
Instead, of single `locked` instruction, it generates:.L2:
movl%eax, %ecx
orl $1, %ecx
lock cmpxchgl %ecx, (%edx)
Similar variant for AND operation:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
Jeffrey Quesnelle changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680
--- Comment #9 from Matt Kline 2012-04-17 16:35:51
UTC ---
Yes it is. Sorry for misclassifying it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
Martin Jambor changed:
What|Removed |Added
CC||bernds at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #18 from Marc Glisse 2012-04-17
16:41:58 UTC ---
(In reply to comment #17)
> > And now I should actually bootstrap and run the testsuite ;-)
> Good luck!
It worked fine, same failures as I got the other day for another patch.
> BTW,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
Mikael Pettersson changed:
What|Removed |Added
CC|mikpe at it dot uu.se |
--- Comment #5 from Mikael Pettersso
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
--- Comment #3 from Yukhin Kirill 2012-04-17
17:00:34 UTC ---
(In reply to comment #2)
> Uh...
>
> Index: config/i386/sync.md
> ===
> --- config/i386/sync.md (revision 186501)
> +++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
--- Comment #6 from Jeffrey Quesnelle 2012-04-17
17:08:22 UTC ---
Hmm, even explicit casts to new void*/char* types doesn't fix it:
const child_t * child3 = (const child_t*)( (const char*)(parentptr) + 4 + size
+ size);
const void* src = (const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #78 from Paul Pluzhnikov 2012-04-17
17:16:10 UTC ---
(In reply to comment #77)
> I believe .init_array keeps the same order of .ctors within
> the same translation unit.
I may be missing something, but I only see a single .ctors entr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53003
--- Comment #2 from paolo at gcc dot gnu.org
2012-04-17 17:20:17 UTC ---
Author: paolo
Date: Tue Apr 17 17:20:02 2012
New Revision: 186541
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186541
Log:
/cp
2012-04-17 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
--- Comment #7 from Mikael Pettersson 2012-04-17
17:27:20 UTC ---
The problem is the fact that you attach explicit child_t/parent_t types to
pointers not aligned accordingly. Casting those typed pointers to void*
doesn't eliminate the implied al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599
--- Comment #3 from paolo at gcc dot gnu.org
2012-04-17 17:20:16 UTC ---
Author: paolo
Date: Tue Apr 17 17:20:02 2012
New Revision: 186541
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186541
Log:
/cp
2012-04-17 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
--- Comment #5 from uros at gcc dot gnu.org 2012-04-17 17:39:12 UTC ---
Author: uros
Date: Tue Apr 17 17:39:06 2012
New Revision: 186543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186543
Log:
PR target/53020
* config/i386/sync.m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
--- Comment #4 from uros at gcc dot gnu.org 2012-04-17 17:35:30 UTC ---
Author: uros
Date: Tue Apr 17 17:35:23 2012
New Revision: 186542
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186542
Log:
PR target/53020
* config/i386/sync.m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53003
--- Comment #3 from paolo at gcc dot gnu.org
2012-04-17 17:45:35 UTC ---
Author: paolo
Date: Tue Apr 17 17:45:25 2012
New Revision: 186544
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186544
Log:
/cp
2012-04-17 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53003
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
Uros Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #79 from Cary Coutant 2012-04-17
18:00:41 UTC ---
(In reply to comment #77)
> I believe .init_array keeps the same order of .ctors within
> the same translation unit. The proposed --reverse-init-array
> switch will only reverse the o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712
--- Comment #4 from Jonathan Nieder 2012-04-17
18:13:08 UTC ---
I am not convinced clang's heuristic is the right one. For example, the
following code trips clang's warning, but the test is still not redundant. The
main advantage of the "enumera
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #80 from H.J. Lu 2012-04-17 18:12:41
UTC ---
(In reply to comment #79)
>
> As Paul noted, this is a moot point in practice for .ctors, since GCC emits
> only a single .ctors entry per TU, but it could be significant for assembly
> co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953
Paolo Carlini changed:
What|Removed |Added
CC|meng at g dot clemson.edu |
--- Comment #2 from Paolo Carlini 2012-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #81 from ccoutant at google dot com 2012-04-17 18:52:11 UTC ---
>> As Paul noted, this is a moot point in practice for .ctors, since GCC emits
>> only a single .ctors entry per TU, but it could be significant for assembly
>> code or for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #82 from H.J. Lu 2012-04-17 19:02:22
UTC ---
(In reply to comment #81)
> Didn't I just do that?
>
Let me ask it again:
The proposed --reverse-init-array switch will only reverse the order across
translation units, while keeping the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52733
--- Comment #2 from Paolo Carlini 2012-04-17
19:03:19 UTC ---
Per se, the issue is now moot because both in mainline and in 4_7-branch we
don't use std::log(2.0) anymore. Still, something may well be flaky, at least
for this specific version of d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52733
--- Comment #3 from Paolo Carlini 2012-04-17
19:26:16 UTC ---
For the record: on Lion things seem in pretty good shape for current gcc-4_7:
builds is fine and std::log(2.0L) also works at any optimization level.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50673
--- Comment #4 from Tobias Burnus 2012-04-17
19:30:38 UTC ---
Author: burnus
Date: Tue Apr 17 19:30:29 2012
New Revision: 186548
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186548
Log:
2012-04-17 Tobias Burnus
PR libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #20 from Tobias Burnus 2012-04-17
19:30:39 UTC ---
Author: burnus
Date: Tue Apr 17 19:30:29 2012
New Revision: 186548
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186548
Log:
2012-04-17 Tobias Burnus
PR libfortra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021
Bug #: 53021
Summary: [4.8 Regression] bootstrap failure on Linux/ia32
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53022
Bug #: 53022
Summary: gimple check fail in gimple_assign_rhs1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021
--- Comment #1 from H.J. Lu 2012-04-17 19:57:44
UTC ---
unique_base_value calls gen_rtx_ADDRESS which overrides
dwarf_file_data created by lookup_filename in dwarf2out.c:
/* Check to see if the file name that was searched on the previous
c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53023
Bug #: 53023
Summary: file_table_last_lookup is used, but never set
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021
--- Comment #2 from rsandifo at gcc dot gnu.org
2012-04-17 20:09:11 UTC ---
Author: rsandifo
Date: Tue Apr 17 20:09:01 2012
New Revision: 186549
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186549
Log:
gcc/
PR bootstrap/53021
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53023
--- Comment #1 from H.J. Lu 2012-04-17 20:19:34
UTC ---
This patch sets file_table_last_lookup:
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 7e2ce58..d5783c2 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -20043,13 +20043,15 @@ lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #83 from ccoutant at google dot com 2012-04-17 20:10:07 UTC ---
>> Didn't I just do that?
>
> Let me ask it again:
>
> The proposed --reverse-init-array switch will only reverse the order across
> translation units, while keeping the sa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #84 from H.J. Lu 2012-04-17 20:28:25
UTC ---
(In reply to comment #83)
>
> Paul suggested to me offline that maybe you're asking about
> translation units with several .ctors or .init_array sections. Since
> that doesn't happen in pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024
Bug #: 53024
Summary: Power of 2 requirement on vector_size not documented
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841
--- Comment #7 from fabien at gcc dot gnu.org 2012-04-17 21:06:52 UTC ---
Created attachment 27180
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27180
return earlier in cp_parser_alias_declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841
--- Comment #8 from fabien at gcc dot gnu.org 2012-04-17 21:08:13 UTC ---
It is related to alias declarations. It seems that we do not recover properly
from a failure in cp_parser_alias_declaration, in the block introduced by this
check: "if (!(fla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #86 from ccoutant at google dot com 2012-04-17 21:09:15 UTC ---
> I have seen codes like:
>
> void (*const init_array []) (void)
> __attribute__ ((section (".init_array"), aligned (sizeof (void * =
> {
> &init_0,
> &init_1,
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #85 from Jan Hubicka 2012-04-17 21:06:55
UTC ---
Just as a quick reminder, the reversed ctor execution order is big performance
problem for C++ Apps inlcuding Mozilla and Chrome ;)
So whatever we do, I would preffer to not have it by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #87 from ccoutant at google dot com 2012-04-17 21:52:12 UTC ---
> Just as a quick reminder, the reversed ctor execution order is big performance
> problem for C++ Apps inlcuding Mozilla and Chrome ;)
> So whatever we do, I would preffer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25943
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712
--- Comment #5 from Manuel López-Ibáñez 2012-04-17
21:27:25 UTC ---
(In reply to comment #4)
> I am not convinced clang's heuristic is the right one. For example, the
> following code trips clang's warning, but the test is still not redundant. T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28492
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #88 from H.J. Lu 2012-04-17 22:15:04
UTC ---
(In reply to comment #86)
> > I have seen codes like:
> >
> > void (*const init_array []) (void)
> > __attribute__ ((section (".init_array"), aligned (sizeof (void * =
> > {
> > &i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Bug #: 53025
Summary: [C++11] noexcept operator depends on copy-elision
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #89 from Taras Glek 2012-04-17 23:58:00
UTC ---
(In reply to comment #87)
> > Just as a quick reminder, the reversed ctor execution order is big
> > performance
> > problem for C++ Apps inlcuding Mozilla and Chrome ;)
> > So whatever
ead model: posix
gcc version 4.8.0 20120417 (experimental) (GCC)
(built, I believe, at revision 186523)
It would take some effort to construct minimal code to reproduce this segfault,
but the following details are available now...
user@host:~$ valgrind /path/to/cc1plus -std=c++11 -O2 -g0 -Wall ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51570
Alexandre Oliva changed:
What|Removed |Added
Summary|[4.7/4.8 Regression] FAIL: |[4.7 Regression] FAIL:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #90 from Paul Pluzhnikov 2012-04-18
00:50:06 UTC ---
(In reply to comment #89)
> Your solution will reverse order of reference of .init_array entries with
> regards to the linker commandline.
>
> Linking translation units A B C, wi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #91 from Taras Glek 2012-04-18 01:27:58
UTC ---
(In reply to comment #90)
>
> Or that you kept the link command fixed, but switching to init_array gave
> you significant speed up, which you don't want to lose?
This.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53026
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
1 - 100 of 105 matches
Mail list logo