[Bug c/20625] New: gcc with -O2 produces code that generates "unaligned access exception"

[Bug c/20625] New: gcc with -O2 produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

gcc version 4.0.0 20050320 (Red Hat 4.0.0-0.35)

The code produced by this version of gcc generates unaligned access exception.
gcc 3.4.3 and 3.4.2 produces correct code

-- 
           Summary: gcc with -O2 produces code that generates "unaligned
                    access exception"
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        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
  GCC host triplet: alpha-redhat-linux
GCC target triplet: alpha-redhat-linux


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

[Bug c/20625] gcc with -O2 produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-03-24 16:55 -------
Created an attachment (id=8450)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8450&action=view)
test case

This is small test case that shows the problem

-- 


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

[Bug c/20625] gcc with -O2 produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-03-24 16:57 -------
Created an attachment (id=8452)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8452&action=view)
Produced assembler file

This is generated assembler source with marked instruction (<---) that
generated unaligned access exception

-- 


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

[Bug c/20625] gcc with -O2 produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-03-24 16:58 -------
If source code compiled without optimization - no unaligned access generated.


-- 


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

[Bug target/20625] gcc with -O2 produces code that generates "unaligned access exception"

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |wrong-code


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

[Bug target/20625] [4.0 regression] ivopts produces code that generates "unaligned access exception"

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-03-29 13:03 -------
I can reproduce this with gcc 4.0.0 20050329 on alphaev68-unknown-linux-gnu.
Test case:

struct BS {
    int i;
    char c[46];
};

void foo(struct BS* p)
{   
    int i; 
    for (i = 0; p->c[i]; i++) 
        ; 
}

int main()
{
#if defined(__alpha__) && defined(__linux__)
    #include <asm/sysinfo.h>
    #include <asm/unistd.h>
    unsigned int buf[2] = { SSIN_UACPROC, UAC_SIGBUS | UAC_NOPRINT };
    syscall(__NR_osf_setsysinfo, SSI_NVPAIRS, buf, 1, 0, 0, 0);
#endif

    struct BS p = { 0, "12" };
    foo(&p);
    return 0;
}

falk@juist:/tmp% gcc -mcpu=ev4 -O2 t.c && ./a.out
zsh: bus error (core dumped)  ./a.out
falk@juist:/tmp% gcc -fno-ivopts -mcpu=ev4 -O2 t.c && ./a.out 
falk@juist:/tmp% 


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
      Known to fail|                            |4.0.0
            Summary|gcc with -O2 produces code  |[4.0 regression] ivopts
                   |that generates "unaligned   |produces code that generates
                   |access exception"           |"unaligned access exception"


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

[Bug target/20625] [4.0 regression] ivopts produces code that generates "unaligned access exception"

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-03-29 13:12 -------
This looks similar to the (fixed) PR 17949. Zdenek, do you have any ideas?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu dot
                   |                            |org


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 20:03 -------
This most likely can be reproduced on ia64 too and other targets where alignment is needed for some 
loads.

The tree which we produce looks like:
<bb 0>:
  if (p->c[0] != 0) goto <L0>; else goto <L2>;

<L0>:;
  D.1133 = *((unsigned char *) p + 5B);
  p = p + 1B;
  if (D.1133 != 0) goto <L0>; else goto <L2>;

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0 regression] ivopts     |[4.0/4.1 regression] ivopts
                   |produces code that generates|produces code that generates
                   |"unaligned access exception"|"unaligned access exception"
   Target Milestone|---                         |4.0.0


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-03-29 20:23 -------
(In reply to comment #6)
> This most likely can be reproduced on ia64 too and other targets where
alignment is needed for some 
> loads.

I cannot reproduce it with -mcpu=ev56, though, so maybe it needs a plaform
that does not have narrow loads (do we have any other except alphaev4?).

-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

------- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz  2005-03-29 21:09 -------
Subject: Re:  [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

> > This most likely can be reproduced on ia64 too and other targets where alignment is needed for some 
> > loads.
> > 
> > The tree which we produce looks like:
> > <bb 0>:
> >   if (p->c[0] != 0) goto <L0>; else goto <L2>;
> > 
> > <L0>:;
> >   D.1133 = *((unsigned char *) p + 5B);
> >   p = p + 1B;
> >   if (D.1133 != 0) goto <L0>; else goto <L2>;
> 
> The problem seems to be that the expansion assumes that p must be
> aligned.  Which seems to be reasonable.  I will try making ivopts
> produce all pointer ivs in (void *) type, that should hopefully
> help.

This patch should fix the problem (I have looked on crosscompiler
output only, so I am not entirely sure yet).

Index: tree-ssa-loop-ivopts.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-loop-ivopts.c,v
retrieving revision 2.54
diff -c -3 -p -r2.54 tree-ssa-loop-ivopts.c
*** tree-ssa-loop-ivopts.c	22 Mar 2005 22:08:53 -0000	2.54
--- tree-ssa-loop-ivopts.c	29 Mar 2005 21:07:33 -0000
*************** strip_offset (tree expr, bool inside_add
*** 1840,1845 ****
--- 1840,1861 ----
    return fold_convert (orig_type, expr);
  }
  
+ /* Returns variant of TYPE that can be used as base for different uses.
+    For integer types, we return unsigned variant of the type, which
+    avoids problems with overflows.  For pointer types, we return void *.  */
+ 
+ static tree
+ generic_type_for (tree type)
+ {
+   if (POINTER_TYPE_P (type))
+     return ptr_type_node;
+ 
+   if (TYPE_UNSIGNED (type))
+     return type;
+ 
+   return unsigned_type_for (type);
+ }
+ 
  /* Adds a candidate BASE + STEP * i.  Important field is set to IMPORTANT and
     position to POS.  If USE is not NULL, the candidate is set as related to
     it.  If both BASE and STEP are NULL, we add a pseudocandidate for the
*************** add_candidate_1 (struct ivopts_data *dat
*** 1852,1865 ****
  {
    unsigned i;
    struct iv_cand *cand = NULL;
!   tree type;
    
    if (base)
      {
!       type = TREE_TYPE (base);
!       if (!TYPE_UNSIGNED (type))
  	{
- 	  type = unsigned_type_for (type);
  	  base = fold_convert (type, base);
  	  if (step)
  	    step = fold_convert (type, step);
--- 1868,1881 ----
  {
    unsigned i;
    struct iv_cand *cand = NULL;
!   tree type, orig_type;
    
    if (base)
      {
!       orig_type = TREE_TYPE (base);
!       type = generic_type_for (orig_type);
!       if (type != orig_type)
  	{
  	  base = fold_convert (type, base);
  	  if (step)
  	    step = fold_convert (type, step);


-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-03-29 21:38 -------
(In reply to comment #9)

> This patch should fix the problem

Yes, it does. (I haven't tried bootstrapping, though.)

Thanks for fixing this so quickly!


-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-03-30 09:43 -------
It does work for me too.
Thank you for quick fix.

-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[rakdver at gcc dot gnu dot org]

------- Additional Comments From rakdver at gcc dot gnu dot org  2005-04-01 20:00 -------
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00097.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-04 23:14 -------
This has been approved by RTH here:

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00428.html

Please apply to 4.0 and mainline.  Thanks!

-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-05 23:57 -------
Subject: Bug 20625

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rakdver@gcc.gnu.org	2005-04-05 23:57:02

Modified files:
	gcc            : ChangeLog tree-ssa-loop-ivopts.c 

Log message:
	PR target/20625
	* tree-ssa-loop-ivopts.c (generic_type_for): New function.
	(add_candidate_1): Use generic_type_for instead of unsigned_type_for.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8156&r2=2.8157
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.57&r2=2.58



-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 00:32 -------
Subject: Bug 20625

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	rakdver@gcc.gnu.org	2005-04-06 00:32:37

Modified files:
	gcc            : ChangeLog tree-ssa-loop-ivopts.c 

Log message:
	PR target/20625
	* tree-ssa-loop-ivopts.c (generic_type_for): New function.
	(add_candidate_1): Use generic_type_for instead of unsigned_type_for.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.132&r2=2.7592.2.133
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.49.2.2&r2=2.49.2.3



-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 21:00 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-05-05 19:07 -------
gcc version 4.0.0 20050423 (Red Hat 4.0.0-2)

Here is another test case that generates unaligned access exception:

----------------------------------------
typedef union
{
   short i16;
   unsigned short u16;
   int i32;
   unsigned int u32;

   long i64;
   unsigned long u64;

   double dbl;
   unsigned char byt;
   char *str;
} DBusBasicValue;

void foo(void *p)
{
   DBusBasicValue *a;

   a = p;

   a->byt = 'a';
}

int main()
{
# include <asm/sysinfo.h>
# include <asm/unistd.h>
   unsigned int buf[2] =
     {
        SSIN_UACPROC, UAC_SIGBUS | UAC_NOPRINT
     };

   char buff[100];

   syscall(__NR_osf_setsysinfo, SSI_NVPAIRS, buf, 1, 0, 0, 0);

   foo(&buff[1]);
}
--------------------------------

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 19:10 -------
(In reply to comment #17)
> gcc version 4.0.0 20050423 (Red Hat 4.0.0-2)
> 
> Here is another test case that generates unaligned access exception:

That code is invalid due to the alignment requirements in standard C.

The orginal testcase has been fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-05-05 19:16 -------
I just extracted it from "dbus" package which I am testing on linux/alpha
platform. There are other packages (mozilla one of them) that started to
generate unaligned access exceptions then built by gcc 4.0.

Should not be some warning to be generated?

Thank you.


-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 19:22 -------
(In reply to comment #19)
> Should not be some warning to be generated?

There is a warning if going directly from char * to the union pointer but since you go through a void 
pointer, the warning is gone.

-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-05-05 20:03 -------
(In reply to comment #20)
> (In reply to comment #19)
> > Should not be some warning to be generated?
> 
> There is a warning if going directly from char * to the union pointer but
since you go through a void 
> pointer, the warning is gone.

Yes, it does. DEC C generates exactly the same code for "foo" function. So, I am
sorry for my wrong testcase.

I am trying to find out where unaligned pointer is came from. Going couple
functions back I found that it is the address if "unsigned char" variable
allocated on stack. Should I look at this issue or it might be possible in
theory and I should report about improper coding practice to the author of the code?

Thank you for your attention

-- 


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

Re: [Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[Andrew Pinski]

On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:

> I am trying to find out where unaligned pointer is came from. Going 
> couple
> functions back I found that it is the address if "unsigned char" 
> variable
> allocated on stack. Should I look at this issue or it might be 
> possible in
> theory and I should report about improper coding practice to the 
> author of the code?

Characters have alignment of 1.  I would report it back to the author 
of the code.


-- Pinski

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-05-05 20:06 -------
Subject: Re:  [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"


On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:

> I am trying to find out where unaligned pointer is came from. Going 
> couple
> functions back I found that it is the address if "unsigned char" 
> variable
> allocated on stack. Should I look at this issue or it might be 
> possible in
> theory and I should report about improper coding practice to the 
> author of the code?

Characters have alignment of 1.  I would report it back to the author 
of the code.


-- Pinski



-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[tsv at solvo dot ru]

------- Additional Comments From tsv at solvo dot ru  2005-05-11 20:39 -------
(In reply to comment #22)
> Subject: Re:  [4.0/4.1 regression] ivopts produces code that generates
"unaligned access exception"
> 
> 
> On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:
> 
> > I am trying to find out where unaligned pointer is came from. Going 
> > couple
> > functions back I found that it is the address if "unsigned char" 
> > variable
> > allocated on stack. Should I look at this issue or it might be 
> > possible in
> > theory and I should report about improper coding practice to the 
> > author of the code?
> 
> Characters have alignment of 1.  I would report it back to the author 
> of the code.
> 
> 
> -- Pinski
> 
> 
Sorry if it is not belong here. Just a quick question: There are still unaligned
exceptions generated (even by gcc(libgcj) code itself). Should I open a new bug
report or could continue attach to this one?

Thank you


-- 


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-05-17 14:07 -------
(In reply to comment #23)

> Sorry if it is not belong here. Just a quick question: There are still unaligned
> exceptions generated (even by gcc(libgcj) code itself). Should I open a new bug
> report or could continue attach to this one?

Please open a new one, since this issue should really be fixed by Zdenek's patch.


-- 


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