java/1414: duplicate switch label problems

java/1414: duplicate switch label problems

[mdejong]

>Number:         1414
>Category:       java
>Synopsis:       duplicate switch label problems
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    apbianco
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:19:40 PST 2000
>Closed-Date:    
>Last-Modified:  Tue Dec 12 12:40:00 PST 2000
>Originator:     mdejong@cygnus.com
>Release:        unknown-1.0
>Organization:
>Environment:
Linux, Red Hat 6.2
>Description:
The following class compiles, but it should fail
because of a duplicate switch block.

class T1410d1 {
    void foo(int i) {
        switch (i) {
            case 0:
            case 0:
        }
    }
}


One can even get the compiler to core
dump by adding another a case label:


class T1410d1 {
    void foo(int i) {
        switch (i) {
            case 0:
            case 1:
            case 0:
        }
    }
}
>How-To-Repeat:
Compile with "gcj -C T1410d1.java".
>Fix:

>Release-Note:
>Audit-Trail:

Formerly PR gcj/383


From: Tom Tromey <tromey@redhat.com>
To: mdejong@cygnus.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/383: duplicate switch label problems
Date: 11 Dec 2000 17:49:41 -0700

 Mo> The following class compiles, but it should fail
 Mo> because of a duplicate switch block.
 
 I'm using a relatively recent gcj.  I don't have any of my local
 patches in the current build.
 
 I tried your test program:
 
 creche. gcj --syntax-only T1410d1.java 
 T1410d1.java: In class `T1410d1':
 T1410d1.java: In method `foo(int)':
 T1410d1.java:6: Duplicate case label: `0'.
                case 0:
                ^
 1 error
 
 
 If I run gcj as `gcj -C' then it erroneously passes.
 
 
 
 Mo> One can even get the compiler to core
 Mo> dump by adding another a case label:
 
 Without -C this works, but with -C I get the segv.
 
 In both cases using `-c' instead of `-C' does the right thing.
 
 So it appears to be a bug in the bytecode generator and not in the
 front end.
 
 Thanks,
 Tom

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/383: duplicate switch label problems
Date: Mon, 11 Dec 2000 17:28:15 -0800 (PST)

 Bryce McKinlay writes:
 
 > Well, I would argue that the front end (parser) should be picking
 > this error up and not leaving it to the bytecode generator.
 
 I thought so too. But then I can't remember to which extend gcc's
 middle end is responsible for the detection of multiple entries.
 
 ./A

From: Tom Tromey <tromey@redhat.com>
To: apbianco@cygnus.com
Cc: Bryce McKinlay <bryce@albatross.co.nz>, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/383: duplicate switch label problems
Date: 12 Dec 2000 13:48:38 -0700

 Alex> I thought so too. But then I can't remember to which extend
 Alex> gcc's middle end is responsible for the detection of multiple
 Alex> entries.
 
 I looked at this bug this morning.
 
 java_lang_expand_expr() does the checking for duplicate case labels.
 However, this is not called when -C is given.  I guess that isn't too
 suprising.
 
 If you look at jcf-write.c:generate_bytecode_insns() you will see a
 FIXME comment indicating that the code should check for duplicates.
 
 I wrote a simple patch to do the checking (appended).  However, this
 patch has a couple of problems:
 
 1. It doesn't print the correct line number for the duplicate label
 2. Even when an error is generated gcj will generate a .class file
 
 
 I don't see how to do error reporting from jcf-write.  Maybe the only
 fix is to check for duplicate labels (and any other kind of
 source-level error) before handing the tree to the .class generator.
 
 This is more work since it involves tracking down the right place to
 put the checking code.
 
 Tom
 
 2000-12-12  Tom Tromey  <tromey@redhat.com>
 
 	* jcf-write.c (generate_bytecode_insns): Check for duplicate case
 	labels.
 
 Index: jcf-write.c
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/java/jcf-write.c,v
 retrieving revision 1.70
 diff -u -r1.70 jcf-write.c
 --- jcf-write.c	2000/12/06 18:55:42	1.70
 +++ jcf-write.c	2000/12/12 20:32:37
 @@ -1726,6 +1726,7 @@
  	else
  	  {
  	    HOST_WIDE_INT i;
 +	    int found_error = 0;
  	    /* Copy the chain of relocs into a sorted array. */
  	    struct jcf_relocation **relocs = (struct jcf_relocation **)
  	      xmalloc (sw_state.num_cases * sizeof (struct jcf_relocation *));
 @@ -1737,6 +1738,22 @@
  	    for (reloc = sw_state.cases;  reloc != NULL;  reloc = reloc->next)
  	      {
  		HOST_WIDE_INT case_value = reloc->offset;
 +		struct jcf_relocation *r2;
 +
 +		/* Check for duplicates.  */
 +		for (r2 = sw_state.cases; r2 != reloc; r2 = r2->next)
 +		  {
 +		    HOST_WIDE_INT v2 = r2->offset;
 +		    if (case_value == v2 && reloc != r2)
 +		      {
 +			/* FIXME: we really should print the locations
 +			   of the duplicate and of the original.  */
 +			error ("Duplicate case label: `%d'",
 +			       (int) case_value);
 +			found_error = 1;
 +		      }
 +		  }
 +
  		while (gap_end < sw_state.num_cases)
  		  {
  		    struct jcf_relocation *end = relocs[gap_end];
 @@ -1757,8 +1774,12 @@
  		/* Note we don't check for duplicates.  FIXME! */
  	      }
  
 -	    if (2 * sw_state.num_cases
 -		>= sw_state.max_case - sw_state.min_case)
 +	    if (found_error)
 +	      {
 +		/* Nothing.  */
 +	      }
 +	    else if (2 * sw_state.num_cases
 +		     >= sw_state.max_case - sw_state.min_case)
  	      { /* Use tableswitch. */
  		int index = 0;
  		RESERVE (13 + 4 * (sw_state.max_case - sw_state.min_case + 1));
>Unformatted: