* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
@ 2010-11-27 16:36 ` danglin at gcc dot gnu.org
2010-11-27 17:28 ` danglin at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: danglin at gcc dot gnu.org @ 2010-11-27 16:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> 2010-11-27 16:33:36 UTC ---
Although the printouts don't show it, the fails are with -fpic.
The non pic versions don't fail.
In the nested-6.c case, it appears the procedure label for the
call to compare from qsort is built incorrectly. As a result,
the test segfaults in libc.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
2010-11-27 16:36 ` [Bug middle-end/46685] " danglin at gcc dot gnu.org
@ 2010-11-27 17:28 ` danglin at gcc dot gnu.org
2010-11-27 18:20 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: danglin at gcc dot gnu.org @ 2010-11-27 17:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #2 from John David Anglin <danglin at gcc dot gnu.org> 2010-11-27 16:53:41 UTC ---
ldo -62(%r30),%r23
bl qsort,%r2
The offset of -62 is misaligned. r23 should point to a plabel.
plabels have to be 4-byte aligned.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
2010-11-27 16:36 ` [Bug middle-end/46685] " danglin at gcc dot gnu.org
2010-11-27 17:28 ` danglin at gcc dot gnu.org
@ 2010-11-27 18:20 ` rguenth at gcc dot gnu.org
2010-11-29 3:18 ` danglin at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2010-11-27 18:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.6.0
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (2 preceding siblings ...)
2010-11-27 18:20 ` rguenth at gcc dot gnu.org
@ 2010-11-29 3:18 ` danglin at gcc dot gnu.org
2010-11-29 4:23 ` danglin at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: danglin at gcc dot gnu.org @ 2010-11-29 3:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
John David Anglin <danglin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.6.0 |---
--- Comment #3 from John David Anglin <danglin at gcc dot gnu.org> 2010-11-29 00:52:05 UTC ---
The regression was introduced in r167085.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (3 preceding siblings ...)
2010-11-29 3:18 ` danglin at gcc dot gnu.org
@ 2010-11-29 4:23 ` danglin at gcc dot gnu.org
2010-11-29 8:25 ` ebotcazou at gcc dot gnu.org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: danglin at gcc dot gnu.org @ 2010-11-29 4:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
John David Anglin <danglin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.6.0
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (4 preceding siblings ...)
2010-11-29 4:23 ` danglin at gcc dot gnu.org
@ 2010-11-29 8:25 ` ebotcazou at gcc dot gnu.org
2010-11-29 12:21 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2010-11-29 8:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|hppa-unknown-linux-gnu |hppa,sparc-unknown-linux-gn
| |u
Status|UNCONFIRMED |NEW
Last reconfirmed| |2010.11.29 06:35:10
CC| |ebotcazou at gcc dot
| |gnu.org, hubicka at gcc dot
| |gnu.org
Host|hppa-unknown-linux-gnu |hppa,sparc-unknown-linux-gn
| |u
Ever Confirmed|0 |1
Build|hppa-unknown-linux-gnu |hppa,sparc-unknown-linux-gn
| |u
--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-29 06:35:10 UTC ---
Same failures on SPARC/Linux.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (5 preceding siblings ...)
2010-11-29 8:25 ` ebotcazou at gcc dot gnu.org
@ 2010-11-29 12:21 ` jakub at gcc dot gnu.org
2010-11-29 12:45 ` ebotcazou at gcc dot gnu.org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-11-29 12:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-29 11:46:28 UTC ---
What is the assembly difference on SPARC Linux? The only difference I see with
a cross compiler to sparc64-linux, both for -O1 -m32 -mptr32 and -O1 -m64 is
.section .text.startup,"ax",@progbits
line added before main, which I don't see how it should break things up.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (6 preceding siblings ...)
2010-11-29 12:21 ` jakub at gcc dot gnu.org
@ 2010-11-29 12:45 ` ebotcazou at gcc dot gnu.org
2010-11-29 15:44 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2010-11-29 12:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-29 11:58:56 UTC ---
> What is the assembly difference on SPARC Linux? The only difference I see with
> a cross compiler to sparc64-linux, both for -O1 -m32 -mptr32 and -O1 -m64 is
> .section .text.startup,"ax",@progbits
> line added before main, which I don't see how it should break things up.
The errors are also visible on SPARC/Solaris. You need -fpic.
FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -Os (test for excess
error\
s)
Excess errors:
/var/tmp//ccC9NwIg.s:27: Error: invalid sections for operation on `.LL3' and
`L\
0^A'
/var/tmp//ccC9NwIg.s:29: Error: invalid sections for operation on `.LL3' and
`L\
0^A'
WARNING: gcc.dg/torture/stackalign/non-local-goto-1.c -Os compilation failed
\
to produce executable
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (7 preceding siblings ...)
2010-11-29 12:45 ` ebotcazou at gcc dot gnu.org
@ 2010-11-29 15:44 ` jakub at gcc dot gnu.org
2010-11-30 22:46 ` [Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic dave at hiauly1 dot hia.nrc.ca
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-11-29 15:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-29 15:17:30 UTC ---
I guess we could do something like:
--- varasm.c.jj 2010-11-29 12:39:07.000000000 +0100
+++ varasm.c 2010-11-29 15:15:53.000000000 +0100
@@ -534,6 +534,15 @@ section *
default_function_section (tree decl, enum node_frequency freq,
bool startup, bool exit)
{
+ /* Force nested functions into the same section as the containing
+ function. */
+ if (decl
+ && DECL_SECTION_NAME (decl) == NULL_TREE
+ && DECL_CONTEXT (decl) != NULL_TREE
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && DECL_SECTION_NAME (DECL_CONTEXT (decl)) == NULL_TREE)
+ return function_section (DECL_CONTEXT (decl));
+
/* Startup code should go to startup subsection unless it is
unlikely executed (this happens especially with function splitting
where we can split away unnecesary parts of static constructors. */
or perhaps instead of changing default_function_section write a wrapper around
it and use it on targets that need it. This will use the same section as the
containing function for nested functions.
On the other side, the above is still broken with
-freorder-blocks-and-partition and I guess even before Honza's change it has
been broken.
Alternatively, we could do something like:
--- gcc/config/sparc/sparc.c.jj 2010-11-26 18:39:04.000000000 +0100
+++ gcc/config/sparc/sparc.c 2010-11-29 15:35:00.727219374 +0100
@@ -1066,8 +1066,13 @@ sparc_expand_move (enum machine_mode mod
are absolutely sure that X is in the same segment as the GOT.
Unfortunately, the flexibility of linker scripts means that we
can't be sure of that in general, so assume that _G_O_T_-relative
- accesses are never valid on VxWorks. */
- if (GET_CODE (operands[1]) == LABEL_REF && !TARGET_VXWORKS_RTP)
+ accesses are never valid on VxWorks.
+ If the label is non-local, it might be placed in a different section
+ from . and movMODE_pic_label_ref patterns require the label and .
+ to be in the same section. */
+ if (GET_CODE (operands[1]) == LABEL_REF
+ && !TARGET_VXWORKS_RTP
+ && !LABEL_REF_NONLOCAL_P (operands[1]))
{
if (mode == SImode)
{
Not sure if even in the current function it could happen that sparc_expand_move
is asked for a label that is in the other partition. I mean something like:
__attribute__((noinline, noclone))
void bar (void *x)
{
asm volatile ("" : : "r" (x) : "memory");
}
__attribute__((noinline, noclone))
void baz (void)
{
asm volatile ("" : : : "memory");
}
__attribute__((noinline, noclone))
int foo (int x)
{
__label__ lab;
if (__builtin_expect (x, 0))
{
lab:
baz ();
return 2;
}
bar (&&lab);
return 1;
}
int
main (void)
{
int x, i;
asm volatile ("" : "=r" (x) : "0" (0));
for (i = 0; i < 1000000; i++)
foo (x);
return 0;
}
first compiled/linked with -O2 -fprofile-generate
-freorder-blocks-and-partition -fpic, then executed, then compiled again with
-O2 -fprofile-use -freorder-blocks-and-partition -fpic. At least on
x86_64-linux the baz () bb is .text.unlikely, while bar (&&lab) is .text
section. Now, I guess this wouldn't assemble on sparc-linux or Solaris, even
before Honza's patch.
In that case we perhaps could look at LABEL_REF's operand (if any, nonlocal
labels probably don't have them) and look at bb flags of its INSN_BLOCK.
Unfortunately, the partitions are only computed during *.bbpart, so this is not
known at expansion time (and in sparc_expand_move we might not even know in
which bb we are going to end up).
So, perhaps we'd just need some splitter for these insns and change them to
something else if the current bb and target LABEL_REF have different partition.
Or simply ammend the second patch above and disable this optimization even for
flag_reorder_blocks_and_partition.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (8 preceding siblings ...)
2010-11-29 15:44 ` jakub at gcc dot gnu.org
@ 2010-11-30 22:46 ` dave at hiauly1 dot hia.nrc.ca
2010-11-30 23:15 ` dave at hiauly1 dot hia.nrc.ca
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dave at hiauly1 dot hia.nrc.ca @ 2010-11-30 22:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2010-11-30 21:52:57 UTC ---
> On the other side, the above is still broken with
> -freorder-blocks-and-partition and I guess even before Honza's change it has
> been broken.
flag_reorder_blocks_and_partition is disabled on pa because we don't
support hot and cold partitioning. Testing you first suggestion.
Dave
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (9 preceding siblings ...)
2010-11-30 22:46 ` [Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic dave at hiauly1 dot hia.nrc.ca
@ 2010-11-30 23:15 ` dave at hiauly1 dot hia.nrc.ca
2010-12-02 8:40 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dave at hiauly1 dot hia.nrc.ca @ 2010-11-30 23:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2010-11-30 22:22:22 UTC ---
On Tue, 30 Nov 2010, John David Anglin wrote:
> > On the other side, the above is still broken with
> > -freorder-blocks-and-partition and I guess even before Honza's change it has
> > been broken.
>
> flag_reorder_blocks_and_partition is disabled on pa because we don't
> support hot and cold partitioning. Testing you first suggestion.
This fixes nested-6.c on hppa-unknown-linux-gnu. Probably fixes
the others.
Dave
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (10 preceding siblings ...)
2010-11-30 23:15 ` dave at hiauly1 dot hia.nrc.ca
@ 2010-12-02 8:40 ` jakub at gcc dot gnu.org
2010-12-02 11:31 ` ebotcazou at gcc dot gnu.org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-02 8:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-02 08:40:08 UTC ---
I'd actually prefer to go with the sparc.c change (probably including
flag_reorder_blocks_and_partition), then hppa could just write its own
function_section hook as a wrapper around default_function_section.
Eric, what do you think? I don't have a working SPARC box around right now, so
can't test it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug middle-end/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (11 preceding siblings ...)
2010-12-02 8:40 ` jakub at gcc dot gnu.org
@ 2010-12-02 11:31 ` ebotcazou at gcc dot gnu.org
2010-12-02 22:33 ` [Bug target/46685] " ebotcazou at gcc dot gnu.org
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2010-12-02 11:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-02 11:30:54 UTC ---
> Alternatively, we could do something like:
> --- gcc/config/sparc/sparc.c.jj 2010-11-26 18:39:04.000000000 +0100
> +++ gcc/config/sparc/sparc.c 2010-11-29 15:35:00.727219374 +0100
> @@ -1066,8 +1066,13 @@ sparc_expand_move (enum machine_mode mod
> are absolutely sure that X is in the same segment as the GOT.
> Unfortunately, the flexibility of linker scripts means that we
> can't be sure of that in general, so assume that _G_O_T_-relative
> - accesses are never valid on VxWorks. */
> - if (GET_CODE (operands[1]) == LABEL_REF && !TARGET_VXWORKS_RTP)
> + accesses are never valid on VxWorks.
> + If the label is non-local, it might be placed in a different section
> + from . and movMODE_pic_label_ref patterns require the label and .
> + to be in the same section. */
> + if (GET_CODE (operands[1]) == LABEL_REF
> + && !TARGET_VXWORKS_RTP
> + && !LABEL_REF_NONLOCAL_P (operands[1]))
> {
> if (mode == SImode)
> {
>
> Not sure if even in current function it could happen that sparc_expand_move
> is asked for a label that is in the other partition. I mean something like:
> __attribute__((noinline, noclone))
> void bar (void *x)
> {
> asm volatile ("" : : "r" (x) : "memory");
> }
>
> __attribute__((noinline, noclone))
> void baz (void)
> {
> asm volatile ("" : : : "memory");
> }
>
> __attribute__((noinline, noclone))
> int foo (int x)
> {
> __label__ lab;
> if (__builtin_expect (x, 0))
> {
> lab:
> baz ();
> return 2;
> }
> bar (&&lab);
> return 1;
> }
>
> int
> main (void)
> {
> int x, i;
> asm volatile ("" : "=r" (x) : "0" (0));
> for (i = 0; i < 1000000; i++)
> foo (x);
> return 0;
> }
>
> first compiled/linked with -O2 -fprofile-generate
> -freorder-blocks-and-partition -fpic, then executed, then compiled again with
> -O2 -fprofile-use -freorder-blocks-and-partition -fpic. At least on
> x86_64-linux the baz () bb is .text.unlikely, while bar (&&lab) is .text
> section. Now, I guess this wouldn't assemble on sparc-linux or Solaris, even
> before Honza's patch.
This testcase just crashes the compiler. :-) But, yes, once the patchlet
Index: config/sparc/sparc.c
===================================================================
--- config/sparc/sparc.c (revision 167365)
+++ config/sparc/sparc.c (working copy)
@@ -9453,6 +9485,7 @@ sparc_file_end (void)
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
allocate_struct_function (decl, true);
+ cfun->is_thunk = 1;
current_function_decl = decl;
init_varasm_status ();
assemble_start_function (decl, name);
is applied, your prediction is verified:
ebotcazou@grobluk:~/obj$ gcc/xgcc -Bgcc -O2 -fprofile-use
-freorder-blocks-and-partition -fpic pr46685.c
/tmp/ccg98MwA.s: Assembler messages:
/tmp/ccg98MwA.s:71: Error: operation combines symbols in different segments
/tmp/ccg98MwA.s:72: Error: operation combines symbols in different segments
> Or simply amend the second patch above and disable this optimization even for
> flag_reorder_blocks_and_partition.
This is good enough I'd think. Testing...
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (12 preceding siblings ...)
2010-12-02 11:31 ` ebotcazou at gcc dot gnu.org
@ 2010-12-02 22:33 ` ebotcazou at gcc dot gnu.org
2010-12-08 1:27 ` danglin at gcc dot gnu.org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2010-12-02 22:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-02 22:33:24 UTC ---
Author: ebotcazou
Date: Thu Dec 2 22:33:16 2010
New Revision: 167395
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167395
Log:
PR target/46685
* config/sparc/sparc.c (can_use_mov_pic_label_ref): New predicate.
(sparc_expand_move): Call it to decide whether to emit the special
mov{si,di}_pic_label_ref patterns.
(sparc_legitimize_pic_address): Call it to decide whether to emit
the regular PIC sequence for labels. Fix long line.
(sparc_file_end): Set is_thunk for the PIC helper.
Added:
trunk/gcc/testsuite/gcc.dg/pr46685.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (13 preceding siblings ...)
2010-12-02 22:33 ` [Bug target/46685] " ebotcazou at gcc dot gnu.org
@ 2010-12-08 1:27 ` danglin at gcc dot gnu.org
2010-12-08 1:56 ` danglin at gcc dot gnu.org
2011-01-03 12:06 ` ebotcazou at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: danglin at gcc dot gnu.org @ 2010-12-08 1:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #13 from John David Anglin <danglin at gcc dot gnu.org> 2010-12-08 01:26:48 UTC ---
Author: danglin
Date: Wed Dec 8 01:26:44 2010
New Revision: 167581
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167581
Log:
PR middle-end/46671
PR target/46685
* config/pa/pa.c (pa_function_section): New function.
(TARGET_ASM_FUNCTION_SECTION): Define.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (14 preceding siblings ...)
2010-12-08 1:27 ` danglin at gcc dot gnu.org
@ 2010-12-08 1:56 ` danglin at gcc dot gnu.org
2011-01-03 12:06 ` ebotcazou at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: danglin at gcc dot gnu.org @ 2010-12-08 1:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
John David Anglin <danglin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #14 from John David Anglin <danglin at gcc dot gnu.org> 2010-12-08 01:55:53 UTC ---
Fixed.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/46685] [4.6 Regression] New stack alignment failures with -fpic
2010-11-27 16:36 [Bug middle-end/46685] New: [4.6 Regression] New stack alignment failures danglin at gcc dot gnu.org
` (15 preceding siblings ...)
2010-12-08 1:56 ` danglin at gcc dot gnu.org
@ 2011-01-03 12:06 ` ebotcazou at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-01-03 12:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685
--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-01-03 12:06:23 UTC ---
Author: ebotcazou
Date: Mon Jan 3 12:06:19 2011
New Revision: 168418
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168418
Log:
Backport from mainline
2010-12-30 Eric Botcazou <ebotcazou@adacore.com>
PR target/47038
* config/sparc/sparc.c (sparc_file_end): Call resolve_unique_section
on the GOT helper if USE_HIDDEN_LINKONCE.
2010-12-02 Eric Botcazou <ebotcazou@adacore.com>
PR target/46685
* config/sparc/sparc.c (can_use_mov_pic_label_ref): New predicate.
(sparc_expand_move): Call it to decide whether to emit the special
mov{si,di}_pic_label_ref patterns.
(sparc_legitimize_pic_address): Call it to decide whether to emit
the regular PIC sequence for labels. Fix long line.
(sparc_file_end): Set is_thunk for the PIC helper.
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/sparc/sparc.c
^ permalink raw reply [flat|nested] 18+ messages in thread