[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-09-07 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Richard Guenther  2012-09-07 
11:25:26 UTC ---
Fixed.


[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-04-25 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

--- Comment #6 from Jan Hubicka  2012-04-25 
11:31:47 UTC ---
Author: hubicka
Date: Wed Apr 25 11:31:42 2012
New Revision: 186815

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186815
Log:
PR middle-end/53088
* gcc.target/i386/pr39082-1.c: Update warning location.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c


[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-04-25 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

--- Comment #5 from Jan Hubicka  2012-04-25 
11:21:52 UTC ---
Hmm, after some playing with this, I don't really know how to make the warning
output right all the time.  To fix the regression I will simply update the
testcase.
The warning now goes on different place because of different gimplification
order. We used to first gimplify the call. Now we first gimplify the function
and warn on its declaration.
It is not bad and the input_location is correctly initialized by cgraph.

I do not get any confused carret:
a.c: In function 'foo1':
a.c:16:1: note: the ABI of passing union with long double has changed in GCC
4.4
 foo1 (union un u)
 ^


[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-04-24 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

--- Comment #4 from Jan Hubicka  2012-04-24 
15:12:36 UTC ---
I guess get_curr_insn_source_location is what I neeed...


[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-04-24 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

--- Comment #3 from Jan Hubicka  2012-04-24 
15:07:21 UTC ---
At few places in cgraph code we set location to get those late diagnostics
right. It sort of makes sense for function wide diagnostics, but it is not this
one.

(gdb) bt
#0  inform (location=1925, gmsgid=0x379f4b8 "the ABI of passing union with long
double has changed in GCC 4.4") at ../../gcc/diagnostic.c:745
#1  0x029a5f2b in classify_argument (mode=BLKmode, type=0x777a9498,
classes=0x7fffded0, bit_offset=0) at ../../gcc/config/i386/i386.c:6124
#2  0x029a6635 in examine_argument (mode=BLKmode, type=0x777a9498,
in_return=0, int_nregs=0x7fffdf38, sse_nregs=0x7fffdf34) at
../../gcc/config/i386/i386.c:6311
#3  0x029a71e9 in function_arg_advance_64 (cum=0x7fffe090,
mode=BLKmode, type=0x777a9498, words=2, named=1 '\001') at
../../gcc/config/i386/i386.c:6661
#4  0x029a748c in ix86_function_arg_advance (cum_v={magic = 0x4a6f0a0,
p = 0x7fffe090}, mode=BLKmode, type=0x777a9498, named=1 '\001') at
../../gcc/config/i386/i386.c:6715
#5  0x00ea45dd in gimplify_parameters () at ../../gcc/function.c:3572
#6  0x010217b5 in gimplify_body (fndecl=0x777c6100, do_parms=1
'\001') at ../../gcc/gimplify.c:8140
#7  0x01022e0a in gimplify_function_tree (fndecl=0x777c6100) at
../../gcc/gimplify.c:8278
#8  0x00a8a229 in cgraph_analyze_function (node=0x77697750) at
../../gcc/cgraphunit.c:608
#9  0x00a8b472 in cgraph_analyze_functions () at
../../gcc/cgraphunit.c:901
#10 0x00a901cf in cgraph_finalize_compilation_unit () at
../../gcc/cgraphunit.c:2416
#11 0x0050e4f4 in c_write_global_declarations () at
../../gcc/c-decl.c:10043
#12 0x01985ba3 in compile_file () at ../../gcc/toplev.c:572
#13 0x01987f7d in do_compile () at ../../gcc/toplev.c:1939
#14 0x019880d2 in toplev_main (argc=3, argv=0x7fffe7c8) at
../../gcc/toplev.c:2015
#15 0x0074efbb in main (argc=3, argv=0x7fffe7c8) at
../../gcc/main.c:36

I guess the catch is that gimplify_body is the last one knowing what statement
it is looking at.  I would expected expansion to set the source location,
right?
Outputting this on functio ndeclaration, that is still avaiable to the
cummulative arguments API is not quite right, because we would not handle
indirect calls.

Honza


[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-04-24 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

Richard Guenther  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0


[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-04-23 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

--- Comment #2 from Richard Guenther  2012-04-23 
18:54:41 UTC ---
(In reply to comment #1)
> Mine.  i386 outputs the message with input_loc, so it seems we need to set it
> correctly.

It should use some more sensible location though - input_location should be
essentially non-accessible from outside the frontend.  Also see the bogus
caret on the function prototype (which should point to the union parameter?)


[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c

2012-04-23 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-23
 Ever Confirmed|0   |1

--- Comment #1 from Jan Hubicka  2012-04-23 
18:40:29 UTC ---
Mine.  i386 outputs the message with input_loc, so it seems we need to set it
correctly.