[Bug tree-optimization/49911] New: vrp2 + -fstrict-enums incorrectly remove predicate

[Bug tree-optimization/49911] New: vrp2 + -fstrict-enums incorrectly remove predicate

[rafael.espindola at gmail dot com]

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

           Summary: vrp2 + -fstrict-enums incorrectly remove predicate
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rafael.espindola@gmail.com


with a r176947 cc1plus, running

cc1plus -fstrict-enums -fdump-tree-all ~/tmpfs/test2.ii -fno-rtti
-fno-exceptions -fno-strict-aliasing   -m32 -O2

in

extern  void JS_Assert();
typedef enum {
eax,         ecx,         edx,         ebx,         esp,         ebp,        
esi,         edi     }
RegisterID;
union StateRemat {
  RegisterID reg_;
  int offset_;
};
static StateRemat FromRegister(RegisterID reg) {
  StateRemat sr;
  sr.reg_ = reg;
  return sr;
}
static StateRemat FromAddress3(int address) {
  StateRemat sr;
    sr.offset_ = address;
  //sr.offset_ = 0;
  if (address < 46 &&    address >= 0) {
    JS_Assert();
  }
  return sr;
}
struct FrameState {
  StateRemat dataRematInfo2(bool y, int z) {
    if (y)         return FromRegister(RegisterID(1));
    return FromAddress3(z);
  }
};
FrameState frame;
StateRemat x;
void jsop_setelem(bool y, int z) {
  x = frame.dataRematInfo2(y, z);
}

produces a test2.ii.123t.vrp2 with:

Folding predicate SR.6_11 <= 45 to 1

replacing the "sr.offset_ = address" line with sr.offset_ = 0 prevents the
transformation.

[Bug tree-optimization/49911] vrp2 + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-07-31 09:56:41 UTC ---
Smells like the latent issue that we treat all integral types with the same
precision as equal but VRP extracts more fine-grained information.  Eric was
opposed to a patch that fixes that.  In the past copyrename exposed this
issue for example, but I guess inlining may do the same.

But I can't reproduce this on x86_64-darwin with rev. 176967.

[Bug tree-optimization/49911] vrp2 + -fstrict-enums incorrectly remove predicate

[rafael.espindola at gmail dot com]

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

--- Comment #2 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-07-31 13:38:54 UTC ---
I got it on 32 bit linux. Doing a git pull to check if it has just been fixed.

[Bug tree-optimization/49911] vrp2 + -fstrict-enums incorrectly remove predicate

[rafael.espindola at gmail dot com]

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

--- Comment #3 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-07-31 13:57:17 UTC ---
I was able to reproduce it on 176972. I did a 64 bit build on linux. It
reproduces with -m32, but not without.

[Bug tree-optimization/49911] vrp2 + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.08.01 08:33:31
     Ever Confirmed|0                           |1

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-01 08:33:31 UTC ---
Ok, reproduced on a linux host.  It's quite obvious:

void jsop_setelem(bool, int) (bool y, int z)
{
  RegisterID SR.6;

<bb 2>:
  if (y_1(D) != 0)
    goto <bb 5>;
  else
    goto <bb 3>;

<bb 3>:
  SR.6_11 = (RegisterID) z_3(D);
  if (SR.6_11 <= 45)

the conversion truncates z_3 to precision 3, so it's not VRPs fault here.

It seems to be SRAs fault which replaces D.1809.offset_ with a register of
type RegisterID, then having to insert a not useless conversion (which it
should _never_ need - it's a sign of a bug):

  D.1809.offset_ = z_3(D);
  address.0_7 = (unsigned int) z_3(D);
  if (address.0_7 <= 45)

  D.1816_11 = (RegisterID) z_3(D);
             ^^^^^^^^^^^^^^ here
  SR.6_6 = D.1816_11;
  address.0_7 = (unsigned int) z_3(D);
  if (address.0_7 <= 45)

Now, then comes along DOM and replaces

Optimizing statement address.0_7 = (unsigned int) z_3(D);
LKUP STMT address.0_7 = nop_expr z_3(D)
          address.0_7 = (unsigned int) z_3(D);
FIND: SR.6_11
  Replaced redundant expr '(unsigned int) z_3(D)' with 'SR.6_11'
==== ASGN address.0_7 = SR.6_11
Optimizing statement if (address.0_7 <= 45)
  Replaced 'address.0_7' with variable 'SR.6_11'

for some other reason ...

[Bug tree-optimization/49911] SRA + DOM + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org
            Summary|vrp2 + -fstrict-enums       |SRA + DOM + -fstrict-enums
                   |incorrectly remove          |incorrectly remove
                   |predicate                   |predicate

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-01 08:34:04 UTC ---
I'm looking into the DOM problem - martin, can you look at the SRA bug?

[Bug tree-optimization/49911] SRA + DOM + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-01 08:41:40 UTC ---
Ok, I misread.  The enum type _does_ have precision 32, even with
-fstrict-enums:

 <enumeral_type 0x7ffff5b46b28 RegisterID
    type <integer_type 0x7ffff5b46bd0 unsigned int public unsigned SI
        size <integer_cst 0x7ffff7ed3dc0 constant 32>
        unit size <integer_cst 0x7ffff7ed3de0 constant 4>
        align 32 symtab 0 alias set -1 canonical type 0x7ffff5b46bd0 precision
3 min <integer_cst 0x7ffff5b51380 0> max <integer_cst 0x7ffff5b513a0 7>>
    unsigned SI size <integer_cst 0x7ffff7ed3dc0 32> unit size <integer_cst
0x7ffff7ed3de0 4>
    align 32 symtab 0 alias set -1 canonical type 0x7ffff5b46b28 precision 32
min <integer_cst 0x7ffff5b2e480 0> max <integer_cst 0x7ffff5b513c0 7>

so it's the middle-end/VRP mismatch I suspected in comment #1.

Still SRA should probably not produce enum kind replacements but always
integer kind ones.

So, Eric - are you still objecting to make VRP and the middle-end aligned
by ignoring TYPE_MIN/MAX_VALUE in VRP?

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Summary|SRA + DOM + -fstrict-enums  |SRA + DOM + VRP +
                   |incorrectly remove          |-fstrict-enums incorrectly
                   |predicate                   |remove predicate

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-01 08:44:26 UTC ---
See http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00741.html

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-01 08:49:30 UTC ---
So the issue here is that enum types with non-canonical TYPE_MIN/MAX_VALUE
leak from storage representation (union StateRemat) via SRA as register
variables into the IL.  Is that something that cannot happen for Ada because
it is also careful to not use such types in storage representations?

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-01 09:05:38 UTC ---
verifier patch that would catch at least computation results (but not loads):

Index: gcc/tree-cfg.c
===================================================================
--- gcc/tree-cfg.c      (revision 176998)
+++ gcc/tree-cfg.c      (working copy)
@@ -3241,6 +3314,16 @@ verify_gimple_assign_unary (gimple stmt)
       return true;
     }

+  if (INTEGRAL_TYPE_P (lhs_type)
+      && (!tree_int_cst_equal (TYPE_MIN_VALUE (lhs_type),
+                              lower_bound_in_type (lhs_type, lhs_type))
+         || !tree_int_cst_equal (TYPE_MAX_VALUE (lhs_type),
+                                 upper_bound_in_type (lhs_type, lhs_type))))
+    {
+      error ("register with non-canonical bounds");
+      return true;
+    }
+
   /* First handle conversions.  */
   switch (rhs_code)
     {
@@ -3397,6 +3480,16 @@ verify_gimple_assign_binary (gimple stmt
       return true;
     }

+  if (INTEGRAL_TYPE_P (lhs_type)
+      && (!tree_int_cst_equal (TYPE_MIN_VALUE (lhs_type),
+                              lower_bound_in_type (lhs_type, lhs_type))
+         || !tree_int_cst_equal (TYPE_MAX_VALUE (lhs_type),
+                                 upper_bound_in_type (lhs_type, lhs_type))))
+    {
+      error ("register with non-canonical bounds");
+      return true;
+    }
+
   /* First handle operations that involve different types.  */
   switch (rhs_code)
     {


shows that the IL after SRA is broken:

t.ii: In function 'void jsop_setelem(bool, int)':
t.ii:32:6: error: register with non-canonical bounds
D.1816_11 = (RegisterID) z_3(D);

t.ii:32:6: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rafael.espindola at gmail dot com]

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

--- Comment #10 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-08-04 18:59:20 UTC ---
Created attachment 24919
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24919
test patch

I ported 
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00741.html
to gcc 4.5 and was able to to build a working firefox in the environment that
mozilla's bots use.
Thanks!

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-08-06 15:58:47 UTC ---
> So, Eric - are you still objecting to make VRP and the middle-end aligned
> by ignoring TYPE_MIN/MAX_VALUE in VRP?

Just to give a bit of context to the reader: this problem bit the Ada compiler
since VRP had been introduced in 2004.  At the time, the consensus was that the
Ada compiler was lying to the middle-end, because objects of type T could have
values that are outside [TYPE_MIN_VALUE:TYPE_MAX_VALUE] in some cases and this
breaks an invariant of the middle-end.  So we changed the Ada compiler in 2009.

If it appears that the previous consensus was short-sighted and should now be
reversed, fine with me, but please document what TYPE_MIN_VALUE/TYPE_MAX_VALUE
mean under the new one.  And if they don't mean anything, then remove them.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-08-06 16:08:16 UTC ---
> So the issue here is that enum types with non-canonical TYPE_MIN/MAX_VALUE
> leak from storage representation (union StateRemat) via SRA as register
> variables into the IL.  Is that something that cannot happen for Ada because
> it is also careful to not use such types in storage representations?

Yes, I think so, only index types of arrays have non-canonical bounds now.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-08-11 12:33:44 UTC ---
(In reply to comment #6)
> Still SRA should probably not produce enum kind replacements but always
> integer kind ones.
> 

I see, what would be the best way of obtaining the proper pure integer
type from an ENUMERAL_TYPE (or its TREE_TYPE)?  Poking around in
tree.h did not reveal anything obvious so far...

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-11 13:37:00 UTC ---
(In reply to comment #13)
> (In reply to comment #6)
> > Still SRA should probably not produce enum kind replacements but always
> > integer kind ones.
> > 
> 
> I see, what would be the best way of obtaining the proper pure integer
> type from an ENUMERAL_TYPE (or its TREE_TYPE)?  Poking around in
> tree.h did not reveal anything obvious so far...

build_nonstandard_integer_type (TYPE_PRECISION (enum_type), TYPE_UNSINGED
(enum_type));

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-11 13:41:24 UTC ---
(In reply to comment #11)
> > So, Eric - are you still objecting to make VRP and the middle-end aligned
> > by ignoring TYPE_MIN/MAX_VALUE in VRP?
> 
> Just to give a bit of context to the reader: this problem bit the Ada compiler
> since VRP had been introduced in 2004.  At the time, the consensus was that the
> Ada compiler was lying to the middle-end, because objects of type T could have
> values that are outside [TYPE_MIN_VALUE:TYPE_MAX_VALUE] in some cases and this
> breaks an invariant of the middle-end.  So we changed the Ada compiler in 2009.
> 
> If it appears that the previous consensus was short-sighted and should now be
> reversed, fine with me, but please document what TYPE_MIN_VALUE/TYPE_MAX_VALUE
> mean under the new one.  And if they don't mean anything, then remove them.

No, they still mean "nothing", but VRP assumes they are the canonical
value according to precision/signedness.  Which C and C++ do not follow.
Unfortunately the C and C++ maintainers do not care (and probably have
a harder job "fixing" this because they lack the nice separation of
the "real" frontend and the interface to GENERIC).

As they mean "nothing" I would like to make VRP not assume anything about
them (and VRP is really the only one caring for TYPE_MIN/MAX_VALUE apart from
array domain uses).

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-08-12 08:01:36 UTC ---
> No, they still mean "nothing", but VRP assumes they are the canonical
> value according to precision/signedness.  Which C and C++ do not follow.
> Unfortunately the C and C++ maintainers do not care (and probably have
> a harder job "fixing" this because they lack the nice separation of
> the "real" frontend and the interface to GENERIC).

They certainly used to mean something, so it would be interesting to know when
they stopped doing so.  The existence of -fstrict-enums is an evidence.

> As they mean "nothing" I would like to make VRP not assume anything about
> them (and VRP is really the only one caring for TYPE_MIN/MAX_VALUE apart from
> array domain uses).

The folder cares (or used to care), in particular the range code.

In any case, this particular problem is more of a SRA bug in my opinion.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rafael.espindola at gmail dot com]

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

--- Comment #17 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-08-17 21:31:43 UTC ---
Created attachment 25041
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25041
gcc 4.5 backport

I have tried porting the vrp patch to 4.5. It works out of the box on 32 bits,
but for 64 I had to backport the fix that sign extends size types too.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[jamborm at gcc dot gnu.org]

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

--- Comment #18 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-09-05 16:35:21 UTC ---
Created attachment 25199
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25199
Patch preventing SRA from creating enumeration type replacements

I'm currently testing this patch which will change the type of enum
components it decides to scalarize to the corresponding integer.  I
have verified the type of the replacement is one.

I've lost the track of whether anything else needs to be done to close
this bug, though.  Should the patch be applied to the 4.6 and 4.5
branches too (assuming it passes testing there)?

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rafael.espindola at gmail dot com]

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

--- Comment #19 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-09-05 17:14:29 UTC ---
> I've lost the track of whether anything else needs to be done to close
> this bug, though.  Should the patch be applied to the 4.6 and 4.5
> branches too (assuming it passes testing there)?

I would love to see this fixed in 4.5, as in there there is no
-fno-strict-enums to hide the bug in there.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-06 07:30:11 UTC ---
(In reply to comment #18)
> Created attachment 25199 [details]
> Patch preventing SRA from creating enumeration type replacements
> 
> I'm currently testing this patch which will change the type of enum
> components it decides to scalarize to the corresponding integer.  I
> have verified the type of the replacement is one.
> 
> I've lost the track of whether anything else needs to be done to close
> this bug, though.  Should the patch be applied to the 4.6 and 4.5
> branches too (assuming it passes testing there)?

I think so, at least if it solves the testcase in this bug.  Not exposing
extra enum typed registers to VRP is definitely a good thing.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[jamborm at gcc dot gnu.org]

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

--- Comment #21 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-09-07 14:25:45 UTC ---
Author: jamborm
Date: Wed Sep  7 14:25:39 2011
New Revision: 178639

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178639
Log:
2011-09-07  Martin Jambor  <mjambor@suse.cz>

    PR tree-optimization/49911
    * tree-sra.c (analyze_access_subtree): Change type of to-be-replaced
    enumerations to the corresponding plain integer type.

    * testsuite/g++.dg/tree-ssa/pr49911.C: New test.


Added:
    trunk/gcc/testsuite/g++.dg/tree-ssa/pr49911.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-sra.c

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[rafael.espindola at gmail dot com]

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

--- Comment #22 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-09-07 14:58:57 UTC ---
Thanks!

>     * testsuite/g++.dg/tree-ssa/pr49911.C: New test.

I think you forgot to add -fstrict-enums to the command line in the test.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[jamborm at gcc dot gnu.org]

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

--- Comment #23 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-09-07 15:43:30 UTC ---
(In reply to comment #22)
> Thanks!
> 
> >     * testsuite/g++.dg/tree-ssa/pr49911.C: New test.
> 
> I think you forgot to add -fstrict-enums to the command line in the test.

Thanks for the notification, I've corrected that mistake in revision 178642.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[jamborm at gcc dot gnu.org]

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

--- Comment #24 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-09-08 13:58:39 UTC ---
Author: jamborm
Date: Thu Sep  8 13:58:30 2011
New Revision: 178693

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178693
Log:
2011-09-08  Martin Jambor  <mjambor@suse.cz>

    PR tree-optimization/49911
    * tree-sra.c (analyze_access_subtree): Change type of to-be-replaced
    enumerations to the corresponding plain integer type.

    * testsuite/g++.dg/tree-ssa/pr49911.C: New test.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/g++.dg/tree-ssa/pr49911.C
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-sra.c

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[jamborm at gcc dot gnu.org]

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

--- Comment #25 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-09-08 17:21:15 UTC ---
Author: jamborm
Date: Thu Sep  8 17:20:52 2011
New Revision: 178701

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178701
Log:
2011-09-08  Martin Jambor  <mjambor@suse.cz>

    PR tree-optimization/49911
    * tree-sra.c (analyze_access_subtree): Change type of to-be-replaced
    enumerations to the corresponding plain integer type.

    * testsuite/g++.dg/tree-ssa/pr49911.C: New test.


Added:
    branches/gcc-4_5-branch/gcc/testsuite/g++.dg/tree-ssa/pr49911.C
Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/tree-sra.c

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

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

--- Comment #26 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-09-09 09:35:09 UTC ---
(In reply to comment #20)
> (In reply to comment #18)
> > 
> > I've lost the track of whether anything else needs to be done to close
> > this bug, though.  Should the patch be applied to the 4.6 and 4.5
> > branches too (assuming it passes testing there)?
> 
> I think so, at least if it solves the testcase in this bug.  Not exposing
> extra enum typed registers to VRP is definitely a good thing.

OK, this is fixed, then.