llvm dev - Dec 2009 - [LLVMdev] Problem in External/SPEC/CFP2000/177.mesa/Makefile ?

Hello folks,

The makefile for 177.mesa says that for a small problem size, it will
get 100 frames. But in the spec sources I have, the test folder only
contains numbers for 10 frames:

$ speccpu2000/benchspec/CFP2000/177.mesa/data $ wc -l test/input/numbers
      10 test/input/numbers

Generating 100 frames causes undefined behaviour because the program is
doing unchecked fscanf on that "numbers" file.

Is my version of spec wrong ? If not, can we apply the attached patch ?

Thanks,
Julien

-- 
Julien Lerouge
PGP Key Id: 0xB1964A62
PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62
PGP Public Key from: keyserver.pgp.com
-------------- next part --------------
Index: External/SPEC/CFP2000/177.mesa/Makefile
==================================================================---
External/SPEC/CFP2000/177.mesa/Makefile	(revision 92115)
+++ External/SPEC/CFP2000/177.mesa/Makefile	(working copy)
@@ -4,7 +4,7 @@
 ifdef LARGE_PROBLEM_SIZE
 RUN_OPTIONS := -frames 500
 else
-RUN_OPTIONS := -frames 100
+RUN_OPTIONS := -frames 10
 endif
 
 RUN_OPTIONS += -meshfile mesa.in -ppmfile mesa.ppm

On Dec 23, 2009, at 6:26 PM, Julien Lerouge wrote:
> Hello folks,
>
> The makefile for 177.mesa says that for a small problem size, it will
> get 100 frames. But in the spec sources I have, the test folder only
> contains numbers for 10 frames:
>
> $ speccpu2000/benchspec/CFP2000/177.mesa/data $ wc -l test/input/ 
> numbers
>      10 test/input/numbers
>
> Generating 100 frames causes undefined behaviour because the program  
> is
> doing unchecked fscanf on that "numbers" file.
>
> Is my version of spec wrong ?
What you say is true in the version I have.
> If not, can we apply the attached patch ?
I don't think it's ideal.  There are 3 input sets, not 2, that's the
root of the problem:

ifndef RUN_TYPE
ifdef SMALL_PROBLEM_SIZE
RUN_TYPE := test
else
ifdef LARGE_PROBLEM_SIZE
RUN_TYPE := ref
else
RUN_TYPE := train
endif
endif
endif

100 is a fine value for "train".  I think it's better to test both
variables in the mesa Makefile.

(IMO controlling a ternary variable with 2 booleans is not the right  
way to do it, btw.)
> Thanks,
> Julien
>
> -- 
> Julien Lerouge
> PGP Key Id: 0xB1964A62
> PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62
> PGP Public Key from: keyserver.pgp.com
> <p.diff>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Wed, Dec 23, 2009 at 08:22:35PM -0800, Dale Johannesen
wrote:
>
> On Dec 23, 2009, at 6:26 PM, Julien Lerouge wrote:
>
>> Hello folks,
>>
>> The makefile for 177.mesa says that for a small problem size, it will
>> get 100 frames. But in the spec sources I have, the test folder only
>> contains numbers for 10 frames:
>>
>> $ speccpu2000/benchspec/CFP2000/177.mesa/data $ wc -l
test/input/numbers
>>      10 test/input/numbers
>>
>> Generating 100 frames causes undefined behaviour because the program is
>> doing unchecked fscanf on that "numbers" file.
>>
>> Is my version of spec wrong ?
>
> What you say is true in the version I have.
>
>> If not, can we apply the attached patch ?
>
> I don't think it's ideal.  There are 3 input sets, not 2,
that's the root
> of the problem:
>
> ifndef RUN_TYPE
> ifdef SMALL_PROBLEM_SIZE
> RUN_TYPE := test
> else
> ifdef LARGE_PROBLEM_SIZE
> RUN_TYPE := ref
> else
> RUN_TYPE := train
> endif
> endif
> endif
>
Ah, I should have verified. Thanks.
> 100 is a fine value for "train".  I think it's better to test
both
> variables in the mesa Makefile.
Alright, I'll do that then.

Thanks Dale,

-- 
Julien Lerouge
PGP Key Id: 0xB1964A62
PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62
PGP Public Key from: keyserver.pgp.com