https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345

            Bug ID: 115345
           Summary: [12/13/14 REGRESSION] / Different outputs compared to
                    GCC 11- and MSVC/Clang
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: djordje.baljozovic at ac dot rwth-aachen.de
  Target Milestone: ---

Created attachment 58344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58344&action=edit
Crash report

Our team works on a large code base written primarily in C:
https://github.com/IUPAC-InChI/InChI .
After compiling the project with MSVC, GCC and Clang/LLVM, we noticed that
there are discrepancies in outputs when the project is compiled with GCC
versions 14.0-14.1/13.0-13.3/12.0-12.4 -- in short GCC versions 12+.
The issue occurs when the GCC 12+ compiled project cannot process 10 specific
inputs (.sdf/.mol files) which are processed without any problems with GCC
11-/MSVC/Clang.
After running dbg with one of these inputs, we got a crash report which I am
attaching to this issue (file name: inchi_stacktrace_core_dump.txt).

We had put some "control" code in strutil.c which creates an output file
(gcc_crash_report.txt) with relevant values of all variables within this
function:

...
#if (GCC_DEBUG)
    FILE* gcc_fptr;
    gcc_fptr = fopen("gcc_crash_report.txt", "w");
    if (!gcc_fptr)
    {
        printf("\n>>>>>Error opening gcc_crash_report.txt file!<<<<<\n");
    }
#endif

    for (j = 0; j < num_at; j++)
    {
        if (!nNewCompNumber[j])
        {
            /* mark starting with at[j] */
            int fst_at = 0, nxt_at = 0, cur_at = j;
            num_components++;

            /* first time at at[j] */
            fst_at = cur_at;
            nNewCompNumber[fst_at] = (AT_NUMB) num_components;

            bool cur_neq_fst = true;

            /* find next neighbor */
            do
            {
#if (GCC_DEBUG)
                fprintf(gcc_fptr, "\ncur_at = %d, nxt_at = %d, iNeigh[cur_at] =
%d, at[cur_at].val = %d ", cur_at, nxt_at, iNeigh[cur_at], at[cur_at].valence);
#endif
                if (iNeigh[cur_at] < at[cur_at].valence)
                {
                    int ineigh_incr = (int)iNeigh[cur_at];
                    nxt_at = at[cur_at].neighbor[ineigh_incr];
                    iNeigh[cur_at]++;
#if (GCC_DEBUG)
                    fprintf(gcc_fptr, "/ ineigh_incr = %d, new_nxt_at = %d,
iNeigh[cur_at]_inc = %d, nNewCompNumber[nxt_at] = %d ", ineigh_incr, nxt_at,
iNeigh[cur_at], nNewCompNumber[nxt_at]);
#endif

                    if (!nNewCompNumber[nxt_at])
                    {
                        /* forward edge: found new atom */
                        nNewCompNumber[nxt_at] = (AT_NUMB) num_components;
                        nPrevAtom[nxt_at] = (AT_NUMB) cur_at;
                        cur_at = nxt_at;
                    }
                }
                else if (cur_at == fst_at)
                {
                    cur_neq_fst = false;
                    /* break;  done */
                }
                else
                {
                    cur_at = nPrevAtom[cur_at]; /* retract */
                }
            } while (cur_neq_fst);
#if (GCC_DEBUG)
            fprintf(gcc_fptr, "\n");
#endif
        }
    }

#if (GCC_DEBUG)
    if (gcc_fptr)
    {
        fclose(gcc_fptr);
    }
#endif
...

MSVC, Clang and GCC 11- compiled project and GCC 12+ compiled project produce
totally different gcc_crash_report.txt contents for the same input .mol/.sdf
file.
This example shows that the variables in question get totally different values
when compiled with GCC 12+, or, in some cases, do not get values at all.

The described issue seems to be indicating an existence of a very serious bug,
which needs to be fixed immediately.

At this moment, we are recommending our users to compile the code from the
source using GCC 11- or MSVC/Clang, but this is obviously not a solution.

I can give some examples but only one attachment is allowed here.
Please feel free to let me know if any further 

Thank you in advance for your assistance.
George
  • [Bug c/115345] Ne... djordje.baljozovic at ac dot rwth-aachen.de via Gcc-bugs

Reply via email to