[Bug c/39985] Type qualifiers not actually ignored on function return type

2009-11-21 Thread gcc at magfr dot user dot lysator dot liu dot se


--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se  
2009-11-21 12:24 ---
Created an attachment (id=19074)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19074&action=view)
Test case - g++ -Wignored-qualifiers test.C gives confusing results

In C++ it becomes even worse since the types are used more.

As it stands right now it becomes ridiculous:

$ g++ -Wignored-qualifiers test.C
test.C:12: warning: type qualifiers ignored on function return type
test.C:12: error: conflicting return type specified for ‘virtual const int
D1::F()’
test.C:5: error:   overriding ‘virtual int B1::F()’
test.C:20: warning: type qualifiers ignored on function return type
test.C:27: error: conflicting return type specified for ‘virtual int D2::F()’
test.C:20: error:   overriding ‘virtual const int B2::F()’

Are the type qualifiers ignored or are they not?


-- 


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



[Bug c/39985] Type qualifiers not actually ignored on function return type

2009-11-22 Thread jsm28 at gcc dot gnu dot org


--- Comment #2 from jsm28 at gcc dot gnu dot org  2009-11-22 20:24 ---
If you wish to report a C++ bug, it needs to have component "c++" and be
a separate bug from any bug report for C front-end issues; comments
about possible C++ front-end issues in "c" bugs are irrelevant except insofar
as they illuminate questions of what the C front end should do.

For C, the qualifiers are ignored as far as standard terms are concerned.
Whether typeof applied to an rvalue in GNU C has a qualified types is
fundamentally confused at present; my inclination is that we should
eliminate the inconsistent attempts to give rvalues qualified types in
some cases, and say that if the operand of typeof is not an lvalue it
never has a qualified type.


-- 


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



[Bug c/39985] Type qualifiers not actually ignored on function return type

2009-11-26 Thread anders at kaseorg dot com


--- Comment #3 from anders at kaseorg dot com  2009-11-27 07:33 ---
> my inclination is that we should eliminate the inconsistent attempts to give
> rvalues qualified types in some cases, and say that if the operand of typeof
> is not an lvalue it never has a qualified type.

Should typeof ever return a qualified type?  It is easy to add qualifiers to a
type if they are desired (const typeof(foo)), but seems difficult to remove
them.

For example, seemingly reasonable macros like
  #define MAX(__x, __y) ({   \
  typeof(__x) __ret = __x;   \
  if (__y > __ret) __ret = __y;  \
  __ret; \
  })
currently fail when given a qualified argument:
  const int c = 42;
  MAX(c, 17);  /* error: assignment of read-only variable ‘__ret’ */

This bug report was motivated by my attempts to fix a macro like this, by
replacing typeof(__x) with something that strips qualifiers.  These all fail to
strip qualifiers:
  typeof( ({ __x; }) )
  typeof( ((typeof(__x)(*)(void)) 0)() )
  typeof( (typeof(__x)) (__x) )
This seems to work, but only for numeric and pointer types:
  typeof( (typeof(__x)) 0 )
This succeeds at stripping qualifiers for numeric types, but for some reason it
promotes char and short to int, and it fails to strip qualifiers for
non-numeric types:
  typeof( 1 ? (__x) : (__x) )

Much confusion would be avoided if typeof(__x) just stripped qualifiers to
begin with.


-- 


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



[Bug c/39985] Type qualifiers not actually ignored on function return type

2017-07-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |polacek at redhat dot 
com
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Anders Kaseorg from comment #3)
> > my inclination is that we should eliminate the inconsistent attempts to give
> > rvalues qualified types in some cases, and say that if the operand of typeof
> > is not an lvalue it never has a qualified type.
> 
> Should typeof ever return a qualified type?  It is easy to add qualifiers to
> a type if they are desired (const typeof(foo)), but seems difficult to
> remove them.
> 
> For example, seemingly reasonable macros like
>   #define MAX(__x, __y) ({   \
>   typeof(__x) __ret = __x;   \
>   if (__y > __ret) __ret = __y;  \
>   __ret; \
>   })
> currently fail when given a qualified argument:
>   const int c = 42;
>   MAX(c, 17);  /* error: assignment of read-only variable ‘__ret’ */
> 
> This bug report was motivated by my attempts to fix a macro like this, by
> replacing typeof(__x) with something that strips qualifiers.  These all fail
> to strip qualifiers:
>   typeof( ({ __x; }) )
>   typeof( ((typeof(__x)(*)(void)) 0)() )
>   typeof( (typeof(__x)) (__x) )
> This seems to work, but only for numeric and pointer types:
>   typeof( (typeof(__x)) 0 )
> This succeeds at stripping qualifiers for numeric types, but for some reason
> it promotes char and short to int, and it fails to strip qualifiers for
> non-numeric types:
>   typeof( 1 ? (__x) : (__x) )
> 
> Much confusion would be avoided if typeof(__x) just stripped qualifiers to
> begin with.

Related: bug 65455. Marek Polacek has been posting patches to the gcc-patches
mailing list towards solving this; latest message in the chain was:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01146.html
Assigning this to him since he's already been working on it anyways.

[Bug c/39985] Type qualifiers not actually ignored on function return type

2017-07-31 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

--- Comment #5 from joseph at codesourcery dot com  ---
In C, in C11 mode, type qualifiers are completely ignored on function 
return types, including not affecting type compatibility, after my commit:

r236231 | jsm28 | 2016-05-13 21:35:39 + (Fri, 13 May 2016) | 46 lines

Implement C11 DR#423 resolution (ignore function return type qualifiers).

[Bug c/39985] Type qualifiers not actually ignored on function return type

2021-06-12 Thread muecker at gwdg dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #10 from Martin Uecker  ---

It seems this is fixed in 11.1:

https://gcc.godbolt.org/z/nMqz8sG1v

[Bug c/39985] Type qualifiers not actually ignored on function return type

2019-01-29 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

Eric Gallager  changed:

   What|Removed |Added

 CC||gcc at magfr dot 
user.lysator.liu.
   ||se, joseph at codesourcery dot 
com

--- Comment #6 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #5)
> In C, in C11 mode, type qualifiers are completely ignored on function 
> return types, including not affecting type compatibility, after my commit:
> 
> r236231 | jsm28 | 2016-05-13 21:35:39 + (Fri, 13 May 2016) | 46 lines
> 
> Implement C11 DR#423 resolution (ignore function return type qualifiers).

So can this be closed then?

[Bug c/39985] Type qualifiers not actually ignored on function return type

2019-01-30 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

--- Comment #7 from joseph at codesourcery dot com  ---
On Wed, 30 Jan 2019, egallager at gcc dot gnu.org wrote:

> So can this be closed then?

A change *in C11 mode* has nothing to do with possible imprecision of the 
wording of a diagnostic message outside C11 mode.

[Bug c/39985] Type qualifiers not actually ignored on function return type

2019-03-15 Thread pskocik at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

pskocik at gmail dot com changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #8 from pskocik at gmail dot com ---
(In reply to Eric Gallager from comment #6)
> (In reply to jos...@codesourcery.com from comment #5)
> > In C, in C11 mode, type qualifiers are completely ignored on function 
> > return types, including not affecting type compatibility, after my commit:
> > 
> > r236231 | jsm28 | 2016-05-13 21:35:39 + (Fri, 13 May 2016) | 46 lines
> > 
> > Implement C11 DR#423 resolution (ignore function return type qualifiers).
> 
> So can this be closed then?

As of 8.2, it doesn't appear to work properly yet.

It looks like the top level qualifs on the return type aren't being ignored
if the return type is sealed in a typedef or __typeof.

typedef int const ic_tp;
int const f(); //ignores the const here
ic_tp f(); //breaks because the const isn't ignored here

Same with:

int const f(); //ignored here
__typeof(int const) f(); //not ignored here

The examples in Godbolt: https://gcc.godbolt.org/z/GVvkmJ

[Bug c/39985] Type qualifiers not actually ignored on function return type

2019-03-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

--- Comment #9 from Jonathan Wakely  ---
Which is PR 89734, right?

[Bug c/39985] Type qualifiers not actually ignored on function return type

2023-05-16 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #11 from Marek Polacek  ---
Closing as fixed then.