Bug 46076 - [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5
Summary: [4.6 regression] constant propagation and compile-time math no longer happeni...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.6.0
: P2 normal
Target Milestone: 4.7.0
Assignee: Richard Biener
URL:
Keywords: missed-optimization
Depends on: 47281
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-18 21:01 UTC by Matt Hargett
Modified: 2012-03-26 06:52 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.5.2, 4.7.0
Known to fail: 4.6.0, 4.6.3
Last reconfirmed: 2010-10-19 00:20:43


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Hargett 2010-10-18 21:01:33 UTC
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
Comment 1 Andrew Pinski 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.
Comment 2 Matt Hargett 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?
Comment 3 H.J. Lu 2010-10-19 00:20:43 UTC
It is caused by revision 158732:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html
Comment 4 Jan Hubicka 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.)
Comment 5 Jan Hubicka 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?
Comment 6 Jan Hubicka 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
Comment 7 Andrew Pinski 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 :).
Comment 8 Jan Hubicka 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
Comment 9 Richard Biener 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).
Comment 10 joseph@codesourcery.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).
Comment 11 Matt Hargett 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?
Comment 12 rguenther@suse.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.
Comment 13 Jan Hubicka 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
Comment 14 Richard Biener 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).
Comment 15 Martin Jambor 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;
Comment 16 Richard Biener 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)?
Comment 17 joseph@codesourcery.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.
Comment 18 Richard Biener 2011-01-11 15:52:48 UTC
Mine then.
Comment 19 Richard Biener 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
Comment 20 Richard Biener 2011-01-11 17:02:05 UTC
Fixed.
Comment 21 Richard Biener 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
Comment 22 Richard Biener 2011-01-14 12:39:55 UTC
Reopen.
Comment 23 Jakub Jelinek 2011-03-25 19:53:06 UTC
GCC 4.6.0 is being released, adjusting target milestone.
Comment 24 Richard Biener 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
Comment 25 Matt Hargett 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.
Comment 26 Jakub Jelinek 2011-04-12 17:39:29 UTC
No, such big changes shouldn't be backported to release branches.
Comment 27 Matt Hargett 2011-04-12 18:15:33 UTC
That's unfortunate. Can you adjust the target milestone, then?
Comment 28 rguenther@suse.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.
Comment 29 Jakub Jelinek 2011-06-27 12:33:10 UTC
GCC 4.6.1 is being released.
Comment 30 Jakub Jelinek 2011-10-26 17:13:56 UTC
GCC 4.6.2 is being released.
Comment 31 Jakub Jelinek 2012-03-01 14:39:15 UTC
GCC 4.6.3 is being released.
Comment 32 Matt Hargett 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 :)
Comment 33 Richard Biener 2012-03-26 06:52:23 UTC
Yeah.