Compiler removing non-redundant code path

[jimdempseyatthecove]

I would normally submit this to Premier Support but they are going to ask me for code samples which aren't that easy for me to submit. I am posting this here to sample the forum members to see if they encountered similar problems.

[cpp]! xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
! Optimization removed critical section and merged code

        if((JSEG .eq. JSEGbegin) .and. (JSEG .ne. 1)) then
!$OMP CRITICAL(TNSFSI_1)
                 pFiniteSolution.rBeadFSIF(:,JSEG-1) = &
                    & pFiniteSolution.rBeadFSIF(:,JSEG-1) + TOSVX1
!$OMP END CRITICAL(TNSFSI_1)
        else
             pFiniteSolution.rBeadFSIF(:,JSEG-1) = &
                & pFiniteSolution.rBeadFSIF(:,JSEG-1) + TOSVX1
        endif

! xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

! optimization removed atomic and merged code

        if((JSEG .eq. JSEGbegin) .and. (JSEG .ne. 1)) then
!$OMP ATOMIC
                 pFiniteSolution.rBeadFSIF(1,JSEG-1) = &
                    & pFiniteSolution.rBeadFSIF(1,JSEG-1) + TOSVX1(1)
!$OMP ATOMIC
                 pFiniteSolution.rBeadFSIF(2,JSEG-1) = &
                    & pFiniteSolution.rBeadFSIF(2,JSEG-1) + TOSVX1(2)
!$OMP ATOMIC
                 pFiniteSolution.rBeadFSIF(3,JSEG-1) = &
                    & pFiniteSolution.rBeadFSIF(3,JSEG-1) + TOSVX1(3)
        else
             pFiniteSolution.rBeadFSIF(:,JSEG-1) = &
                & pFiniteSolution.rBeadFSIF(:,JSEG-1) + TOSVX1
        endif

! xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

! optimization kept both code paths

        if((JSEG .eq. JSEGbegin) .and. (JSEG .ne. 1)) then
            call AtomicAddVec3(pFiniteSolution.rBeadFSIF(:,JSEG-1), TOSVX1)
        else
             pFiniteSolution.rBeadFSIF(:,JSEG-1) = &
                & pFiniteSolution.rBeadFSIF(:,JSEG-1) + TOSVX1
        endif

! xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[/cpp]

Note, if OpenMP were disabled (in this case it was not) the code in both branches of the IF would be identical and one path, plus the IF test could be removed. However with OpenMP enabled the4 !$OMP statements generate code and therefore the code paths are different. Inserting the out call to the external subroutine fixes the problem

So the postulation is: Is the redundant code path elimination code in the compiler performed _before_ the OpenMP code processing? If so, then this clearly illustrates a bug in the compiler.

Now then, even without sample code illustrating the problem, the compiler maintainer(s) should be able to examine the sequencing between "redundant code path elimination" and "OpenMP code insertion".

Jim Dempsey

[Steven_L_Intel1]

The developers are not going to look at this without a test case. It is not so simple as browsing the code and asking "what if".

[jimdempseyatthecove]

Quoting - Steve Lionel (Intel)

The developers are not going to look at this without a test case. It is not so simple as browsing the code and asking "what if".

Steve,

I have put in over 40 years of software support and many software problems are resolved faster by a well constructed code snipit and a good "what if". In gross terms the compiler is nothing more than

part1();
part2();
..
partn();

and will have loops and branches.

Of the parts performed by the compiler, the two parts of interest are "redundant code removal from two branches of if statement" and "OpenMP code insertion".

Your compiler maintainer/developer should be capable, in 10 seconds or less, of identifying which part of the compilation process relates to which functionality in quotes. With this information at hand, it will take perhaps a few minutes of time to determine the sequence that these processing occure in the compilation process, and then a fraction of a second for the "ah!".

For us to discuss this is immaterial... as the compiler developer/maintainer is the one with the knowledge. The point I am making (and attempting to resolve) is well structured postulations do not make it past the first tier on the Premier Support site (as they do not include a failing code example).

To beat a dead horse:

What would a failing test case do for the maintainer?

1) Demonstrates that "Yes this doesn't work" (does what was observed).
2) The code doesn't crash the compiler, so why doesn't it work? Hmmm... maybe, if the "redundant code removal from two branches of if statement" preceeds the "OpenMP code insertion" the symptoms will exhibit themselves. Let me look there.
3) If the sequencing problem is indeed the case, then yes, the failing code example would be of use in confirming the fix.

Progressing through step 2) can be made without reliance on a test case (other than for confirmation of problem).

Requiring test cases _before_ examination of problem in all cases is detrimental to your goal of making an error free compilation.

Jim Dempsey

[Steven_L_Intel1]

Jim,

A test case would allow the developer to follow the path it takes through the compiler, examining the data structures created, and then figuring out why, for this program, code is incorrectly removed. There are too many variables, too much information passed in from other phases, to simply get this from code inspection. Furthermore, without a test case there's no way to know if a fix works (and continues to work in the future.)

More to the point is that the developers will simply push back and insist on a test case. In an ideal world we might try to construct one based on your paraphrase of the problem, and in some simple cases that's possible, but not for something like this.