https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #20 from Harald van Dijk ---
(In reply to Kaz Kylheku from comment #19)
Needless to say I still disagree, but I interpreted your comment #17 as
suggesting this aspect of the discussion is neither necessary nor useful for
this bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #19 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Kaz Kylheku from comment #17)
> > The standrad does not define the conversion at the *type* level.
> > ...
> > The program is strictly conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #18 from Harald van Dijk ---
(In reply to Kaz Kylheku from comment #17)
> The standrad does not define the conversion at the *type* level.
> ...
> The program is strictly conforming because it has no problem with type.
The DRs I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #17 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Joseph S. Myers from comment #11)
> > I think that simply failing to say whether a value of type X may be
> > converted to type Y is clearly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #16 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #15)
> In the cases where there is no statement either way, the behavior is
> undefined as a property of the translation unit (not just of the execution):
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #15 from Joseph S. Myers ---
There are several statements such as "Any pointer type may be converted to an
integer type." and "A pointer to an object type may be converted to a pointer
to a different object type.", that allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #14 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #13 from Kaz Kylheku ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #12 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #10)
> Sorry, sent my earlier comment too soon.
>
> (In reply to Joseph S. Myers from comment #8)
> > I believe conversions between function and object pointers are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #11 from Joseph S. Myers ---
I think that simply failing to say whether a value of type X may be converted
to type Y is clearly enough for it at least to be unspecified whether or when
such conversions are possible in a cast at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #10 from Harald van Dijk ---
Sorry, sent my earlier comment too soon.
(In reply to Joseph S. Myers from comment #8)
> I believe conversions between function and object pointers are undefined as
> a property of the translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #9 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #8)
> "rejects", in the ISO C sense, only applies to errors and pedwarns in GCC;
> not to warnings conditional on -pedantic (of which there are also some, but
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #8 from Joseph S. Myers ---
"rejects", in the ISO C sense, only applies to errors and pedwarns in GCC; not
to warnings conditional on -pedantic (of which there are also some, but which
don't turn into errors with -pedantic).
If you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #7 from Kaz Kylheku ---
Also, it would be useful for the documentation to list all the -W-* options
that are implied by -Wpedantic.
The function/object pointer conversion diagnostics, unfortunately, are tied to
-Wpedantic itself,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #6 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #5)
> The -pedantic documentation was updated to reflect reality - that the option
> is about more than just when diagnostics are required by ISO C ("forbidden
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #5 from Joseph S. Myers ---
The -pedantic documentation was updated to reflect reality - that the option is
about more than just when diagnostics are required by ISO C ("forbidden
extensions" can be taken, in the C case, as meaning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #3 from Kaz Kylheku ---
(In reply to Andrew Pinski from comment #2)
> Actually it is a required diagnostic. See PR 11234 for explanation on how.
> This was changed a little over 20 years ago explictly to reject this because
> it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/legacy-ml/gcc-patches/2004-01/msg00599.html
20 matches
Mail list logo
