* [Bug c++/12581] [3.4 Regression ] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
@ 2003-10-13 3:27 ` pinskia at gcc dot gnu dot org
2003-10-16 16:14 ` ehrhardt at mathematik dot uni-ulm dot de
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2003-10-13 3:27 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |3.4
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression ] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
2003-10-13 3:27 ` [Bug c++/12581] " pinskia at gcc dot gnu dot org
@ 2003-10-16 16:14 ` ehrhardt at mathematik dot uni-ulm dot de
2003-10-22 1:25 ` [Bug c++/12581] [3.4 Regression] " bangerth at dealii dot org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: ehrhardt at mathematik dot uni-ulm dot de @ 2003-10-16 16:14 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
------- Additional Comments From ehrhardt at mathematik dot uni-ulm dot de 2003-10-16 16:13 -------
The testcase basically reduces to:
int f();
__typeof__ (f)() x;
Depending on the priority of the __typeof__ operator relative to the
postfix () operator this is valid or not. The two posibilities are:
(A) declare x as int ( == __typeof__ (f ()) )
(B) get type of f (function returning int) and try to apply the postfix
() to this which is impossible.
(A) would make __typeof__ similar to sizeof, (B) would make it similar to
typeid in C++. The downside of (A) (this is what we currently do) is that
some potentially useful applications of __typeof__ are impossible, e.g.
the one in the original report or this one which is similar:
int f ();
__typeof__ (f()) (*x) (void);
where we try do declare x as a pointer to a function returning int.
However, this is rejected, because due to the higher priority of ()
it is parsed as
__typeof__ ( (f()) (*x) (void) );
i.e. we try to get the type of the invalid unary expression
(f()) (*x) (void) and do nothing with the result. Note that it
is impossible to get the desired result by placing parentheses
in this declaration.
IMHO, this needs a language lawyer. A work around is of course to
use a typedef.
regards Christian
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
2003-10-13 3:27 ` [Bug c++/12581] " pinskia at gcc dot gnu dot org
2003-10-16 16:14 ` ehrhardt at mathematik dot uni-ulm dot de
@ 2003-10-22 1:25 ` bangerth at dealii dot org
2003-10-22 1:27 ` bangerth at dealii dot org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: bangerth at dealii dot org @ 2003-10-22 1:25 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
bangerth at dealii dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2003-10-22 01:24:40
date| |
Summary|[3.4 Regression ] gcc |[3.4 Regression] gcc rejects
|rejects typeof use for the |typeof use for the return
|return type |type
------- Additional Comments From bangerth at dealii dot org 2003-10-22 01:24 -------
A darn good argument against introducing extensions as operators!
I think it can be called a regression, since it used to work. I would bet this is introduced
by the new parser, so I'll tentatively assign it to Mark. He'll know for sure.
I can't help setting this to low priority, though, since I think it's so obscure...
W.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (2 preceding siblings ...)
2003-10-22 1:25 ` [Bug c++/12581] [3.4 Regression] " bangerth at dealii dot org
@ 2003-10-22 1:27 ` bangerth at dealii dot org
2003-11-12 3:14 ` mmitchel at gcc dot gnu dot org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: bangerth at dealii dot org @ 2003-10-22 1:27 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
bangerth at dealii dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (3 preceding siblings ...)
2003-10-22 1:27 ` bangerth at dealii dot org
@ 2003-11-12 3:14 ` mmitchel at gcc dot gnu dot org
2003-11-12 3:16 ` mmitchel at gcc dot gnu dot org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2003-11-12 3:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From mmitchel at gcc dot gnu dot org 2003-11-12 03:14 -------
This is not a bug.
It does not compile with GCC (as opposed to G++) and the manual says:
"A `typeof'-construct can be used anywhere a typedef name could be
used."
If that were standardese, it would say that a typeof construct is a
simple-type-specifier, which is what is implemented in the C++ front end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (4 preceding siblings ...)
2003-11-12 3:14 ` mmitchel at gcc dot gnu dot org
@ 2003-11-12 3:16 ` mmitchel at gcc dot gnu dot org
2003-11-12 12:35 ` gabor dot greif at lucent dot com
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2003-11-12 3:16 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From mmitchel at gcc dot gnu dot org 2003-11-12 03:16 -------
This is not a bug.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (5 preceding siblings ...)
2003-11-12 3:16 ` mmitchel at gcc dot gnu dot org
@ 2003-11-12 12:35 ` gabor dot greif at lucent dot com
2003-11-12 12:43 ` gdr at integrable-solutions dot net
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: gabor dot greif at lucent dot com @ 2003-11-12 12:35 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gabor dot greif at lucent dot com 2003-11-12 12:35 -------
(In reply to comment #4)
> This is not a bug.
I beg your pardon. If I understand your comment #3 correctly,
a __typeof__() can appear "anywhere a typedef name could be used".
A typedef name can certainly appear a the result type of a PTMF type
declaration. So I cannot understand why a typeof construct must not.
This looks illogical to me.
This bug omits some stuff from its parent PR#12577. There I see:
foobar.cpp:35: error: expected unqualified-id
I ask myself why a typeof construct cannot be an unqualified-id?
Also, I think the analysis in comment #1 is completely bogus.
The example mentioned in it does not deal with pointer-to-member-function types
at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (6 preceding siblings ...)
2003-11-12 12:35 ` gabor dot greif at lucent dot com
@ 2003-11-12 12:43 ` gdr at integrable-solutions dot net
2003-11-12 14:03 ` gabor dot greif at lucent dot com
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: gdr at integrable-solutions dot net @ 2003-11-12 12:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at integrable-solutions dot net 2003-11-12 12:43 -------
Subject: Re: [3.4 Regression] gcc rejects typeof use for the return type
"gabor dot greif at lucent dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| I ask myself why a typeof construct cannot be an unqualified-id?
Meaning?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (7 preceding siblings ...)
2003-11-12 12:43 ` gdr at integrable-solutions dot net
@ 2003-11-12 14:03 ` gabor dot greif at lucent dot com
2003-11-12 14:29 ` gdr at integrable-solutions dot net
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: gabor dot greif at lucent dot com @ 2003-11-12 14:03 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gabor dot greif at lucent dot com 2003-11-12 14:03 -------
(In reply to comment #6)
> ...
>
> | I ask myself why a typeof construct cannot be an unqualified-id?
>
> Meaning?
>
> -- Gaby
>
Hmmm, I assume you do not understand what I am meaning. (Your question is a bit
overloaded :-)
Here is what I think. Let's modify my the simplified example:
struct bar
{
void setfoobar(int);
int getfoobar(void) const;
static int (bar::* const getter1)(void) const;
};
template <typename T>
T* JustAPointer(void);
typedef __typeof__(JustAPointer<bar>()->getfoobar()) GETTER_RESULT;
GETTER_RESULT (bar::* const bar::getter1)(void)
const = &bar::getfoobar;
--------------------------------------------------------------------
I strongly assume this is legal _and_ compiles.
GETTER_RESULT is a typedef-name, right?
The new C++ parser only accepts an unqualified-id in that
position, so typedef-name implies unqualified-id.
Now, by statement of Mark (comment #3), a typeof construct can be used
everywhere a typedef-name can occur. So typeof-construct implies typedef-name
(basically), and by transitiveness: typeof-construct implies unqualified-id.
Maybe I am a bit dense today, but I still cannot see what is illegal in the
example in comment #1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (8 preceding siblings ...)
2003-11-12 14:03 ` gabor dot greif at lucent dot com
@ 2003-11-12 14:29 ` gdr at integrable-solutions dot net
2003-11-12 16:14 ` mmitchel at gcc dot gnu dot org
2003-11-13 8:23 ` gabor dot greif at lucent dot com
11 siblings, 0 replies; 13+ messages in thread
From: gdr at integrable-solutions dot net @ 2003-11-12 14:29 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at integrable-solutions dot net 2003-11-12 14:29 -------
Subject: Re: [3.4 Regression] gcc rejects typeof use for the return type
"gabor dot greif at lucent dot com" <gcc-bugzilla@gcc.gnu.org> writes:
| ------- Additional Comments From gabor dot greif at lucent dot com 2003-11-12 14:03 -------
| (In reply to comment #6)
| > ...
| >
| > | I ask myself why a typeof construct cannot be an unqualified-id?
| >
| > Meaning?
| >
| > -- Gaby
| >
|
| Hmmm, I assume you do not understand what I am meaning. (Your question is a bit
| overloaded :-)
Thnks for successfully resolving the call :-)
| Here is what I think. Let's modify my the simplified example:
|
|
|
| struct bar
| {
| void setfoobar(int);
| int getfoobar(void) const;
| static int (bar::* const getter1)(void) const;
| };
|
| template <typename T>
| T* JustAPointer(void);
|
| typedef __typeof__(JustAPointer<bar>()->getfoobar()) GETTER_RESULT;
|
| GETTER_RESULT (bar::* const bar::getter1)(void)
| const = &bar::getfoobar;
| --------------------------------------------------------------------
|
| I strongly assume this is legal _and_ compiles.
Given that this is a GNU extension, it is valid construct only if the
doc says so :-) But I can see your point.
As an aside, the next version of C++ will have something like typeof
called "decltype", which is a "reference preserving typeof". The
current draft stabdardese says that decltype(<some-expression>) is a
simple-type-specifier -- which is not the same as an unqualified-id.
| GETTER_RESULT is a typedef-name, right?
| The new C++ parser only accepts an unqualified-id in that
| position, so typedef-name implies unqualified-id.
|
| Now, by statement of Mark (comment #3), a typeof construct can be used
| everywhere a typedef-name can occur. So typeof-construct implies typedef-name
| (basically), and by transitiveness: typeof-construct implies unqualified-id.
I can't follow. Mark was saying that in standardese, it would be a
simple-type-specifier (and I agree with him), and a
simple-type-specifier does not imply an unqualified name.
| Maybe I am a bit dense today, but I still cannot see what is illegal in the
| example in comment #1.
I can see an implementation problem but I can't see a problem from user
point-of-view. And with compatibility with decltype, I would accept
the code, but I'm not going to fix it now so I can't revert Mark's
decision. I can just suggest a feature-request.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (9 preceding siblings ...)
2003-11-12 14:29 ` gdr at integrable-solutions dot net
@ 2003-11-12 16:14 ` mmitchel at gcc dot gnu dot org
2003-11-13 8:23 ` gabor dot greif at lucent dot com
11 siblings, 0 replies; 13+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2003-11-12 16:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From mmitchel at gcc dot gnu dot org 2003-11-12 16:14 -------
There are two pieces of code in this PR; comment #1 and comment #2.
(1) In comment #2, GCC does not accept the code, either. That's because:
typedef int (F)();
F() x;
is not syntactically valid either.
(3) In the example in comment #1, the problem is more complex. The "typeof"
keyword, like the "sizeof" keyword, can be used in two alternative productions:
sizeof type-id
sizeof unary-expression
In comment #1, it is the second production which is used. Note that this second
production is *not* "sizeof (unary-expression)"; the unary-expression is not
parenthesized.
One alternative for a unary-expression is a postfix-expression.
A postfix-expression can have the form "x (...)".
That is the syntactic form of the line in comment #1: (Just...) (....). The
parser becomes unhappy when it sees "bar::*" because "*" is not a valid identifier.
(This case is analogous to "sizeof f ()" which is valid C/C++.)
To try to recover from the case where the arguments to the function call are not
valid would require a considerable amount of code and a slower parser.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/12581] [3.4 Regression] gcc rejects typeof use for the return type
2003-10-11 16:26 [Bug c++/12581] New: [3.4 Regression ] gcc rejects typeof use for the return type pinskia at gcc dot gnu dot org
` (10 preceding siblings ...)
2003-11-12 16:14 ` mmitchel at gcc dot gnu dot org
@ 2003-11-13 8:23 ` gabor dot greif at lucent dot com
11 siblings, 0 replies; 13+ messages in thread
From: gabor dot greif at lucent dot com @ 2003-11-13 8:23 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gabor dot greif at lucent dot com 2003-11-13 08:22 -------
(In reply to comment #9)
> There are two pieces of code in this PR; comment #1 and comment #2.
>
No. There is the PR description too. _That_ is the problem. As I mentioned
before, comment #1 (as viewed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581) is bogus IMHO. I see no
connection between the Description and comment #1. I am not intending to follow
on for reasons of impertinence, but let's not get sidetracked by those comments
and focus on the PR which deals with a PTMF type that has a typeof in the result
position. All g++ versions (going back till egcs) supported that, but gcc3.4
breaks (I did not check 3.3).
Mark, in this case your analogy typeof<-->sizeof is hinking, because a sizeof
expression cannot stand in the result-type position of a PTMF type. Also, there
is not paren-less version ot typeof.
In the meantime I found a workaround that looks like this:
-----------------------------------
...
template <typename T> struct Id { typedef T is; };
Id<__typeof__(JustAPointer<bar>()->getfoobar())>::is (bar::* const
bar::getter1)(void)
const = &bar::getfoobar;
-----------------------------------
(The trick is to use typeof inside of the <>, where the parser seems to readily
accept it.)
I can hardly believe that parsing the latter is easier that what is in the
Description :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12581
^ permalink raw reply [flat|nested] 13+ messages in thread