[Bug middle-end/46076] New: [4.6 regression] constant propogation and compile-time math no longer happening versus 4.4 and 4.5

[Bug middle-end/46076] New: [4.6 regression] constant propogation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

           Summary: [4.6 regression] constant propogation and compile-time
                    math no longer happening versus 4.4 and 4.5
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: matt@use.net


For the following code:


#include <stdio.h>

typedef unsigned char(*Calculable)(void);

static unsigned char one() { return 1; }
static unsigned char two() { return 2; }

static void print(Calculable calculate)
{
    printf("%d\n", calculate());
    printf("+1: %d\n", calculate() + 1);
}

int main()
{
    print(one);
    print(two);

    return 0;
}


GCC 4.4 (Ubuntu/Linaro 4.4.4-14ubuntu5) and 4.5(Ubuntu/Linaro 4.5.1-7ubuntu2),
when using -O3 on amd64 using Ubuntu 10.10's packages, produce the following
code:


00000000004005a0 <main>:
  4005a0:       48 83 ec 08             sub    rsp,0x8
  4005a4:       ba 01 00 00 00          mov    edx,0x1
  4005a9:       be 00 07 40 00          mov    esi,0x400700
  4005ae:       bf 01 00 00 00          mov    edi,0x1
  4005b3:       31 c0                   xor    eax,eax
  4005b5:       e8 ae fe ff ff          call   400468 <__printf_chk@plt>
  4005ba:       ba 02 00 00 00          mov    edx,0x2
  4005bf:       be fc 06 40 00          mov    esi,0x4006fc
  4005c4:       bf 01 00 00 00          mov    edi,0x1
  4005c9:       31 c0                   xor    eax,eax
  4005cb:       e8 98 fe ff ff          call   400468 <__printf_chk@plt>
  4005d0:       ba 02 00 00 00          mov    edx,0x2
  4005d5:       be 00 07 40 00          mov    esi,0x400700
  4005da:       bf 01 00 00 00          mov    edi,0x1
  4005df:       31 c0                   xor    eax,eax
  4005e1:       e8 82 fe ff ff          call   400468 <__printf_chk@plt>
  4005e6:       ba 03 00 00 00          mov    edx,0x3
  4005eb:       be fc 06 40 00          mov    esi,0x4006fc
  4005f0:       bf 01 00 00 00          mov    edi,0x1
  4005f5:       31 c0                   xor    eax,eax
  4005f7:       e8 6c fe ff ff          call   400468 <__printf_chk@plt>
  4005fc:       31 c0                   xor    eax,eax
  4005fe:       48 83 c4 08             add    rsp,0x8
  400602:       c3                      ret    

where the constants are correctly propogated and the compile-time math occurs.

With Ubuntu 10.10's gcc-snapshot of 4.6 (Ubuntu 20101004-0ubuntu1) or an
alternate 4.6 version (Sourcery G++ 2010.09-31), neither of these things
happens, even with -fwhole-program:

0000000000400510 <_ZL3onev>:
  400510:       b8 01 00 00 00          mov    eax,0x1
  400515:       c3                      ret    
  400516:       eb 08                   jmp    400520 <_ZL3twov>
  400518:       90                      nop
  400519:       90                      nop
  40051a:       90                      nop
  40051b:       90                      nop
  40051c:       90                      nop
  40051d:       90                      nop
  40051e:       90                      nop
  40051f:       90                      nop

0000000000400520 <_ZL3twov>:
  400520:       b8 02 00 00 00          mov    eax,0x2
  400525:       c3                      ret    
  400526:       eb 08                   jmp    400530 <_ZL5printPFhvE>
  400528:       90                      nop
  400529:       90                      nop
  40052a:       90                      nop
  40052b:       90                      nop
  40052c:       90                      nop
  40052d:       90                      nop
  40052e:       90                      nop
  40052f:       90                      nop

0000000000400530 <_ZL5printPFhvE>:
  400530:       53                      push   rbx
  400531:       48 89 fb                mov    rbx,rdi
  400534:       ff d7                   call   rdi
  400536:       bf 74 06 40 00          mov    edi,0x400674
  40053b:       0f b6 f0                movzx  esi,al
  40053e:       31 c0                   xor    eax,eax
  400540:       e8 b3 fe ff ff          call   4003f8 <printf@plt>
  400545:       ff d3                   call   rbx
  400547:       5b                      pop    rbx
  400548:       0f b6 f0                movzx  esi,al
  40054b:       bf 70 06 40 00          mov    edi,0x400670
  400550:       31 c0                   xor    eax,eax
  400552:       83 c6 01                add    esi,0x1
  400555:       e9 9e fe ff ff          jmp    4003f8 <printf@plt>
  40055a:       eb 04                   jmp    400560 <main>
  40055c:       90                      nop
  40055d:       90                      nop
  40055e:       90                      nop
  40055f:       90                      nop

0000000000400560 <main>:
  400560:       48 83 ec 08             sub    rsp,0x8
  400564:       bf 10 05 40 00          mov    edi,0x400510
  400569:       e8 c2 ff ff ff          call   400530 <_ZL5printPFhvE>
  40056e:       bf 20 05 40 00          mov    edi,0x400520
  400573:       e8 b8 ff ff ff          call   400530 <_ZL5printPFhvE>
  400578:       31 c0                   xor    eax,eax
  40057a:       48 83 c4 08             add    rsp,0x8
  40057e:       c3                      ret

[Bug middle-end/46076] [4.6 regression] constant propogation and compile-time math no longer happening versus 4.4 and 4.5

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-18 21:15:16 UTC ---
This is a micro benchmark really; we would inline it as far as I can tell if we
have other things going on.

[Bug middle-end/46076] [4.6 regression] constant propogation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #2 from Matt Hargett <matt at use dot net> 2010-10-18 21:36:23 UTC ---
This is a reduction from proprietary (and complex) code, and the optimization
has regressed there as well. Any diagnosis on why it would have regressed and
not triggered a testsuite failure?

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.10.19 00:20:43
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |hubicka at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2010-10-19 00:20:43 UTC ---
It is caused by revision 158732:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-10-19 03:20:48 UTC ---
It is caused by fact that the main() function is optimized for size except for
code in loops because we know it will be executed once.
Inliner thinks that it is not good idea to inline printf.

The code size grows because we align the functions.
This is handled by the new ipa profile pass that recognizes the functions as
executed once.  With current mainline I get
0000000000400520 <main>:
  400520:       48 83 ec 08             sub    $0x8,%rsp
  400524:       bf 80 05 40 00          mov    $0x400580,%edi
  400529:       e8 12 00 00 00          callq  400540 <print>
  40052e:       bf 70 05 40 00          mov    $0x400570,%edi
  400533:       e8 08 00 00 00          callq  400540 <print>
  400538:       31 c0                   xor    %eax,%eax
  40053a:       48 83 c4 08             add    $0x8,%rsp
  40053e:       c3                      retq   
  40053f:       90                      nop

0000000000400540 <print>:
  400540:       53                      push   %rbx
  400541:       48 89 fb                mov    %rdi,%rbx
  400544:       ff d7                   callq  *%rdi
  400546:       bf 84 06 40 00          mov    $0x400684,%edi
  40054b:       0f b6 f0                movzbl %al,%esi
  40054e:       31 c0                   xor    %eax,%eax
  400550:       e8 bb fe ff ff          callq  400410 <printf@plt>
  400555:       ff d3                   callq  *%rbx
  400557:       5b                      pop    %rbx
  400558:       0f b6 f0                movzbl %al,%esi
  40055b:       bf 80 06 40 00          mov    $0x400680,%edi
  400560:       31 c0                   xor    %eax,%eax
  400562:       83 c6 01                add    $0x1,%esi
  400565:       e9 a6 fe ff ff          jmpq   400410 <printf@plt>
  40056a:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

0000000000400570 <two>:
  400570:       b8 02 00 00 00          mov    $0x2,%eax
  400575:       c3                      retq   
  400576:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  40057d:       00 00 00 

0000000000400580 <one>:
  400580:       b8 01 00 00 00          mov    $0x1,%eax
  400585:       c3                      retq   
  400586:       90                      nop
  400587:       90                      nop
  400588:       90                      nop
  400589:       90                      nop
  40058a:       90                      nop
  40058b:       90                      nop
  40058c:       90                      nop
  40058d:       90                      nop
  40058e:       90                      nop
  40058f:       90                      nop

this is smaller (if I am counting right, original is 98 bytes, the code in
comment1 is 110 bytes and this code is 95 bytes including the alignment at the
end of section.)

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-10-19 03:25:37 UTC ---
Also renaming main() to main2() so GCC no longer  can track the runtime
behaviour leads to:
   0:   53                      push   %rbx
   1:   bb 00 00 00 00          mov    $0x0,%ebx
   6:   ff d3                   callq  *%rbx
   8:   bf 00 00 00 00          mov    $0x0,%edi
   d:   0f b6 f0                movzbl %al,%esi
  10:   31 c0                   xor    %eax,%eax
  12:   e8 00 00 00 00          callq  17 <main2+0x17>
  17:   ff d3                   callq  *%rbx
  19:   0f b6 f0                movzbl %al,%esi
  1c:   bf 00 00 00 00          mov    $0x0,%edi
  21:   31 c0                   xor    %eax,%eax
  23:   83 c6 01                add    $0x1,%esi
  26:   bb 00 00 00 00          mov    $0x0,%ebx
  2b:   e8 00 00 00 00          callq  30 <main2+0x30>
  30:   ff d3                   callq  *%rbx
  32:   bf 00 00 00 00          mov    $0x0,%edi
  37:   0f b6 f0                movzbl %al,%esi
  3a:   31 c0                   xor    %eax,%eax
  3c:   e8 00 00 00 00          callq  41 <main2+0x41>
  41:   ff d3                   callq  *%rbx
  43:   0f b6 f0                movzbl %al,%esi
  46:   bf 00 00 00 00          mov    $0x0,%edi
  4b:   31 c0                   xor    %eax,%eax
  4d:   83 c6 01                add    $0x1,%esi
  50:   e8 00 00 00 00          callq  55 <main2+0x55>
  55:   31 c0                   xor    %eax,%eax
  57:   5b                      pop    %rbx
  58:   c3                      retq   
  59:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)

that is 89 bytes.
What is the problem with the proprietary and complex code?

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-10-19 03:33:39 UTC ---
Hmm, actually in the modified testcase we miss the indirect inlining and we
also never turn the indirect call into direct call.
The problem is that pointer cast is in the way
  one.0_1 = (unsigned char (*Calculable) (void)) one;
  D.3314_7 = one.0_1 ();

Martin, Richi, this is really yours area.
I think both indirect inlining and constant propagation should be able to get
past the cast especially when there is no type mismatch in the testcase.

Honza

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-19 04:42:40 UTC ---
(In reply to comment #6)
> I think both indirect inlining and constant propagation should be able to get
> past the cast especially when there is no type mismatch in the testcase.

Either try with (void) in the function declaration or try using the C++
front-end.  () and (void) are different in C :).

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2010-10-19 05:47:31 UTC ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076
> 
> --- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-19 04:42:40 UTC ---
> (In reply to comment #6)
> > I think both indirect inlining and constant propagation should be able to get
> > past the cast especially when there is no type mismatch in the testcase.
> 
> Either try with (void) in the function declaration or try using the C++
> front-end.  () and (void) are different in C :).

Well, still we have no real reason to not optimize this.  C programs does this.
Honza

Re: [Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[Jan Hubicka]

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076
> 
> --- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-19 04:42:40 UTC ---
> (In reply to comment #6)
> > I think both indirect inlining and constant propagation should be able to get
> > past the cast especially when there is no type mismatch in the testcase.
> 
> Either try with (void) in the function declaration or try using the C++
> front-end.  () and (void) are different in C :).

Well, still we have no real reason to not optimize this.  C programs does this.
Honza

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |jakub at gcc dot gnu.org

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org
          Component|middle-end                  |c

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-04 13:04:58 UTC ---
Joseph, does C really distinguish between

int foo()
{
}

and

int foo(void)
{
}

?  That is, are they not the same when in a function definition context
(as opposed to declaration context)?

It would be nice if the C frontend would handle them the same (thus,
make it not varargs).

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-11-04 13:54:58 UTC ---
On Thu, 4 Nov 2010, rguenth at gcc dot gnu.org wrote:

> Joseph, does C really distinguish between
> 
> int foo()
> {
> }
> 
> and
> 
> int foo(void)
> {
> }
> 
> ?  That is, are they not the same when in a function definition context
> (as opposed to declaration context)?

Yes, they are different.  The first definition does not give foo a type 
that includes a prototype for subsequent references to that function in 
the translation unit.  Thus a subsequent function may call foo with 
arguments - this is undefined behavior only at runtime, if the call is 
executed, not at compile time - and although the standard is less clear 
(see DR#316) that pointers to foo can be stored in pointers to other 
prototyped function types (with int return type, not variadic) without 
casts.

> It would be nice if the C frontend would handle them the same (thus,
> make it not varargs).

int foo() certainly isn't varargs; unprototyped function types are always 
incompatible with variadic function types.

You could lower the function to have a type with (void) at some point - 
modulo any differences there might be in how they are supposed to be 
represented in debug info - but then you might need to fix up the 
conversions between types that are now incompatible, and to convert calls 
with bad arguments to use __builtin_trap (after evaluating all the 
arguments, in case one of the arguments calls exit, of course - the 
undefined behavior is only at the point of the call, after evaluation of 
all the arguments and the function designator).

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #11 from Matt Hargett <matt at use dot net> 2010-11-17 21:37:43 UTC ---
Given that "int foo()" and "int foo(void)" are not varargs functions, shouldn't
GCC mainline be able to optimize this?

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> 2010-11-18 11:31:59 UTC ---
On Wed, 17 Nov 2010, matt at use dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076
> 
> --- Comment #11 from Matt Hargett <matt at use dot net> 2010-11-17 21:37:43 UTC ---
> Given that "int foo()" and "int foo(void)" are not varargs functions, shouldn't
> GCC mainline be able to optimize this?

The types are not treated as compatible.

The following would change that:

Index: tree-ssa.c
===================================================================
--- tree-ssa.c  (revision 166900)
+++ tree-ssa.c  (working copy)
@@ -1410,6 +1410,11 @@ useless_type_conversion_p (tree outer_ty
       if (!TYPE_ARG_TYPES (outer_type))
        return true;

+      /* A conversion between unprototyped and empty argument list is ok.  
*/
+      if (TYPE_ARG_TYPES (outer_type) == void_list_node
+         && !TYPE_ARG_TYPES (inner_type))
+       return true;
+
       /* If the unqualified argument types are compatible the conversion
         is useless.  */
       if (TYPE_ARG_TYPES (outer_type) == TYPE_ARG_TYPES (inner_type))

But for example our type-generic builtins for isinf and friends also
use a NULL TYPE_ARG_TYPES list but they _are_ variadic and certainly
not compatible with isinf (void).  I'm also not sure if other languages
allow variadic functions without a first arg (the backends would
certainly handle that just fine I think).

That said - the middle-end doesn't really have a notion of "unprototyped".
That's a concept the frontend should lower (at call-sites, but that
requires some middle-end infrastructure change).

Richard.

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> 2010-11-18 12:07:51 UTC ---
> That said - the middle-end doesn't really have a notion of "unprototyped".
> That's a concept the frontend should lower (at call-sites, but that
> requires some middle-end infrastructure change).
What I was thinking of here is some gimple optimization working out that we can
update type of the originally indirect call...  That way the types don't need
to
be neccesarily compatible.
Obviously K&R C will also do variadic functions without prototypes...

Honza

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-18 12:11:42 UTC ---
(In reply to comment #13)
> > That said - the middle-end doesn't really have a notion of "unprototyped".
> > That's a concept the frontend should lower (at call-sites, but that
> > requires some middle-end infrastructure change).
> What I was thinking of here is some gimple optimization working out that we can
> update type of the originally indirect call...  That way the types don't need
> to
> be neccesarily compatible.
> Obviously K&R C will also do variadic functions without prototypes...

What we need (and what I unfortunately have postponed to next stage1) is
a way to keep the (indirect call) function type.  For which I will simply
add a fn_type member to gimple_call which is controlled by the frontend.
We then can treat function pointer conversions as useless (and then
the inliner has to decide if the call is suitable for the fndecl).

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-04 17:39:45 UTC ---
I'd also prefer a general solution and would not actually mind very
much if we regressed in cases like this.  Nevertheless, if we have a
consensus that we should avoid regressing in 4.6, an ipa-prop.c
specific handling of this situation would probably look very much like
the patch below.  Given the discussion above I am not 100% sure it is
always safe but it passes bootstrap and testing (though I do not know
how much it exercises the code path).  I'll be happy to submit the
patch with a testcase and a change log and stuff if any maintainer
thinks it is a good idea.

Index: gcc/ipa-prop.c
===================================================================
--- gcc/ipa-prop.c    (revision 168424)
+++ gcc/ipa-prop.c    (working copy)
@@ -396,6 +396,25 @@ compute_complex_assign_jump_func (struct
     }
       return;
     }
+  else if (!op2 && is_gimple_ip_invariant (op1))
+    {
+      tree name_type = TREE_TYPE (name);
+      tree op_type = TREE_TYPE (op1);
+
+      if (useless_type_conversion_p (name_type, op_type)
+      || (POINTER_TYPE_P (name_type)
+          && POINTER_TYPE_P (op_type)
+          && TREE_CODE (TREE_TYPE (name_type)) == FUNCTION_TYPE
+          && TREE_CODE (TREE_TYPE (op_type)) == FUNCTION_TYPE
+          && (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (name_type)))
+          == TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (op_type))))
+          && TYPE_ARG_TYPES (TREE_TYPE (name_type)) == void_list_node
+          && !TYPE_ARG_TYPES (TREE_TYPE (op_type))))
+    {
+      jfunc->type = IPA_JF_CONST;
+      jfunc->value.constant = op1;
+    }
+    }

   if (TREE_CODE (op1) != ADDR_EXPR)
     return;

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu.org

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 14:32:23 UTC ---
I don't think we should add hacks like that.  Either the type signatures
are compatible for the middle-end (and exchanging one for the other does not
affect generated code for any target) or not.  I can't answer this question.
If they are indeed compatible then fixing the bug is easy.

Thus, can I call

 void foo();

via

 *(void (*)(void))&foo

and can I call

 void foo (void);

via

 *(void (*)())&foo

on all targets without unexpected effects (assuming foo does not use
any arguments)?

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #17 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-01-11 15:28:56 UTC ---
On Tue, 11 Jan 2011, rguenth at gcc dot gnu.org wrote:

> I don't think we should add hacks like that.  Either the type signatures
> are compatible for the middle-end (and exchanging one for the other does not
> affect generated code for any target) or not.  I can't answer this question.
> If they are indeed compatible then fixing the bug is easy.
> 
> Thus, can I call
> 
>  void foo();
> 
> via
> 
>  *(void (*)(void))&foo
> 
> and can I call
> 
>  void foo (void);
> 
> via
> 
>  *(void (*)())&foo
> 
> on all targets without unexpected effects (assuming foo does not use
> any arguments)?

Yes, those types are compatible and so this should work for all ABIs 
designed for C (which should mean all ABIs GCC handles).  An unprototyped 
function type is compatible with a prototyped one if the return types are 
compatible, the prototyped type is not variadic and the prototyped type 
does not have parameter types such as "char" that are changed under the 
default argument promotions.

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 15:52:48 UTC ---
Mine then.

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 17:01:45 UTC ---
Author: rguenth
Date: Tue Jan 11 17:01:37 2011
New Revision: 168665

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168665
Log:
2011-01-11  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/46076
    * tree-ssa.c (useless_type_conversion_p): Conversions from
    unprototyped to empty argument list function types are useless.

    * gcc.dg/tree-ssa/pr46076.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr46076.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa.c

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 17:02:05 UTC ---
Fixed.

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #21 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-14 12:39:14 UTC ---
Author: rguenth
Date: Fri Jan 14 12:39:09 2011
New Revision: 168781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168781
Log:
2011-01-14  Richard Guenther  <rguenther@suse.de>

    PR middle-end/47281
    Revert
    2011-01-11  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/46076
        * tree-ssa.c (useless_type_conversion_p): Conversions from
        unprototyped to empty argument list function types are useless.

    * gcc.dg/torture/pr47281.c: New testcase.
    * gcc.dg/tree-ssa/pr46076.c: XFAIL.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr47281.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr46076.c
    trunk/gcc/tree-ssa.c

[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #22 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-14 12:39:55 UTC ---
Reopen.

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.0                       |4.6.1

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-25 19:53:06 UTC ---
GCC 4.6.0 is being released, adjusting target milestone.

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #24 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-12 10:44:20 UTC ---
Author: rguenth
Date: Tue Apr 12 10:44:15 2011
New Revision: 172310

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172310
Log:
2011-04-12  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/46076
    * gimple.h (struct gimple_statement_call): Add fntype field.
    (gimple_call_fntype): Adjust.
    (gimple_call_set_fntype): New function.
    * gimple.c (gimple_build_call_1): Set the call function type.
    * gimplify.c (gimplify_call_expr): Preserve the function
    type the frontend used for the call.
    (gimplify_modify_expr): Likewise.
    * lto-streamer-in.c (input_gimple_stmt): Input the call stmts
    function type.
    * lto-streamer-out.c (output_gimple_stmt): Output the call stmts
    function type.
    * tree-ssa.c (useless_type_conversion_p): Function pointer
    conversions are useless.

    * gcc.dg/tree-ssa/pr46076.c: Un-XFAIL.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple.c
    trunk/gcc/gimple.h
    trunk/gcc/gimplify.c
    trunk/gcc/lto-streamer-in.c
    trunk/gcc/lto-streamer-out.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr46076.c
    trunk/gcc/tree-ssa.c

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #25 from Matt Hargett <matt at use dot net> 2011-04-12 16:24:33 UTC ---
backport to 4.6 for 4.6.1? I'll apply locally and report any issues in the
meantime.

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-12 17:39:29 UTC ---
No, such big changes shouldn't be backported to release branches.

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #27 from Matt Hargett <matt at use dot net> 2011-04-12 18:15:33 UTC ---
That's unfortunate. Can you adjust the target milestone, then?

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> 2011-04-12 22:31:53 UTC ---
On Tue, 12 Apr 2011, matt at use dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076
> 
> --- Comment #27 from Matt Hargett <matt at use dot net> 2011-04-12 18:15:33 UTC ---
> That's unfortunate. Can you adjust the target milestone, then?

I still hope some more trivial fix for this particular case comes
to my mind.

[Bug tree-optimization/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.1                       |4.6.2

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-27 12:33:10 UTC ---
GCC 4.6.1 is being released.

[Bug tree-optimization/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.2                       |4.6.3

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-26 17:13:56 UTC ---
GCC 4.6.2 is being released.

[Bug tree-optimization/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.3                       |4.6.4

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-01 14:39:15 UTC ---
GCC 4.6.3 is being released.

[Bug tree-optimization/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #32 from Matt Hargett <matt at use dot net> 2012-03-23 20:30:17 UTC ---
Richard, if nothing's come to mind by now for the 4.6 branch, can this be
closed?
I'd like to see it fixed, of course, but so long as it still works in 4.7.0 and
there's a test in the suite that verifies as such, let's move on :)

[Bug tree-optimization/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.6.4                       |4.7.0
      Known to fail|                            |4.6.3

--- Comment #33 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-26 06:52:23 UTC ---
Yeah.