[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds

[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds

[reichelt at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|reichelt at gcc dot gnu dot |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|REOPENED                    |NEW


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

[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2005-01-07 13:14 -------
A testcase never made it to testsuite. :-(

Well, the ICE was fixed in gcc 3.2.1, I don't think we need a testcase
for that one.

The other issue is the testcase from comment #4:

---------------------------------------------------------------------
template <typename> struct X {
    enum { N = 10 };
    int items[N+1];
};
template <typename A, typename B> int operator+(A,B);
X<int> x;
----------------------------------------------------------------------

The question is whether this is valid code or not.
There are two issues involved:

a) operator+ is defined *after* the definition of X.
   Do we really have to take it into account for overload resolution
   to compute N+1?
   Mark's opinion (as stated in private email) to this is "no".
   This would render the code valid.
   Alas, gcc *does* take operator+ into account. And that's a bug.

b) Because gcc behaves wrong in a) we end up with a second problem:
   Anonymous types cannot be template parameters. That's not an SFINAE
   problem, this should be diagnosed as a hard error.
   However, gcc 3.4.0 - 3.4.3 treat this as an SFINAE case, thus
   accepting the code (although for the wrong reason).

   Mark's patch for PR17413 changed that behavior for mainline
   (maybe it will be backported to the 3.4 branch). So the code
   is again rejected - because of the bug in a).


To make things short:
We have a rejects-valid bug in mainline. To the user this is a
regression from gcc 3.4.3, although the bug was latent in the compiler
and papered over by a second bug (PR 17413).


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com
             Status|RESOLVED                    |REOPENED
           Keywords|                            |monitored, rejects-valid
      Known to fail|                            |2.95.3 3.3.5 4.0.0
      Known to work|                            |3.4.0 3.4.3
         Resolution|FIXED                       |
            Summary|User-defined operator+ and  |[4.0 regression] User-
                   |use of enum values in       |defined operator+ and use of
                   |computation of array bounds |enum values in computation
                   |                            |of array bounds
   Target Milestone|---                         |4.0.0


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

[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-02-10 08:00 -------
John Spicer and I have had a long talk about this issue, and we're of differring
opinions.  There's going to be a core issue about this, but until that's
resolved I don't think we know whether to call this a rejects-valid or
not-a-bug.  I think it's unwise to make changes here until we know the outcome
of that discussion, so I've removed the target milestone.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.0                       |---


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

[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-02-10 08:15 -------
Let's suspend it then. It's still questionable whether we should let GCC change 
behaviour between 3.4 and 4.0 on this unresolved issue, but I guess that Mark 
had fixed it back to the previous behaviour, had it been easy to do. We can't 
always win...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


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

[Bug c++/6273] [4.0/4.1 regression] User-defined operator+ and use of enum values in computation of array bounds

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-23 03:47 -------
(In reply to comment #7)
> ---------------------------------------------------------------------
> template <typename> struct X {
>     enum { N = 10 };
>     int items[N+1];
> };
> template <typename A, typename B> int operator+(A,B);
> X<int> x;
> ----------------------------------------------------------------------

Actually I think there is two different bugs here, the above code is vaild I think because operators just 
like functions have an overloaded set for lookup which is PR 2922.
The testcase which is questionable is:
template <typename A, typename B> int operator+(A,B);
template <typename> struct X {
    enum a{ N = 10 };
    int items[N+1];
};
X<int> x;

-- 


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

[Bug c++/6273] [DR 502] Dependency of nested enumerations and enumerators

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2005-09-17 20:03 -------
The code snippet from comment #4 is now accepted on the 4.0 branch
and mainline due to Mark's patch for PR21514:

http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00996.html

The anonymous enum is again treated via SFINAE.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|monitored                   |
            Summary|[4.0/4.1 regression] User-  |[DR 502] Dependency of
                   |defined operator+ and use of|nested enumerations and
                   |enum values in computation  |enumerators
                   |of array bounds             |


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

[Bug c++/6273] [DR 502] Dependency of nested enumerations and enumerators

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2005-09-17 20:27 -------
Here's a link to DR 502:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#502


-- 


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

[Bug c++/6273] [DR 502] Dependency of nested enumerations and enumerators

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-09-17 20:29 -------
Subject: Re:  [DR 502] Dependency of nested enumerations and enumerators

"reichelt at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| The code snippet from comment #4 is now accepted on the 4.0 branch
| and mainline due to Mark's patch for PR21514:
| 
| http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00996.html
| 
| The anonymous enum is again treated via SFINAE.

Notice however, that this is not a committee decision.  It is not 
clear at this moment whether linkage should play any role in SFNINAE
or not -- but the previous behaviour was just annoying.

-- Gaby


-- 


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