http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #35 from Richard Biener rguenth at gcc dot gnu.org 2013-03-06
08:38:50 UTC ---
Author: rguenth
Date: Wed Mar 6 08:38:46 2013
New Revision: 196487
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196487
Log:
2013-03-06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #24 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05
10:18:01 UTC ---
(In reply to comment #23)
How can the patch cause a name collision when all the patch does is
avoid creating a new decl...? They are static and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05
13:19:53 UTC ---
Btw, I cannot reproduce the issue with
t.c:
void bar (int *);
void foo (void)
{
int a[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2, 3,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #26 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
13:51:28 UTC ---
The question is why we don't hit lto-lang.c:lto_set_decl_assembler_name
mangling of !TREE_PUBLIC decls when streaming in the decl for the constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #27 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 13:58:15 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #26 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #28 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
14:23:19 UTC ---
Hmm, but when I use the same contents for the two arrays in my simple
testcase I do get only a single .LC0 output referenced from two places.
We
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #29 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 14:26:00 UTC ---
On Tue, 5 Mar 2013, rguenther at suse dot de wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #27 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #30 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
14:39:00 UTC ---
So we can revert the part of the patch that ends up not creating
a new decl but only transfer DECL_ALIGN. But then we still don't
merge the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #31 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 15:09:06 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #28 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #32 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
15:32:15 UTC ---
But in all places I found we check TREE_ASM_WRITTEN on DECL_INITIAL
of the SYMBOL_REF_DECL ...
Nope, maybe_output_constant_def_contents has:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #33 from rguenther at suse dot de rguenther at suse dot de
2013-03-05 15:48:03 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #32 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #34 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-05
16:05:44 UTC ---
Created attachment 29587
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29587
Patch to restore LTO bootstrap with Ada + comment tweaks
OK,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #23 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04
16:10:53 UTC ---
How can the patch cause a name collision when all the patch does is
avoid creating a new decl...? They are static and thus should be
mangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #16 from rguenther at suse dot de rguenther at suse dot de
2013-02-14 08:56:12 UTC ---
On Wed, 13 Feb 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #14 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-02-14
09:18:46 UTC ---
Because as it is seen as a regular VAR_DECL by optimizers the
vectorizer (well, IPA increase-alignment in this case) chooses to
bump its
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #18 from rguenther at suse dot de rguenther at suse dot de
2013-02-14 10:41:07 UTC ---
On Thu, 14 Feb 2013, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #17 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #19 from Richard Biener rguenth at gcc dot gnu.org 2013-02-14
12:24:26 UTC ---
Author: rguenth
Date: Thu Feb 14 12:24:12 2013
New Revision: 196050
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196050
Log:
2013-02-14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #11 from rguenther at suse dot de rguenther at suse dot de
2013-02-13 09:05:16 UTC ---
On Tue, 12 Feb 2013, meissner at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #10 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13
10:55:15 UTC ---
Created attachment 29436
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29436
patch
-fsection-anchors enables pass_ipa_increase_alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-02-13
22:13:42 UTC ---
In LTO:
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #15 from Michael Meissner meissner at gcc dot gnu.org 2013-02-13
22:38:12 UTC ---
The patch does align the .rodata section to 16 byte alignment, but the code to
load up the auto vector from constant memory does not do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Michael Meissner meissner at gcc dot gnu.org changed:
What|Removed |Added
Component|target |lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #9 from Michael Meissner meissner at gcc dot gnu.org 2013-02-12
19:07:18 UTC ---
The -fsection-anchors option appears to be important. If I use
-fsection-anchors (which is default for powerpc64-linux), LTO does not align
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #10 from Michael Meissner meissner at gcc dot gnu.org 2013-02-12
19:16:56 UTC ---
If -fno-merge-constants (and the default -fsection-anchors) is used, then the
correct alignment for the table is set (and Altivec memory
30 matches
Mail list logo
