[Bug target/22447] New: gcc produces code that generate unaligned exceptions

[Bug target/22447] New: gcc produces code that generate unaligned exceptions

[tsv at solvo dot ru]

/usr/test/bin/gcc -v
Using built-in specs.
Target: alpha-redhat-linux
Configured with: ../configure --prefix=/usr/test --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --host=alpha-redhat-linux
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.2 20050712 (prerelease)
and
gcc -v
Using built-in specs.
Target: alpha-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95 --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=alpha-redhat-linux
Thread model: posix
gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)

Both version of compilers produce the code that generates unaligned exceptions
on EV4 processor. 
Instead of generating the code to store a byte using unaligned load/store
instruction it uses aligned LDL/STL. The assembler code looks correct using -O0
optimization flag and incorrect with -O1 and -O2. I tried to write smaler test
case with the same pattern, but compiler compiles it correctly, so I am
attaching the original preprocessed source. The function to look at:
init_one_value. Check the byte manupilation code.

Thank you,

-- 
           Summary: gcc produces code that generate unaligned exceptions
           Product: gcc
           Version: 4.0.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tsv at solvo dot ru
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: alpha-redhat-linux-gnu
  GCC host triplet: alpha-redhat-linux-gnu
GCC target triplet: alpha-redhat-linux-gnu


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-07-12 21:24 -------
Created an attachment (id=9255)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9255&action=view)
produced assembler output


-- 


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-07-12 21:23 -------
Created an attachment (id=9254)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9254&action=view)
test case


-- 


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|alpha-redhat-linux-gnu      |
   GCC host triplet|alpha-redhat-linux-gnu      |
 GCC target triplet|alpha-redhat-linux-gnu      |alpha-*-linux-gnu


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-07-12 22:27 -------
(In reply to comment #0)


> Instead of generating the code to store a byte using unaligned load/store
> instruction it uses aligned LDL/STL. The assembler code looks correct using -O0
> optimization flag and incorrect with -O1 and -O2. I tried to write smaler test
> case with the same pattern, but compiler compiles it correctly, so I am
> attaching the original preprocessed source. The function to look at:
> init_one_value.

typedef char *gptr;
typedef char my_bool;
[...]
static void init_one_value(const struct my_option *option, gptr *variable,
      longlong value)
{
  switch ((option->var_type & 127)) {
  case 2:
    *((my_bool*) variable)= (my_bool) value;
    break;
[...]

At entry of the function, variable must be a null pointer, or point
to an object of type gptr = char*. Because of the dereferencing, gcc can
assume the former, and therefore *variable can be deduced to be 8-byte
aligned. (BTW, the other cases violate aliasing rules, since
they're not covered by the "lvalue of type char" exception.)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-07-12 22:48 -------
(In reply to comment #3)
> (In reply to comment #0)
> 
> 
> > Instead of generating the code to store a byte using unaligned load/store
> > instruction it uses aligned LDL/STL. The assembler code looks correct using -O0
> > optimization flag and incorrect with -O1 and -O2. I tried to write smaler test
> > case with the same pattern, but compiler compiles it correctly, so I am
> > attaching the original preprocessed source. The function to look at:
> > init_one_value.
> 
> typedef char *gptr;
> typedef char my_bool;
> [...]
> static void init_one_value(const struct my_option *option, gptr *variable,
>       longlong value)
> {
>   switch ((option->var_type & 127)) {
>   case 2:
>     *((my_bool*) variable)= (my_bool) value;
>     break;
> [...]
> 
> At entry of the function, variable must be a null pointer, or point
> to an object of type gptr = char*. Because of the dereferencing, gcc can
> assume the former, and therefore *variable can be deduced to be 8-byte
> aligned. (BTW, the other cases violate aliasing rules, since
> they're not covered by the "lvalue of type char" exception.)

Ok. Thank you very much for explanation. Unfortunatelly, with switching to gcc
4.x some code started to produce such exceptions (with gcc 3.4 everything was
fine). Is there an option to make gcc think that passed *variable is char * and
can't be null pointer? Why the simpe test case (that contains the same function
and a function that calls it) produces the correct code (I could attach it if
you have time to take a look at it). Thans again.


-- 


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-07-12 22:59 -------
(In reply to comment #4)

> Unfortunatelly, with switching to gcc 4.x some code started to
> produce such exceptions (with gcc 3.4 everything was fine). Is there
> an option to make gcc think that passed *variable is char * and
> can't be null pointer?

No, sorry. -fno-strict-aliasing doesn't cover this.

> Why the simpe test case (that contains the same function and a
> function that calls it) produces the correct code (I could attach it
> if you have time to take a look at it).

Well, for this:

void f(long *p) {
    *(char *) p = 0;
}

I get

        ldl     t0,0(a0)
        andnot  t0,0xff,t0
        stl     t0,0(a0)

which will fail with unaligned *p, with all gccs I have till back to
2.95. So this doesn't seem to be anything recent...


-- 


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-07-12 23:16 -------
(In reply to comment #5)
> (In reply to comment #4)
> 
> > Unfortunatelly, with switching to gcc 4.x some code started to
> > produce such exceptions (with gcc 3.4 everything was fine). Is there
> > an option to make gcc think that passed *variable is char * and
> > can't be null pointer?
> 
> No, sorry. -fno-strict-aliasing doesn't cover this.
> 
> > Why the simpe test case (that contains the same function and a
> > function that calls it) produces the correct code (I could attach it
> > if you have time to take a look at it).
> 
> Well, for this:
> 
> void f(long *p) {
>     *(char *) p = 0;
> }
> 
> I get
> 
>         ldl     t0,0(a0)
>         andnot  t0,0xff,t0
>         stl     t0,0(a0)
> 
> which will fail with unaligned *p, with all gccs I have till back to
> 2.95. So this doesn't seem to be anything recent...
> 

For this one:

typedef char * gptr;
typedef char my_bool;
//typedef void * gtpr;

static void foo(int sv, gptr var, long value)
{
   switch(sv)
     {
      case 2:
        *((my_bool*) var) = (my_bool) value;
        break;
      case 3:
        *((int *) var) = (int) value;
        break;

      case 4:
        *((long *) var) = (long) value;
        break;

      case 5:
        *((long long *) var) = (long long) value;
        break;
      case 6:
        *((unsigned int *) var) = (unsigned int) value;
        break;
      case 7:
        *((unsigned long *) var) = (unsigned long) value;
        break;
      case 8:
        *((unsigned long long *) var) = (unsigned long long) value;
        break;
      default:
        ;
     }

}

void foo1(int a, gptr ad, long v)
{
   foo(a, ad, v);
}

I get :

$L3:
        insbl $18,$17,$2
        ldq_u $1,0($17)
        mskbl $1,$17,$1
        bis $2,$1,$2
        stq_u $2,0($17)
        ret $31,($26),1
        .end foo1
        .ident  "GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)"
        .section        .note.GNU-stack,"",@progbits

I am just trying to understand how to modify original code (part of MySQL) to
get work without exceptions.

-- 


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

[Bug target/22447] gcc produces code that generate unaligned exceptions

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-07-12 23:27 -------
(In reply to comment #5)
> (In reply to comment #4)
> 
> Well, for this:
> 
> void f(long *p) {
>     *(char *) p = 0;
> }
> 
> I get
> 
>         ldl     t0,0(a0)
>         andnot  t0,0xff,t0
>         stl     t0,0(a0)
> 
> which will fail with unaligned *p, with all gccs I have till back to
> 2.95. So this doesn't seem to be anything recent...
> 
This one I understand and produced assembler code seems to right.


-- 


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