* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
@ 2011-01-08 7:16 ` hjl.tools at gmail dot com
2011-01-08 14:01 ` [Bug lto/47222] New: " Jan Hubicka
` (13 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2011-01-08 7:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-08 04:59:40 UTC ---
It failed with the Linux binutils 2.21.51.0.5 and hjl/lto-mixed branch at
http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
2011-01-08 7:16 ` [Bug lto/47222] " hjl.tools at gmail dot com
@ 2011-01-08 14:01 ` Jan Hubicka
2011-01-08 14:38 ` [Bug lto/47222] " hubicka at ucw dot cz
` (12 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: Jan Hubicka @ 2011-01-08 14:01 UTC (permalink / raw)
To: hjl.tools at gmail dot com; +Cc: gcc-bugs
> One failure is
>
> /tmp/ccJSP9PV.lto.o: In function `main':^M
> ccWUIi0z.o:(.text.startup+0x1d): undefined reference to `g_ebp_save'^M
> ccWUIi0z.o:(.text.startup+0x23): undefined reference to `g_esp_save'^M
> ccWUIi0z.o:(.text.startup+0x3b): undefined reference to `g_edi'^M
> ccWUIi0z.o:(.text.startup+0x41): undefined reference to `g_esi'^M
> ccWUIi0z.o:(.text.startup+0x47): undefined reference to `g_ebx'^M
> ccWUIi0z.o:(.text.startup+0x4d): undefined reference to `g_ebp'^M
> ccWUIi0z.o:(.text.startup+0x53): undefined reference to `g_esp'^M
> collect2: ld returned 1 exit status^M
Hmm, this does not seem to be dependent on plugin implementation, but it seems like
bug in 32bit only testcase. The testcase seems to use:
int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
int g_ebp, g_ebp_save, g_esp, g_esp_save;
int n_error;
and
__asm__ __volatile__ (
"movl %ebp," ASMNAME("g_ebp_save")"\n\t"
"movl %esp," ASMNAME("g_esp_save")"\n\t"
);
I guess either g_ebp_save needs externally_visible attribute or the asm
statement needs to be modified to use g_ebp_save as an destination.
I think this testcase is "yours", so perhaps you can fix it?
Was there some reason to use the ASMNAME hack instead of memory output constraint?
Thanks,
Honza
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
2011-01-08 7:16 ` [Bug lto/47222] " hjl.tools at gmail dot com
2011-01-08 14:01 ` [Bug lto/47222] New: " Jan Hubicka
@ 2011-01-08 14:38 ` hubicka at ucw dot cz
2011-01-08 18:22 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: hubicka at ucw dot cz @ 2011-01-08 14:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-08 13:43:27 UTC ---
> One failure is
>
> /tmp/ccJSP9PV.lto.o: In function `main':^M
> ccWUIi0z.o:(.text.startup+0x1d): undefined reference to `g_ebp_save'^M
> ccWUIi0z.o:(.text.startup+0x23): undefined reference to `g_esp_save'^M
> ccWUIi0z.o:(.text.startup+0x3b): undefined reference to `g_edi'^M
> ccWUIi0z.o:(.text.startup+0x41): undefined reference to `g_esi'^M
> ccWUIi0z.o:(.text.startup+0x47): undefined reference to `g_ebx'^M
> ccWUIi0z.o:(.text.startup+0x4d): undefined reference to `g_ebp'^M
> ccWUIi0z.o:(.text.startup+0x53): undefined reference to `g_esp'^M
> collect2: ld returned 1 exit status^M
Hmm, this does not seem to be dependent on plugin implementation, but it seems
like
bug in 32bit only testcase. The testcase seems to use:
int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
int g_ebp, g_ebp_save, g_esp, g_esp_save;
int n_error;
and
__asm__ __volatile__ (
"movl %ebp," ASMNAME("g_ebp_save")"\n\t"
"movl %esp," ASMNAME("g_esp_save")"\n\t"
);
I guess either g_ebp_save needs externally_visible attribute or the asm
statement needs to be modified to use g_ebp_save as an destination.
I think this testcase is "yours", so perhaps you can fix it?
Was there some reason to use the ASMNAME hack instead of memory output
constraint?
Thanks,
Honza
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (2 preceding siblings ...)
2011-01-08 14:38 ` [Bug lto/47222] " hubicka at ucw dot cz
@ 2011-01-08 18:22 ` hjl.tools at gmail dot com
2011-01-08 18:54 ` hjl.tools at gmail dot com
` (10 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2011-01-08 18:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-08 18:07:00 UTC ---
I got the same failure with gold:
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-flto-partition=none execution test
FAIL: g++.dg/torture/stackalign/unwind-0.C -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-0.C -O2 -flto (test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-1.C -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-1.C -O2 -flto (test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -flto (test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-3.C -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-3.C -O2 -flto (test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-4.C -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-4.C -O2 -flto (test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-5.C -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-5.C -O2 -flto (test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-6.C -O2 -flto -flto-partition=none
(test for excess errors)
FAIL: g++.dg/torture/stackalign/unwind-6.C -O2 -flto (test for excess errors)
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (3 preceding siblings ...)
2011-01-08 18:22 ` hjl.tools at gmail dot com
@ 2011-01-08 18:54 ` hjl.tools at gmail dot com
2011-01-08 18:58 ` Jan Hubicka
2011-01-08 18:58 ` hubicka at ucw dot cz
` (9 subsequent siblings)
14 siblings, 1 reply; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2011-01-08 18:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-08 18:20:58 UTC ---
(In reply to comment #2)
>
> Hmm, this does not seem to be dependent on plugin implementation, but it seems
> like
> bug in 32bit only testcase. The testcase seems to use:
>
> int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
> int g_ebp, g_ebp_save, g_esp, g_esp_save;
> int n_error;
>
> and
>
> __asm__ __volatile__ (
> "movl %ebp," ASMNAME("g_ebp_save")"\n\t"
> "movl %esp," ASMNAME("g_esp_save")"\n\t"
> );
>
> I guess either g_ebp_save needs externally_visible attribute or the asm
> statement needs to be modified to use g_ebp_save as an destination.
I tried
diff --git a/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h
b/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h
index b07b27c..ff56027 100644
--- a/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h
+++ b/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h
@@ -47,8 +47,13 @@ copy (char *p, int size)
__builtin_strncpy (p, "good", size);
}
-int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
-int g_ebp, g_ebp_save, g_esp, g_esp_save;
+int g_edi __attribute__((externally_visible)) =INIT_EDI;
+int g_esi __attribute__((externally_visible)) =INIT_ESI;
+int g_ebx __attribute__((externally_visible)) = INIT_EBX;
+int g_ebp __attribute__((externally_visible));
+int g_esp __attribute__((externally_visible));
+int g_ebp_save __attribute__((externally_visible));
+int g_esp_save __attribute__((externally_visible));
int n_error;
int
and it doesn't make a difference.
> I think this testcase is "yours", so perhaps you can fix it?
> Was there some reason to use the ASMNAME hack instead of memory output
> constraint?
We want to verify the contents of registers.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 18:54 ` hjl.tools at gmail dot com
@ 2011-01-08 18:58 ` Jan Hubicka
0 siblings, 0 replies; 19+ messages in thread
From: Jan Hubicka @ 2011-01-08 18:58 UTC (permalink / raw)
To: hjl.tools at gmail dot com; +Cc: gcc-bugs
> I tried
> -int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
> -int g_ebp, g_ebp_save, g_esp, g_esp_save;
> +int g_edi __attribute__((externally_visible)) =INIT_EDI;
> +int g_esi __attribute__((externally_visible)) =INIT_ESI;
> +int g_ebx __attribute__((externally_visible)) = INIT_EBX;
> +int g_ebp __attribute__((externally_visible));
> +int g_esp __attribute__((externally_visible));
> +int g_ebp_save __attribute__((externally_visible));
> +int g_esp_save __attribute__((externally_visible));
Weird, for me it seems to work as expected:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[1]# cat t.c
__attribute__ ((externally_visible))
int a;
main()
{
asm("movl %eax, a");
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t2.c
int a;
main()
{
asm("movl %eax, a");
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t2.c -flto
/abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: /tmp/ccP7Lfjk.ltrans0.ltrans.o: in function main:ccP7Lfjk.ltrans0.o(.text.startup+0x3): error: undefined reference to 'a'
collect2: ld returned 1 exit status
Perhaps some extra var needs annotation?
> int n_error;
>
> int
>
> and it doesn't make a difference.
>
> > I think this testcase is "yours", so perhaps you can fix it?
> > Was there some reason to use the ASMNAME hack instead of memory output
> > constraint?
>
> We want to verify the contents of registers.
Still, I think the cleanest way is:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t3.c
int a;
main()
{
asm __volatile__ ("movl %%eax, %0":"=m"(a));
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t3.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]#
It avoids the ASMNAME hack and makes outputs explicit.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (4 preceding siblings ...)
2011-01-08 18:54 ` hjl.tools at gmail dot com
@ 2011-01-08 18:58 ` hubicka at ucw dot cz
2011-01-09 17:10 ` hjl.tools at gmail dot com
` (8 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: hubicka at ucw dot cz @ 2011-01-08 18:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-08 18:54:30 UTC ---
> I tried
> -int g_edi=INIT_EDI, g_esi=INIT_ESI, g_ebx=INIT_EBX;
> -int g_ebp, g_ebp_save, g_esp, g_esp_save;
> +int g_edi __attribute__((externally_visible)) =INIT_EDI;
> +int g_esi __attribute__((externally_visible)) =INIT_ESI;
> +int g_ebx __attribute__((externally_visible)) = INIT_EBX;
> +int g_ebp __attribute__((externally_visible));
> +int g_esp __attribute__((externally_visible));
> +int g_ebp_save __attribute__((externally_visible));
> +int g_esp_save __attribute__((externally_visible));
Weird, for me it seems to work as expected:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[1]# cat t.c
__attribute__ ((externally_visible))
int a;
main()
{
asm("movl %eax, a");
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t2.c
int a;
main()
{
asm("movl %eax, a");
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t2.c -flto
/abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld:
/tmp/ccP7Lfjk.ltrans0.ltrans.o: in function
main:ccP7Lfjk.ltrans0.o(.text.startup+0x3): error: undefined reference to 'a'
collect2: ld returned 1 exit status
Perhaps some extra var needs annotation?
> int n_error;
>
> int
>
> and it doesn't make a difference.
>
> > I think this testcase is "yours", so perhaps you can fix it?
> > Was there some reason to use the ASMNAME hack instead of memory output
> > constraint?
>
> We want to verify the contents of registers.
Still, I think the cleanest way is:
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t3.c
int a;
main()
{
asm __volatile__ ("movl %%eax, %0":"=m"(a));
}
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t3.c -flto
evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]#
It avoids the ASMNAME hack and makes outputs explicit.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (5 preceding siblings ...)
2011-01-08 18:58 ` hubicka at ucw dot cz
@ 2011-01-09 17:10 ` hjl.tools at gmail dot com
2011-01-09 17:19 ` Jan Hubicka
2011-01-09 17:20 ` hubicka at ucw dot cz
` (7 subsequent siblings)
14 siblings, 1 reply; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2011-01-09 17:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-09 16:20:35 UTC ---
(In reply to comment #5)
>
> Still, I think the cleanest way is:
> evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# cat t3.c
> int a;
> main()
> {
> asm __volatile__ ("movl %%eax, %0":"=m"(a));
> }
> evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 t3.c -flto
> evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]#
>
> It avoids the ASMNAME hack and makes outputs explicit.
I will take a look. But it still leaves:
FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 12 arg1 == 1
FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 14 arg1 == 1
FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 12 arg1
== 1
FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 14 arg1
== 1
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-flto-partition=none execution test
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
-flto-partition=none execution test
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-09 17:10 ` hjl.tools at gmail dot com
@ 2011-01-09 17:19 ` Jan Hubicka
0 siblings, 0 replies; 19+ messages in thread
From: Jan Hubicka @ 2011-01-09 17:19 UTC (permalink / raw)
To: hjl.tools at gmail dot com; +Cc: gcc-bugs
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
>
> I will take a look. But it still leaves:
>
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 12 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 14 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 12 arg1
> == 1
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 14 arg1
> == 1
This is probably another case of unwanted optimization. It does not seem to reproduce
for me in 64bit mode, I will check 32bit.
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> -flto-partition=none execution test
What kind of failures are you getting here?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (6 preceding siblings ...)
2011-01-09 17:10 ` hjl.tools at gmail dot com
@ 2011-01-09 17:20 ` hubicka at ucw dot cz
2011-01-09 18:06 ` hjl.tools at gmail dot com
` (6 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: hubicka at ucw dot cz @ 2011-01-09 17:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-09 17:10:51 UTC ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
>
> I will take a look. But it still leaves:
>
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 12 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 14 arg1 == 1
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 12 arg1
> == 1
> FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 14 arg1
> == 1
This is probably another case of unwanted optimization. It does not seem to
reproduce
for me in 64bit mode, I will check 32bit.
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> -flto-partition=none execution test
> FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> -flto-partition=none execution test
What kind of failures are you getting here?
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (7 preceding siblings ...)
2011-01-09 17:20 ` hubicka at ucw dot cz
@ 2011-01-09 18:06 ` hjl.tools at gmail dot com
2011-01-09 18:11 ` Jan Hubicka
2011-01-09 18:12 ` hubicka at ucw dot cz
` (5 subsequent siblings)
14 siblings, 1 reply; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2011-01-09 18:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2011-01-09 17:35:01 UTC ---
(In reply to comment #7)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
>
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-3.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-apply-4.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> > -flto-partition=none execution test
> > FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O2 -flto
> > -flto-partition=none execution test
>
> What kind of failures are you getting here?
Run-time abort. Please check 32bit.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-09 18:06 ` hjl.tools at gmail dot com
@ 2011-01-09 18:11 ` Jan Hubicka
0 siblings, 0 replies; 19+ messages in thread
From: Jan Hubicka @ 2011-01-09 18:11 UTC (permalink / raw)
To: hjl.tools at gmail dot com; +Cc: gcc-bugs
>
> Run-time abort. Please check 32bit.
OK, these reproduce to me. Adding "staitic" into the testcase as follows:
/* PR middle-end/12210 */
/* Origin: Ossadchy Yury A. <waspcoder@mail.ru> */
/* This used to fail on i686 because the argument was not copied
to the right location by __builtin_apply after the direct call. */
/* { dg-do run } */
#define INTEGER_ARG 5
extern void abort(void);
static void foo(int arg)
{
if (arg != INTEGER_ARG)
abort();
}
static void bar(int arg)
{
foo(arg);
__builtin_apply(foo, __builtin_apply_args(), 16);
}
int main(void)
{
bar(INTEGER_ARG);
return 0;
}
make it fail too, so it is pre-existing wrong code. I am looking into what gets wrong.
Honza
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (8 preceding siblings ...)
2011-01-09 18:06 ` hjl.tools at gmail dot com
@ 2011-01-09 18:12 ` hubicka at ucw dot cz
2011-01-09 18:38 ` hubicka at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: hubicka at ucw dot cz @ 2011-01-09 18:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #9 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-09 18:06:44 UTC ---
>
> Run-time abort. Please check 32bit.
OK, these reproduce to me. Adding "staitic" into the testcase as follows:
/* PR middle-end/12210 */
/* Origin: Ossadchy Yury A. <waspcoder@mail.ru> */
/* This used to fail on i686 because the argument was not copied
to the right location by __builtin_apply after the direct call. */
/* { dg-do run } */
#define INTEGER_ARG 5
extern void abort(void);
static void foo(int arg)
{
if (arg != INTEGER_ARG)
abort();
}
static void bar(int arg)
{
foo(arg);
__builtin_apply(foo, __builtin_apply_args(), 16);
}
int main(void)
{
bar(INTEGER_ARG);
return 0;
}
make it fail too, so it is pre-existing wrong code. I am looking into what
gets wrong.
Honza
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (9 preceding siblings ...)
2011-01-09 18:12 ` hubicka at ucw dot cz
@ 2011-01-09 18:38 ` hubicka at gcc dot gnu.org
2011-01-10 12:53 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: hubicka at gcc dot gnu.org @ 2011-01-09 18:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011.01.09 18:25:04
Ever Confirmed|0 |1
--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-09 18:25:04 UTC ---
OK, the remaining stack align changes all seem to be caused by the same
problem, filled in as PR 47237. It seems to be regression to GCC 3.3, as the
API changes was introduced in 3.4 with cgraph infrastructure.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (10 preceding siblings ...)
2011-01-09 18:38 ` hubicka at gcc dot gnu.org
@ 2011-01-10 12:53 ` rguenth at gcc dot gnu.org
2011-01-10 13:24 ` hubicka at ucw dot cz
` (2 subsequent siblings)
14 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-01-10 12:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
Target Milestone|--- |4.6.0
--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-10 12:48:21 UTC ---
So this bug is in fact invalid (or a dup of PR47237), right?
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (11 preceding siblings ...)
2011-01-10 12:53 ` rguenth at gcc dot gnu.org
@ 2011-01-10 13:24 ` hubicka at ucw dot cz
2011-01-10 20:22 ` hjl at gcc dot gnu.org
2011-01-11 13:12 ` rguenth at gcc dot gnu.org
14 siblings, 0 replies; 19+ messages in thread
From: hubicka at ucw dot cz @ 2011-01-10 13:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #12 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-10 13:15:54 UTC ---
> So this bug is in fact invalid (or a dup of PR47237), right?
Well, it seemed correct to create separate PR for the wrong code bug that is
independent of plugin.
This PR tracks also the fact that ASM statements in the other testcase are
wrong and that plugin triggers PR47237 in testsuite.
Honza
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (12 preceding siblings ...)
2011-01-10 13:24 ` hubicka at ucw dot cz
@ 2011-01-10 20:22 ` hjl at gcc dot gnu.org
2011-01-11 13:12 ` rguenth at gcc dot gnu.org
14 siblings, 0 replies; 19+ messages in thread
From: hjl at gcc dot gnu.org @ 2011-01-10 20:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
--- Comment #13 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2011-01-10 19:58:59 UTC ---
Author: hjl
Date: Mon Jan 10 19:58:57 2011
New Revision: 168640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168640
Log:
Add __attribute__((externally_visible)).
2011-01-10 H.J. Lu <hongjiu.lu@intel.com>
PR lto/47222
* g++.dg/torture/stackalign/test-unwind.h (g_edi): Mark it
externally visible.
(g_esi): Likewise.
(g_ebx): Likewise.
(g_ebp): Likewise.
(g_esp): Likewise.
(g_ebp_save): Likewise.
(g_esp_save): Likewise.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/stackalign/test-unwind.h
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug lto/47222] [4.6 Regression] Revision 168593 failed many tests
2011-01-08 5:24 [Bug lto/47222] New: [4.6 Regression] Revision 168593 failed many tests hjl.tools at gmail dot com
` (13 preceding siblings ...)
2011-01-10 20:22 ` hjl at gcc dot gnu.org
@ 2011-01-11 13:12 ` rguenth at gcc dot gnu.org
14 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-01-11 13:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47222
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |FIXED
--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 13:05:11 UTC ---
Fixed.
^ permalink raw reply [flat|nested] 19+ messages in thread