[Bug c/35489] New: Inaccurate GCC documentation

[adam at irvine dot com]

I'm not sure whether this is the proper method for reporting errors in
the documentation.  However, I believe there is a serious error in the
GCC documentation that needs to be addressed.

The error is at http://gcc.gnu.org/bugs.html#nonbugs_general.  This
section refers to inherent limitations of floating-point types because
most numbers can be represented only approximately.

The problem is that this "non-bug", which is connected to problem
report #323 and has a hyperlink to it, encompasses many other problem
reports that are not accurately described by this documentation
section.  Some are due to the inherent limitations, but others are
actual bugs in which the compiler is generating incorrect instructions
(such as #12331); others are due to a particular floating-point
processor feature that can be defeated with a flag (but it could be
considered a bug that the compiler is not able to take proper advantage
of this feature); still others could marginally be considered "bugs"
because a compiler could, in theory, generate correct code although
expecting it to do so may not be reasonable.

For honesty's sake, since so many problem reports end up with users
being referred to this section, the documentation should accurately
describe the situation (including the fact that there are known bugs
which may be difficult to fix), rather than giving the false
implication that all such problems are the user's fault for doing
something ignorant.  I believe this to be a serious inaccuracy in the
documentation, and one that I think has been leaving users in an
unhelpful state of confusion.


-- 
   Summary: Inaccurate GCC documentation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: adam at irvine dot com


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

[Bug c/35489] Inaccurate GCC documentation

[adam at irvine dot com]

--- Comment #2 from adam at irvine dot com  2008-03-07 00:08 ---
(In reply to comment #1)
> > but others are
> actual bugs in which the compiler is generating incorrect instructions
> (such as #12331);
> 
> That is not incorrect instructions.  Just different than what you are
> expecting. 

I suppose that if the chip has an instruction that would allow it to store the
correct value without losing any precision, and the compiler instead chooses to
generate an instruction that causes the computation to lose precision, that
could be considered "different than what I am expecting", yes.

Actually, I like that response.  I might try to use it myself next time one of
our customers reports a problem.


-- 


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

[Bug ada/57382] New: Illegal type conversion to access-interface-class inside generic not detected

[adam at irvine dot com]

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

Bug ID: 57382
   Summary: Illegal type conversion to access-interface-class
inside generic not detected
   Product: gcc
   Version: 4.5.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at irvine dot com

Created attachment 30170
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30170&action=edit
source code

Inside a generic, GNAT incorrectly accepts a type conversion where the target
type is access Interface_Type'Class and the argument type is a non-access type.

[Bug ada/57383] New: Illegal program not detected, RM 7.3(10.1)

[adam at irvine dot com]

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

Bug ID: 57383
   Summary: Illegal program not detected, RM 7.3(10.1)
   Product: gcc
   Version: 4.5.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at irvine dot com

Created attachment 30171
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30171&action=edit
source code

RM 7.3(10.1) makes it clear that if you declare a private extension that has
the LIMITED keyword, and the full type is a derived type definition, then the
full type definition must also include the LIMITED keyword; it isn't enough for
the full type definition to be limited for other reasons, the keyword has to be
there.  Based on that, the attached source should be rejected, but the error is
not detected.

[Bug ada/16095] Illegal program not detected, accessibility levels, RM 3.10.2(28)

[adam at irvine dot com]

--- Comment #4 from adam at irvine dot com  2010-01-08 00:46 ---
(In reply to comment #2)
> From what I understand:
>   - "access T1" is an access_definition and thus a general access type (RM
> 3.10(12/2))
>   - "Y'Access" is of the type of its context, which should be a general access
> type  (RM 3.10.2(24/1))
>   - An equality operator exists for anonymous access types and is visible
> because it is defined in Standard (RM 4.5.2(7.2/2))
> Note that the current GCC gives no error even on the line you marked with
> "error detected".
> Do you agree that this bug can be closed?

I know this is rather delayed but my attention just got drawn to this bug
report.  In any case, Samuel is wrong.  There is no equality operator on
anonymous access types.  RM 4.5.2(7.2/2) says there is an "=" operator on
universal_access, *for* *use* *with* anonymous access types; but the parameters
of the "=" subprogram have type universal_access, and an 'Access cannot be used
when the expected type is universal_access.  See AC-00164.


-- 


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