public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/5344: gcc 3.0.3 optimizer generates incorrect code
@ 2002-02-12 19:09 anguiano
  0 siblings, 0 replies; 3+ messages in thread
From: anguiano @ 2002-02-12 19:09 UTC (permalink / raw)
  To: cosmos, gcc-bugs, gcc-prs, nobody

Synopsis: gcc 3.0.3 optimizer generates incorrect code

State-Changed-From-To: open->closed
State-Changed-By: anguiano
State-Changed-When: Tue Feb 12 19:09:48 2002
State-Changed-Why:
    Bogus bug report.  Problem exists only in author's source code.  The problem in the code is that the variable temp1 is unsigned.
    The author assumes temp1 can be negative.  Sections of code dealing
    with temp1 < 0 are optimized away because they are not possible.  If diff is
    used instead, the generated code is different, because diff is signed
    and therefore can be negative.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5344


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: optimization/5344 gcc 3.0.3 optimizer generates incorrect code
@ 2002-02-12 11:16 Ricardo Anguiano
  0 siblings, 0 replies; 3+ messages in thread
From: Ricardo Anguiano @ 2002-02-12 11:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR optimization/5344; it has been noted by GNATS.

From: Ricardo Anguiano <anguiano@codesourcery.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, cosmos@visi.com,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: optimization/5344 gcc 3.0.3 optimizer generates incorrect code
Date: 12 Feb 2002 11:12:39 -0800

 Greetings,
 
 This email is a response to GNATS submission #5344.  I do not have
 access to change the GNATS database.
 
 Running the C code by hand reveals the binary search algorithm
 implementation to be incorrect: It doesn't handle the following case
 well:
         array of size 1
 	containing fd=34
 	searching for fd=40
 
 The variable *p_i ends up the the value of 2.
 
 The main problem with this code is that the variable tmp1 is unsigned.
 The Writer assumes temp1 can be negative.  Sections of code dealing
 with temp1 < 0 are optimized away they are not possible.  If diff is
 used instead, the generated code is different, because diff is signed
 and therefore can be negative.
 
 This code reveals no bugs in the compiler.  Please don't make compiler
 maintainers debug your code.  Use a standard library function like
 bsearch.
 
 A paraphrase from \emph{Programming Pearls}, second edition, by Jon
 Bentley, column 4, "Writing Correct Programs", p. 34:
 
      "Most programmers think that ... writing [binary search] s easy.
      They're wrong....
 
      "Given ample time, only about ten percent of professional
      programmers were able to get this small program right.  But they
      aren't the only ones to find this task difficult: in the history
      of Section 6.2.1 of his \emph{Sorting and Searching}, Knuth
      points out that while the first binary search was published in
      1946, the first published binary search without bugs did not
      appear until 1962."
 
 Thanks,
 Ricardo Anguiano             anguiano@codesourcery.com
 CodeSourcery, LLC            http://www.codesourcery.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* optimization/5344: gcc 3.0.3 optimizer generates incorrect code
@ 2002-01-09 22:46 cosmos
  0 siblings, 0 replies; 3+ messages in thread
From: cosmos @ 2002-01-09 22:46 UTC (permalink / raw)
  To: gcc-gnats


>Number:         5344
>Category:       optimization
>Synopsis:       gcc 3.0.3 optimizer generates incorrect code
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 09 22:46:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Clay Harris
>Release:        3.0.3
>Organization:
>Environment:
System: Linux vorlon.zahadum.world 2.4.16 #2 SMP Wed Dec 12 02:10:51 CST 2001 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../configure 
>Description:
	Compiling the following program with 'gcc -O2 -S search_bug3.c'
	generates incorrect code.  Pay special attention to the 2nd
	if statement and the recalculation of i in the .s file.
>How-To-Repeat:

search_bug3.c:

/* #include <sys/poll.h> */
struct pollfd
  {
    int fd;
    short int events;
    short int revents;
  };

int search1 (
    unsigned int * __restrict__         i_p,
    int                                 fd,
    unsigned int                        num,
    struct pollfd * __restrict__        poll_p)
{
    int                                 diff;
    unsigned int                        i;
    unsigned int                        l;
    unsigned int                        u;
    unsigned int                        tmp1;

    /*
     * Find the fd (or the next highest fd to insert before)
     * in the poll_array using a binary search.
     */

    u = num;
    l = 0;
    i = num >> 1;

    while (l < u)
    {
        tmp1 = poll_p[i].fd - fd;

        if (tmp1 == 0)
            goto FOUND_IT;

        if (tmp1 > 0)
            u = i;
        else 
            l = i + 1;

        i = (l + u) >> 1;
    }

    if (tmp1 < 0)
        i++;

FOUND_IT: ;

    diff = tmp1;

    *i_p = i;
    return (diff);
}

search_bug3.s:

	.file	"search_bug3.c"
	.text
	.align 16
.globl search1
	.type	search1,@function
search1:
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%edi
	movl	16(%ebp), %eax
	pushl	%esi
	movl	12(%ebp), %ecx
	pushl	%ebx
	xorl	%ebx, %ebx
	movl	%eax, %edx
	shrl	%edx
	cmpl	%eax, %ebx
	movl	20(%ebp), %edi
	jae	.L6
	.p2align 4
.L4:
	movl	(%edi,%edx,8), %eax
	movl	%eax, %esi
	subl	%ecx, %esi
	je	.L6
	movl	%edx, %eax
	shrl	%edx
	cmpl	%eax, %ebx
	jb	.L4
.L6:
	movl	8(%ebp), %eax
	movl	%edx, (%eax)
	movl	%esi, %eax
	popl	%ebx
	popl	%esi
	popl	%edi
	popl	%ebp
	ret
.Lfe1:
	.size	search1,.Lfe1-search1
	.ident	"GCC: (GNU) 3.0.3"

>Fix:
	No known fix.  The following are work-arounds:
	If optimization is turned off, it appears correct code is
	generated.
	If the variable tmp1 is removed from the program (replaced
	by variable diff), it appears that correct code is
	generated.
>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-02-13  3:09 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-12 19:09 optimization/5344: gcc 3.0.3 optimizer generates incorrect code anguiano
  -- strict thread matches above, loose matches on Subject: below --
2002-02-12 11:16 optimization/5344 " Ricardo Anguiano
2002-01-09 22:46 optimization/5344: " cosmos

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).