Re: ARM gcc 4.1 optimization bug.

2006-06-26 Thread Dirk Behme

Dave Korn wrote:

On 06 June 2006 15:17, Richard Earnshaw wrote:


On Tue, 2006-06-06 at 15:05, Dirk Behme wrote:


Fengwei Yin wrote:


Hi Daniel,
I have already reported this bug. The bug number is #27363.
I also tried the gcc snapshot 4.1.1-20060421. The bug is not
fixed in this version too.


>


On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:


On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote:


I am using gcc4.1 for ARM to build Linux kernel. But there is a bug
related to the gcc optimization. I assume this is correct mail list to
report this bug. If not, please let me know.


No, if you have a bug report, please use the bug reporting system.
 Please see: http://gcc.gnu.org/bugs.html


Any news regarding this?

Seems that I have the same problem. However, I first selected an other list

http://sourceware.org/ml/crossgcc/2006-06/msg00032.html

before finding this ;)

Looking at

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

it looks to me that this isn't fixed at 4.1.1?



The bug is in state 'WAITING', which means there is not enough
information for us to investigate the problem.

See http://gcc.gnu.org/bugs.html for details of what we need.


  Just to elaborate: we need a simple self-contained testcase that anybody can
compile themselves and see the bug.  There's no possible way to analyze and
fix it without being able to recreate it!  In the bug report, you wrote 


"I tried to make a simple test example for this bug. But If I put the
code from ALSA subsystem of Linux kernel to a test.c file, the gcc will
product correct assembly code."

  So, what you need to do is re-do the original kernel build, but add
"--save-temps" to the compiler flags, then find the .i file with the
preprocessed source code for the failing module.  This will be entirely
selfcontained and will reproduce the bug, because that's what the compiler
actually gets fed with in the case where you do see the bug; when you
extracted it to a separate file there was probably some subtle difference
related maybe to macro #defines or something that didn't match up.


We now put the code generated with --save-temps and the 
resulting assembly files for different optimization levels 
as attachment to


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

Anything else needed?

Best regards

Dirk


RE: ARM gcc 4.1 optimization bug.

2006-06-06 Thread Dave Korn
On 06 June 2006 15:33, Dave Korn wrote:


> In the bug report, you wrote


  "You" being Fengwei Yin, of course, not Dirk Behme; apologies for my unclear
attribution.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today



RE: ARM gcc 4.1 optimization bug.

2006-06-06 Thread Dave Korn
On 06 June 2006 15:17, Richard Earnshaw wrote:

> On Tue, 2006-06-06 at 15:05, Dirk Behme wrote:
>> Fengwei Yin wrote:
>>> Hi Daniel,
>>> I have already reported this bug. The bug number is #27363.
>>> I also tried the gcc snapshot 4.1.1-20060421. The bug is not
>>> fixed in this version too.
>>  >
>>> On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
 On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote:
> I am using gcc4.1 for ARM to build Linux kernel. But there is a bug
> related to the gcc optimization. I assume this is correct mail list to
> report this bug. If not, please let me know.
 
 No, if you have a bug report, please use the bug reporting system.
   Please see: http://gcc.gnu.org/bugs.html
>> 
>> Any news regarding this?
>> 
>> Seems that I have the same problem. However, I first selected an other list
>> 
>> http://sourceware.org/ml/crossgcc/2006-06/msg00032.html
>> 
>> before finding this ;)
>> 
>> Looking at
>> 
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
>> 
>> it looks to me that this isn't fixed at 4.1.1?
> 
> 
> The bug is in state 'WAITING', which means there is not enough
> information for us to investigate the problem.
> 
> See http://gcc.gnu.org/bugs.html for details of what we need.
> 
> R.


  Just to elaborate: we need a simple self-contained testcase that anybody can
compile themselves and see the bug.  There's no possible way to analyze and
fix it without being able to recreate it!  In the bug report, you wrote 

"I tried to make a simple test example for this bug. But If I put the
code from ALSA subsystem of Linux kernel to a test.c file, the gcc will
product correct assembly code."

  So, what you need to do is re-do the original kernel build, but add
"--save-temps" to the compiler flags, then find the .i file with the
preprocessed source code for the failing module.  This will be entirely
selfcontained and will reproduce the bug, because that's what the compiler
actually gets fed with in the case where you do see the bug; when you
extracted it to a separate file there was probably some subtle difference
related maybe to macro #defines or something that didn't match up.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today



Re: ARM gcc 4.1 optimization bug.

2006-06-06 Thread Richard Earnshaw
On Tue, 2006-06-06 at 15:05, Dirk Behme wrote:
> Fengwei Yin wrote:
> > Hi Daniel,
> > I have already reported this bug. The bug number is #27363.
> > I also tried the gcc snapshot 4.1.1-20060421. The bug is not
> > fixed in this version too.
>  >
> > On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> >> On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote:
> >> > I am using gcc4.1 for ARM to build Linux kernel. But there is a bug
> >> > related to the gcc
> >> > optimization. I assume this is correct mail list to report this bug.
> >> > If not, please let me know.
> >>
> >> No, if you have a bug report, please use the bug reporting system.
> >> Please see:
> >>   http://gcc.gnu.org/bugs.html
> 
> Any news regarding this?
> 
> Seems that I have the same problem. However, I first 
> selected an other list
> 
> http://sourceware.org/ml/crossgcc/2006-06/msg00032.html
> 
> before finding this ;)
> 
> Looking at
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
> 
> it looks to me that this isn't fixed at 4.1.1?


The bug is in state 'WAITING', which means there is not enough
information for us to investigate the problem.  

See http://gcc.gnu.org/bugs.html for details of what we need.

R.



Re: ARM gcc 4.1 optimization bug.

2006-06-06 Thread Dirk Behme

Fengwei Yin wrote:

Hi Daniel,
I have already reported this bug. The bug number is #27363.
I also tried the gcc snapshot 4.1.1-20060421. The bug is not
fixed in this version too.

>

On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote:
> I am using gcc4.1 for ARM to build Linux kernel. But there is a bug
> related to the gcc
> optimization. I assume this is correct mail list to report this bug.
> If not, please let me know.

No, if you have a bug report, please use the bug reporting system.
Please see:
  http://gcc.gnu.org/bugs.html


Any news regarding this?

Seems that I have the same problem. However, I first 
selected an other list


http://sourceware.org/ml/crossgcc/2006-06/msg00032.html

before finding this ;)

Looking at

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

it looks to me that this isn't fixed at 4.1.1?

To create "easier" testcase, maybe it helps to compile only 
kernel's sound modules? I can reproduce this failure 
compiling sound modules of 2.6.17-rc5 with using different 
optimization levels for them:


-Os -> failure
-O2 -> failure
-O0 -> building of some modules fails
-O1 -> sound works!

Best regards

Dirk




Re: ARM gcc 4.1 optimization bug.

2006-05-01 Thread Fengwei Yin

Hi Daniel,
I have already reported this bug. The bug number is #27363.
I also tried the gcc snapshot 4.1.1-20060421. The bug is not
fixed in this version too.

Thanks & Regards
yfw

On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote:
> Hi,
> I am using gcc4.1 for ARM to build Linux kernel. But there is a bug
> related to the gcc
> optimization. I assume this is correct mail list to report this bug.
> If not, please let me know.

No, if you have a bug report, please use the bug reporting system.
Please see:
  http://gcc.gnu.org/bugs.html


--
Daniel Jacobowitz
CodeSourcery



Re: ARM gcc 4.1 optimization bug.

2006-04-30 Thread Daniel Jacobowitz
On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote:
> Hi,
> I am using gcc4.1 for ARM to build Linux kernel. But there is a bug
> related to the gcc
> optimization. I assume this is correct mail list to report this bug.
> If not, please let me know.

No, if you have a bug report, please use the bug reporting system.
Please see:
  http://gcc.gnu.org/bugs.html


-- 
Daniel Jacobowitz
CodeSourcery


ARM gcc 4.1 optimization bug.

2006-04-29 Thread Fengwei Yin

Hi,
I am using gcc4.1 for ARM to build Linux kernel. But there is a bug
related to the gcc
optimization. I assume this is correct mail list to report this bug.
If not, please let me know.
And I didn't find the same bug reported too.

The kernel is 2.6.14. When I build ALSA subsystem. I use following commandline:

arm-iwmmxt-linux-gnueabi-gcc -Wp,-MD,sound/core/.pcm_native.o.d 
-nostdinc -isystem

/usr/local/arm-iwmmxt-linux-gnueabi/bin/../lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.0/include
-D__KERNEL__ -Iinclude  -include include/linux/autoconf.h
-mlittle-endian -gdwarf-2 -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding 
-fno-omit-frame-pointer -fno-optimize-sibling-calls -gdwarf-2

-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux
-mno-thumb-interwork -D__LINUX_ARM_ARCH__=5 -march=armv5te
-mtune=xscale -Wa,-mcpu=xscale  -msoft-float -Uarm
-Wdeclaration-after-statement -Wno-pointer-sign   -gdwarf-2
-DKBUILD_BASENAME=pcm_native -DKBUILD_MODNAME=snd_pcm -Os -c -o
sound/core/pcm_native.o sound/core/pcm_native.c


And the function is like following (using
arm-iwmmxt-linux-gnueabi-objdump -d pcm_nativ.o):

211c :
   211c:e1a0c00dmov ip, sp
   2120:e92dd8f0stmdb   sp!, {r4, r5, r6, r7, fp, ip, lr, pc}
   2124:e24cb004sub fp, ip, #4  ; 0x4
   2128:e24dd020sub sp, sp, #32 ; 0x20
   212c:e5913000ldr r3, [r1]
   2130:e51b502cldr r5, [fp, #-44]
   2134:e24b603csub r6, fp, #60 ; 0x3c
   2138:e1a0c000mov ip, r0
   213c:e1a0e006mov lr, r6
   2140:e1a04000mov r4, r0
   2144:e0055003and r5, r5, r3
   2148:e1a07001mov r7, r1
   214c:e8bc000fldmia   ip!, {r0, r1, r2, r3}
   2150:e8ae000fstmia   lr!, {r0, r1, r2, r3}
   2154:e89c000fldmia   ip, {r0, r1, r2, r3}
   2158:e5845000str r5, [r4]
   215c:e597c004ldr ip, [r7, #4]
   2160:e355cmp r5, #0  ; 0x0
   2164:e88e000fstmia   lr, {r0, r1, r2, r3}
   2168:e001300cand r3, r1, ip  /* r1 from
   2154:
e89c000fldmia   ip, {r0, r1, r2, r3}
   Using the 
wrong value.
   The r1 from 
this instruction should be used:
   214c:   
ldmiaip!, {r0, r1, r2, r3}
*/
   216c:e1a4mov r0, r4
   2170:e3a02008mov r2, #8  ; 0x8
   2174:e1a01006mov r1, r6
   2178:e5843004str r3, [r4, #4]
   217c:1a05bne 2198 
   2180:e353cmp r3, #0  ; 0x0
   2184:e3e03015mvn r3, #21 ; 0x15
   2188:1a02bne 2198 
   218c:e1a3mov r0, r3
   2190:e24bd01csub sp, fp, #28 ; 0x1c
   2194:e89da8f0ldmia   sp, {r4, r5, r6, r7, fp, sp, pc}
   2198:ebfebl  0 
   219c:e2503000subsr3, r0, #0  ; 0x0
   21a0:13a03001movne   r3, #1  ; 0x1
   21a4:eaf8b   218c 

The C code is like following:

#define SNDRV_MASK_SIZE 2
struct mask_t {
unsigned int bits[8];
};
typedef struct mask_t snd_mask_t;
static inline int snd_mask_empty(const snd_mask_t *mask)
{
   int i;
   for (i = 0; i < SNDRV_MASK_SIZE; i++) {
   if (mask->bits[i])
   return 0;
   }
   return 1;
}
static inline void snd_mask_intersect(snd_mask_t *mask, const snd_mask_t *v)
{
   int i;
   for (i = 0; i < SNDRV_MASK_SIZE; i++)
   mask->bits[i] &= v->bits[i];
}
static inline void snd_mask_copy(snd_mask_t *mask, const snd_mask_t *v)
{
   *mask = *v;
}
int snd_mask_refine(snd_mask_t *mask, const snd_mask_t *v)
{
   snd_mask_t old;

   snd_mask_copy(&old, mask);
   snd_mask_intersect(mask, v);
   if (snd_mask_empty(mask))
   return -1;

   return !snd_mask_eq(mask, &old);
return 1;
}

When I remove the -O option, the ALSA works OK. the .s file is like following:

0040 :
 40:e1a0c00dmov ip, sp
 44:e92dd800stmdb   sp!, {fp, ip, lr, pc}
 48:e24cb004sub fp, ip, #4  ; 0x4
 4c:e24dd048sub sp, sp, #72 ; 0x48
 50:e50b0048str r0, [fp, #-72]
 54:e50b104cstr r1, [fp, #-76]
 58:e51b3048