Salford compiler: Assigning a value to a constant expression is invalid 
Author Message
 Salford compiler: Assigning a value to a constant expression is invalid

Our code, http://www.*-*-*.com/ , is compiled and run /at least/ nightly
on several unix-style platform/compiler combinations in the spirit of Extreme
Programming's Continuous Integration.^

For example, we currently cover x86, x86-64, alpha, Mac, Sun, HP, SGI with
Lahey/Fujitsu, NAG, Compaq, IBM, Sun, HP, SGI compilers, respectively.  We also
spot check on x86 with Intel, NA Software, and Portland Group -- the later two
cannot compile our code due to a compiler bug and the lack of F95, respectively.

Despite all this testing, while beginning to port our code to Windows using
the Salford compiler, it failed with,

  $ ftn95 -c  distance_function.f90
  [..]
  0434)     if ( need_transition(grid%bc) ) then
  *** Assigning a value to a constant expression is invalid
  [..]
  *** Compilation failed

where distance_function.f90 has

      30      use bc_types,            only : need_transition

     434     if ( need_transition(grid%bc) ) then

and bc_types.f90 has

     414   logical function need_transition(bc)
     415
     416     type(bcgrid_type), dimension(:), intent(in) :: bc
     417
     418     integer :: i
     419
     420     continue
     421
     422     need_transition = .false.
     423
     424     do i = 1, size(bc)
     425       if (bc_laminar_transition(bc(i)%ibc)) then
     426         need_transition = .true.
     427         return
     428       end if
     429     end do
     430
     431   end function need_transition

and earlier,

     398   logical function bc_laminar_transition(ibc)
     399
     400     integer, intent(in) :: ibc
     401
     402     continue
     403
     404     bc_laminar_transition  = ( ibc < 0 )
     405
     406   end function bc_laminar_transition

Does anyone have any ideas?

Thanks,
--
Bil Kleb, NASA, Hampton, {*filter*}ia, USA

^See http://www.*-*-*.com/
a nice online summary.  Or, for details on our development environment, see
http://www.*-*-*.com/



Thu, 20 Jul 2006 20:34:51 GMT  
 Salford compiler: Assigning a value to a constant expression is invalid

Quote:

>   0434)     if ( need_transition(grid%bc) ) then
>   *** Assigning a value to a constant expression is invalid

    [code details elided]

As I'm sure you suspect, I don't see anything in sight that
looks like assigning a value to a constant expression.  Nor
do I see anything else obviously wrong with the code.

I suppose it is possible that something outside of what you are
showing is messing it up (for example, if the compiler
isn't seeing the same definitions that you think it is), but
I think I'd place my money on compiler bug at the moment.

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net



Fri, 21 Jul 2006 01:47:24 GMT  
 Salford compiler: Assigning a value to a constant expression is invalid
Bil:  I'd suggest submitting a self-contained source code file to Salford Support.
It's darn difficult to fix bugs that are reported only in code segments.

If you post such a compilable/runable source code we the fortran community
can test it on several platforms which might help further document your problem.

Skip Knoble, Penn State

-|Our code, http://fun3d.larc.nasa.gov, is compiled and run /at least/ nightly
-|on several unix-style platform/compiler combinations in the spirit of Extreme
-|Programming's Continuous Integration.^
-|
-|For example, we currently cover x86, x86-64, alpha, Mac, Sun, HP, SGI with
-|Lahey/Fujitsu, NAG, Compaq, IBM, Sun, HP, SGI compilers, respectively.  We also
-|spot check on x86 with Intel, NA Software, and Portland Group -- the later two
-|cannot compile our code due to a compiler bug and the lack of F95, respectively.
-|
-|Despite all this testing, while beginning to port our code to Windows using
-|the Salford compiler, it failed with,
-|
-|  $ ftn95 -c  distance_function.f90
-|  [..]
-|  0434)     if ( need_transition(grid%bc) ) then
-|  *** Assigning a value to a constant expression is invalid
-|  [..]
-|  *** Compilation failed
-|
-|where distance_function.f90 has
-|
-|      30      use bc_types,            only : need_transition
-|
-|     434     if ( need_transition(grid%bc) ) then
-|
-|and bc_types.f90 has
-|
-|     414   logical function need_transition(bc)
-|     415
-|     416     type(bcgrid_type), dimension(:), intent(in) :: bc
-|     417
-|     418     integer :: i
-|     419
-|     420     continue
-|     421
-|     422     need_transition = .false.
-|     423
-|     424     do i = 1, size(bc)
-|     425       if (bc_laminar_transition(bc(i)%ibc)) then
-|     426         need_transition = .true.
-|     427         return
-|     428       end if
-|     429     end do
-|     430
-|     431   end function need_transition
-|
-|and earlier,
-|
-|     398   logical function bc_laminar_transition(ibc)
-|     399
-|     400     integer, intent(in) :: ibc
-|     401
-|     402     continue
-|     403
-|     404     bc_laminar_transition  = ( ibc < 0 )
-|     405
-|     406   end function bc_laminar_transition
-|
-|Does anyone have any ideas?
-|
-|Thanks,

   Herman D. (Skip) Knoble, Research Associate
   (a computing professional for 38 years)

   Web: http://www.personal.psu.edu/hdk
   Penn State Information Technology Services
    Academic Services and Emerging Technologies
     Graduate Education and Research Services
   Penn State University
     214C Computer Building
     University Park, PA 16802-21013
   Phone:+1 814 865-0818   Fax:+1 814 863-7049



Fri, 21 Jul 2006 23:59:34 GMT  
 Salford compiler: Assigning a value to a constant expression is invalid
 >

Quote:
> I'd suggest submitting a self-contained source code file to Salford Support.
> It's darn difficult to fix bugs that are reported only in code segments.

Agreed, that would be best.

However, this is deep in an export-restricted code and, as I am sure
your are aware, it is very time consuming to create stripped-down,
self-contained source which exhibits the same problem.  I recently tried
that for a NAG bug and gave up.  However, since NAG has U.S.-based support,
they were able to request the code ( http://www.*-*-*.com/ ) so that
I could ship them source.  The initial response was that even they
have not been able to strip the problem down to something simple.

I was lucky with the first of three Salford bugs I found: It was in one
of our low-level (i.e., releasable), self-contained library routines and
furthermore, it was developed test-first using our Fortran unit testing
framework.  So all I had to do in that case was send the routine and
the test routine.  They had a fix in less than a week.

Quote:
> If you post such a compilable/runable source code we the Fortran community
> can test it on several platforms which might help further document your problem.

We already test nightly on seven platforms/compilers as the large grain part
of our Continuous Integration practice.

Regards,
--
Bil, NASA, Hampton, {*filter*}ia, USA

A nice summary of Continuous Integration is available at
http://www.*-*-*.com/



Sun, 23 Jul 2006 22:50:12 GMT  
 Salford compiler: Assigning a value to a constant expression is invalid
One can appreciate the complexities involved. However, when encountering
a bug, it is not usually wise, I think, to assume that it's a compiler bug.

I recently worked with a professor here on a nuclear reactor simulator
package by ORNL. This was about 80,000+ lines of code and it had
three misspelt variable names as fleshed out by Salford FTN95 /Checkmate
and verified by Lahey LF95 with debug options. This multiple compiler testing
showed that there were other platform dependent problems and three subscritps
out of range. We were able to work with ORNL and fix each these (known) bugs
and the resultant code compiled and ran using both of the above compilers
in full debug mode.

Over the past 35 years I've worked with many large  codes like
this. Some were government (NASA) codes, others were "Lab"
and other private codes.

To be honest, many of these codes were very messy. I doubt that is
the case with your code, but your code may call code that you did not
write. In our case, we found  all these large codes  had some semantic errors.
Moreover the authors involved did not want to hear this kind of news.
Only on rare occasion did we report to the compiler vendor a compiler bug.

Finally, I do not think my experience over the years is unique.

For what it's worth.
Skip

-| >
-|> I'd suggest submitting a self-contained source code file to Salford Support.
-|> It's darn difficult to fix bugs that are reported only in code segments.
-|
-|Agreed, that would be best.
-|
-|However, this is deep in an export-restricted code and, as I am sure
-|your are aware, it is very time consuming to create stripped-down,
-|self-contained source which exhibits the same problem.  I recently tried
-|that for a NAG bug and gave up.  However, since NAG has U.S.-based support,
-|they were able to request the code (http://fun3d.larc.nasa.gov) so that
-|I could ship them source.  The initial response was that even they
-|have not been able to strip the problem down to something simple.
-|
-|I was lucky with the first of three Salford bugs I found: It was in one
-|of our low-level (i.e., releasable), self-contained library routines and
-|furthermore, it was developed test-first using our Fortran unit testing
-|framework.  So all I had to do in that case was send the routine and
-|the test routine.  They had a fix in less than a week.
-|
-|> If you post such a compilable/runable source code we the Fortran community
-|> can test it on several platforms which might help further document your problem.
-|
-|We already test nightly on seven platforms/compilers as the large grain part
-|of our Continuous Integration practice.
-|
-|Regards,

   Herman D. (Skip) Knoble, Research Associate
   (a computing professional for 38 years)

   Web: http://www.personal.psu.edu/hdk
   Penn State Information Technology Services
    Academic Services and Emerging Technologies
     Graduate Education and Research Services
   Penn State University
     214C Computer Building
     University Park, PA 16802-21013
   Phone:+1 814 865-0818   Fax:+1 814 863-7049



Sun, 23 Jul 2006 23:32:31 GMT  
 Salford compiler: Assigning a value to a constant expression is invalid

Quote:

> One can appreciate the complexities involved. However, when encountering
> a bug, it is not usually wise, I think, to assume that it's a compiler bug.

I think we have an environment that turns the tables.

Quote:
> This multiple compiler testing showed that there were other platform

 > dependent problems and three subscritps out of range. We were able to
 > work with ORNL and fix each these (known) bugs and the resultant code
 > compiled and ran using both of the above compilers in full debug mode.

Exactly.  We compile and run regression tests nightly on /seven/ different
platform/compiler combinations with full debug options.  So, when we go to
a new platform/compiler combination, the odds are extremely likely that it
is due to a bug in the compiler.

Quote:
> To be honest, many of these codes were very messy. I doubt that is
> the case with your code,

I am not that vain.  :)

 > but your code may call code that you did not write.

Depends on what mode we're in.  For straight, sequential operation, it
is all our own code.  Otherwise we're using third-party libraries like
MPICH, Metis, and so forth.

 > In our case, we found  all these large codes had some semantic errors.

According to Hatton and Roberts, "How Accurate Is Scientific Software?",
IEEE Transactions on Software Engineering, Vol. 20, No. 10, Oct. 1994,
the rate is 6 'faults' per 1,000 LOC for commercially released Fortran
code.

Quote:
> Moreover the authors involved did not want to hear this kind of news.

Feedback is the cure for optimism.

Quote:
> Only on rare occasion did we report to the compiler vendor a compiler bug.

I think we've found a compiler bug in every compiler we've ever tried except
for Lahey/Fujitsu, Compaq Fortran, and PathScale.

Regards,
--
Bil, NASA, Hampton, {*filter*}ia, USA



Mon, 24 Jul 2006 06:01:21 GMT  
 Salford compiler: Assigning a value to a constant expression is invalid

Quote:
> This was about 80,000+ lines of code and it had
> three misspelt variable names...

I've run into lots of that.  One of my favorite cases was a program
to extract data from the Shuttle aerodynamic data base.

Horrible, horrible code, I might add.  The whole database was
loaded into one huge array and then every reference to that
array used hard-coded literal index values, whose meaning was
not documented, but which depended on the sizes of all the
database arrays.  If you added a single breakpoint somewhere,
you'd have had to redo pretty much the whole program; I bet
50% of the lines would have to change - not that you'd have the
documentation to figure out what the needed changes were.

I thought some of the engineering judgements incorporated were
as bad as the coding.  Had a bad case of kitchen-sink-itis,
throwing in every effect that someone could think up, regardless
of whether the effect was actually noticable or the data about
it had much credibility.

One compiler I used with it (I forget which), griped about some
variables that were referenced, but not defined.  Turned out to
be some misspelled variable names (I think it was something like
O vs 0).  Undefined variables happened to initialize to zero on
the systems where the code had formerly been used (a fairly small
set of system types).

Turned out that, in my judgement, zero was probably a better value
than the one they were trying to put in.  These were for effects
that were too small to have been sensibly modeled anyway...and
cearly, although someone had thrown the effects into the code,
nobody cared enough to bother even a token test that they had
some effect.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Tue, 25 Jul 2006 00:40:50 GMT  
 Salford compiler: Assigning a value to a constant expression is invalid

Quote:

> Turned out that, in my judgement, zero was probably a better value
> than the one they were trying to put in.  These were for effects
> that were too small to have been sensibly modeled anyway...and
> cearly, although someone had thrown the effects into the code,
> nobody cared enough to bother even a token test that they had
> some effect.

Nah.  The test suite probably went like:

Try nutating the shield frequency.

Done.  I get exactly the same answer.

OK. We didn't expect it would have much effect.




Tue, 25 Jul 2006 10:29:05 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. PGF90-S-0087-Non-constant expression where constant expression required

2. PGF90-S-0087-Non-constant expression where constant expression required

3. Non-constant expression where constant expression required.

4. constant expressions & compilers

5. Updated Win32 Compiler Comparisons (including results for Salford's .NET compiler)

6. help: "assigning" constant big array

7. Invalid initialization expression?

8. Salford FTN90 IOSTAT values

9. optimizing evaluation of constant expressions

10. constant expressions, parameters, `define

11. constant expressions, parameters, `define

12. '87 LRM - constant expression on port

 

 
Powered by phpBB® Forum Software