[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #24 from ubizjak at gmail dot com 2008-01-31 08:21 --- Author: hubicka Date: Wed Jan 30 23:25:35 2008 New Revision: 131969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131969 Log: * gcc.c-torture/execute/pr34982.c: Add forgotten return 0. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr34982.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #14 from steven at gcc dot gnu dot org 2008-01-30 12:35 --- Patch in comment #9 works for me. -- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-01-30 15:54 --- Fixed at mainline. I am really surprises this is 4.3 only regression since the code didn't see much changes in last few releases. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-01-30 15:55 --- Subject: Bug 34982 Author: hubicka Date: Wed Jan 30 15:54:14 2008 New Revision: 131966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131966 Log: PR target/34982 * i386.c (init_cumulative_args): Use real function declaration when calling locally. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr34982.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #17 from hubicka at ucw dot cz 2008-01-30 15:56 --- Subject: Re: [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher These tests time out from time to time when the testing box is busy, that's quite normal. The problem is in the use of sched_yield (), which puts the calling thread to the end of the runqueue. If there are many processes in the runqueue, one or more of the 10 threads might miss the 10 sec timeout in one or more of the 20 repetitions in 100 sched_yield calls. So just ignore this. Thanks for explanation. It happent few time in past to me that I ignored mudflap failures incorrectly claiming random noise. Now at least I know how to look for test that is supposed to have this problem. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #18 from dominiq at lps dot ens dot fr 2008-01-30 22:59 --- On i686-apple-darwin9 (rev. 131968), the new test gcc.c-torture/execute/pr34982.c fails: FAIL: gcc.c-torture/execute/pr34982.c execution, -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-01-30 23:08
---
(In reply to comment #19)
Any idea why the test is failing in the test suite?
Yes because main needs a return 0;
so the main function should look like:
int main()
{
something(-1);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-01-30 23:18 --- (In reply to comment #21) but why does this happen only with -O1? Random value in eax register so we could put 0 in some cases but not others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #23 from hubicka at ucw dot cz 2008-01-30 23:20 --- Subject: Re: [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher (In reply to comment #21) but why does this happen only with -O1? Random value in eax register so we could put 0 in some cases but not others. Oops, I am going to commit obvious fix for that. Looks like my tester got lucky. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #21 from dominiq at lps dot ens dot fr 2008-01-30 23:15 --- Yes because main needs a return 0; but why does this happen only with -O1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #19 from dominiq at lps dot ens dot fr 2008-01-30 23:05 --- Follow up to comment #18, the test pass if I run it directly or if I run gcc/testsuite/gcc/pr34982.x1. Any idea why the test is failing in the test suite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #11 from hubicka at ucw dot cz 2008-01-29 17:51 --- Subject: Re: [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher Hi, the patch seems to pass my local testing, but on Zdenek's tester I get curious results on i686: Tests that now fail, but worked before: libmudflap.cth/pass37-frag.c (-O2) (rerun 14) execution test libmudflap.cth/pass37-frag.c (-O2) (rerun 18) execution test libmudflap.cth/pass37-frag.c (-O2) (rerun 18) output pattern test libmudflap.cth/pass37-frag.c (-O3) (rerun 2) execution test libmudflap.cth/pass37-frag.c (-O3) (rerun 2) output pattern test libmudflap.cth/pass37-frag.c (-O3) (rerun 3) execution test libmudflap.cth/pass37-frag.c (-O3) (rerun 3) output pattern test libmudflap.cth/pass37-frag.c (-static -DSTATIC) (rerun 10) execution test libmudflap.cth/pass37-frag.c (-static -DSTATIC) (rerun 16) execution test libmudflap.cth/pass37-frag.c (-static -DSTATIC) (rerun 16) output pattern test libmudflap.cth/pass37-frag.c (rerun 10) execution test libmudflap.cth/pass37-frag.c (rerun 10) output pattern test libmudflap.cth/pass37-frag.c (rerun 12) execution test libmudflap.cth/pass37-frag.c (rerun 12) output pattern test libmudflap.cth/pass37-frag.c (rerun 13) execution test libmudflap.cth/pass37-frag.c (rerun 14) execution test libmudflap.cth/pass37-frag.c (rerun 14) output pattern test libmudflap.cth/pass37-frag.c (rerun 15) execution test libmudflap.cth/pass37-frag.c (rerun 17) execution test libmudflap.cth/pass37-frag.c (rerun 17) output pattern test libmudflap.cth/pass37-frag.c (rerun 2) execution test libmudflap.cth/pass37-frag.c (rerun 2) output pattern test libmudflap.cth/pass37-frag.c (rerun 4) execution test libmudflap.cth/pass37-frag.c (rerun 4) output pattern test libmudflap.cth/pass39-frag.c (-O2) (rerun 11) execution test libmudflap.cth/pass39-frag.c (-O2) (rerun 4) execution test libmudflap.cth/pass39-frag.c (-O3) (rerun 13) execution test libmudflap.cth/pass39-frag.c (-O3) (rerun 13) output pattern test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 10) execution test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 10) output pattern test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 14) execution test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 14) output pattern test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 16) execution test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 16) output pattern test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 4) execution test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 4) output pattern test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 5) execution test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 5) output pattern test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 7) execution test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 7) output pattern test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 9) execution test libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 9) output pattern test libmudflap.cth/pass39-frag.c (rerun 1) execution test libmudflap.cth/pass39-frag.c (rerun 1) output pattern test libmudflap.cth/pass39-frag.c (rerun 15) execution test libmudflap.cth/pass39-frag.c (rerun 18) execution test libmudflap.cth/pass39-frag.c (rerun 18) output pattern test libmudflap.cth/pass39-frag.c (rerun 19) execution test libmudflap.cth/pass39-frag.c (rerun 9) execution test libmudflap.cth/pass39-frag.c (rerun 9) output pattern test libmudflap.cth/pass39-frag.c execution test libmudflap.cth/pass39-frag.c output pattern test libmudflap.cth/pass40-frag.c (-O2) execution test libmudflap.cth/pass40-frag.c (-O2) output pattern test libmudflap.cth/pass40-frag.c (-static -DSTATIC) execution test libmudflap.cth/pass40-frag.c (-static -DSTATIC) output pattern test libmudflap.cth/pass40-frag.c
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #12 from jakub at gcc dot gnu dot org 2008-01-29 21:22 --- These tests time out from time to time when the testing box is busy, that's quite normal. The problem is in the use of sched_yield (), which puts the calling thread to the end of the runqueue. If there are many processes in the runqueue, one or more of the 10 threads might miss the 10 sec timeout in one or more of the 20 repetitions in 100 sched_yield calls. So just ignore this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #13 from tromey at gcc dot gnu dot org 2008-01-30 01:19 --- other than that, I'm not aware of any commonly used KR bits and pieces in a modern system. FWIW -- Emacs is mostly KR. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #6 from hubicka at ucw dot cz 2008-01-27 13:54 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
cgraph_local_info still behaves as expected returning NULL when info is
not computed yet. Unfortunately check to simply ignore it when not
available has been added to ix86_function_regparm that makes this bug
lead to wrong code. (revision 123146)
There are two occurences where we can ix86_function_regparm. First one
is for compatibility checking, I would just declare it invalid - we
don't want the type comatiblity to depend on backend decision and I
think it is perfectly sane to reject any types specifying different
REGPARM values or where one specify and other doesn't.
I am testing attached patch and will commit it if passes.
Other case is from gimplifier, I am looking into it. This definitly has
to go or we need to drop the feature :(
Honza
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 131882)
+++ config/i386/i386.c (working copy)
@@ -3148,6 +3148,7 @@ ix86_comp_type_attributes (const_tree ty
{
/* Check for mismatch of non-default calling convention. */
const char *const rtdstr = TARGET_RTD ? cdecl : stdcall;
+ tree attr1, attr2;
if (TREE_CODE (type1) != FUNCTION_TYPE
TREE_CODE (type1) != METHOD_TYPE)
@@ -3155,11 +3156,27 @@ ix86_comp_type_attributes (const_tree ty
/* Check for mismatched fastcall/regparm types. */
if ((!lookup_attribute (fastcall, TYPE_ATTRIBUTES (type1))
- != !lookup_attribute (fastcall, TYPE_ATTRIBUTES (type2)))
- || (ix86_function_regparm (type1, NULL)
- != ix86_function_regparm (type2, NULL)))
+ != !lookup_attribute (fastcall, TYPE_ATTRIBUTES (type2
return 0;
+ /* We don't want to use ix86_function_regparm here: it's decision depends
+ on middle end information, like localness of functions. Here we only
want
+ to know if types are declared compatible. */
+ attr1 = lookup_attribute (regparm, TYPE_ATTRIBUTES (type1));
+ attr2 = lookup_attribute (regparm, TYPE_ATTRIBUTES (type2));
+
+ if ((attr1 != NULL_TREE) != (attr2 != NULL_TREE))
+return 0;
+
+ if (attr1)
+{
+ int val1 = TREE_INT_CST_LOW (TREE_VALUE (TREE_VALUE (attr1)));
+ int val2 = TREE_INT_CST_LOW (TREE_VALUE (TREE_VALUE (attr2)));
+
+ if (val1 != val2)
+ return 0;
+}
+
/* Check for mismatched sseregparm types. */
if (!lookup_attribute (sseregparm, TYPE_ATTRIBUTES (type1))
!= !lookup_attribute (sseregparm, TYPE_ATTRIBUTES (type2)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-27 14:19 --- One more reason to gimplify unit-at-a-time... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #8 from hubicka at ucw dot cz 2008-01-27 18:10 --- Subject: Re: [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher One more reason to gimplify unit-at-a-time... Yep, on the other hand there is probably not much need to get that amount of architectural detail so easy. I am looking into what makes the compilation to diverge. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #9 from hubicka at ucw dot cz 2008-01-27 19:24 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
However the failure here is not early calling of cgraph_local_info (it
is ugly, but harmless, we are just looking for target promoting rules
that we don't change).
The problem is good old type system broken scenario: the forward
declaration has no prorotype and thus might be vararg and thus it is not
regparmized, however the definition is correct. When expanding the call
we use type of the call, so the wrong type.
I am testing the attached patch. My type merging code fixes this too and
obvioiusly we should work harder on maybe_vaarg rule for local
functions, this should make lot of difference on KR code (I wonder if
any is still around in usual distro)
Honza
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 131882)
--- config/i386/i386.c (working copy)
*** init_cumulative_args (CUMULATIVE_ARGS *c
*** 3432,3437
--- 3449,3455
rtx libname, /* SYMBOL_REF of library name or 0 */
tree fndecl)
{
+ struct cgraph_local_info *i = fndecl ? cgraph_local_info (fndecl) : NULL;
memset (cum, 0, sizeof (*cum));
/* Set up the number of registers to use for passing arguments. */
*** init_cumulative_args (CUMULATIVE_ARGS *c
*** 3442,3447
--- 3460,3474
cum-mmx_nregs = MMX_REGPARM_MAX;
cum-warn_sse = true;
cum-warn_mmx = true;
+
+ /* Because type might mismatch in between caller and callee, we need to
+ use actual type of function for local calls.
+ FIXME: cgraph_analyze can be told to actually record if function uses
+ va_start so for local functions maybe_vaarg can be made aggressive
+ helping KR code.
+ FIXME: once typesytem is fixed, we won't need this code anymore. */
+ if (i i-local)
+ fntype = TREE_TYPE (fndecl);
cum-maybe_vaarg = (fntype
? (!prototype_p (fntype) || stdarg_p (fntype))
: !libname);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #10 from bero at arklinux dot org 2008-01-27 19:36 --- this should make lot of difference on KR code (I wonder if any is still around in usual distro) Some parts of xorg still follow KR conventions, few parts of teTeX have KR code in them, cdrtools is fully KR (I fixed that in the dvdrtools fork, not sure if any of the other cdrtools forks in circulation copied that) -- other than that, I'm not aware of any commonly used KR bits and pieces in a modern system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-26 18:50 ---
We seem to use local calling conventions for emitting the body of something,
but
at the call site we pass arguments via the stack.
P1 until we know more about this.
Reduced testcase:
extern void abort (void);
static void something();
int main()
{
something(-1);
}
static void something(int i)
{
if (i != -1)
abort ();
}
The asm shows it:
something:
subl$12, %esp
cmpl$-1, %eax
je .L3
callabort
.L3:
addl$12, %esp
ret
but:
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ecx
subl$8, %esp
movl$-1, (%esp)
callsomething
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |target
Ever Confirmed|0 |1
Keywords||wrong-code
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2008-01-26 18:50:39
date||
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-26 19:09 --- Janis, can you hunt this? Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-26 19:23 ---
So we use the local info before it is available and thus the following will
ICE:
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 131861)
+++ config/i386/i386.c (working copy)
@@ -3199,6 +3199,7 @@ ix86_function_regparm (const_tree type,
{
/* FIXME: remove this CONST_CAST when cgraph.[ch] is constified. */
struct cgraph_local_info *i = cgraph_local_info (CONST_CAST_TREE(decl));
+ gcc_assert (cgraph_node (CONST_CAST_TREE(decl))-analyzed);
if (i i-local)
{
int local_regparm, globals = 0, regno;
and if it is just not available (i == NULL) might give inconsistent
answers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-26 19:07 --- The first time we ask, cgraph_local_info ()-local is zero, the second time it is one. Honza, Uros? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org, ||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #5 from hubicka at ucw dot cz 2008-01-26 20:19 --- Subject: Re: [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher and if it is just not available (i == NULL) might give inconsistent answers. I will look into this. cgraph_local_info used to trap when asked for unavailable local info, looks like someone fixed the bug by removing the assert. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
