This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ARM gcc 4.1 optimization bug.


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 <dan@debian.org> 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....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]