Member Avatar for nahmartin

I don't know how to solve this problem in my code

voro.cpp(200): (col. 5) remark: LOOP WAS VECTORIZED
voro.cpp(395): same problem
voro.cpp(423):
voro.cpp(427):

I am using intel compiler 10.1 to compile my code

the code works fine on dev C++ and V C++ 2008

200

for(j=0; j<3; j++)
    {
      orient_norm[i][j] = orient[i][j]/len;
    }

395

for(i=0; i<4; i++)                                   // Normalise
      quat[i] /= qlen;

423

for(j=0; j<3; j++)
        ori_rot[i][j] = orient_norm[i][0]*q_matrix[0][j] + orient_norm[i][1]*q_matrix[1][j] + orient_norm[i][2]*q_matrix[2][j];

427

for(j=0; j<3; j++)
        bas_rot[i][j] = basis[i][0]*q_matrix[0][j] + basis[i][1]*q_matrix[1][j] + basis[i][2]*q_matrix[2][j];

Thank you for your time

  • 3 Contributors
  • 5 Replies
  • 229 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by wildgoose

Dani AI

Generated

A few focused points to bridge the existing advice from and the crash reported by .

The compiler remark about vectorization is only an optimization hint. Vectorization can change access order, alignment assumptions and timing; that often reveals existing undefined behavior (out‑of‑bounds indexing, use of uninitialised memory, invalid pointers, or alignment-sensitive SIMD loads) rather than introducing a new bug. If the program behaves differently under optimization, the root cause is usually undefined behavior elsewhere in the code.

Practical checklist and diagnostics (in order of cost/effectiveness):

  • Confirm every loop index and array dimension: ensure i/j are always within the allocated sizes and that the code doesn’t mix 3‑component and 4‑component arrays by mistake.
  • Verify command‑line indexing before using argv elements (check argc first).
  • Protect normalisation/division by zero with a tiny epsilon and provide a fallback (identity or skip) for zero‑length vectors: 
const double eps = 1e-12;
if (qlen > eps) {
  for (int k = 0; k < 4; ++k) quat[k] /= qlen;
} else {
  // handle zero-length quaternion (set identity, skip, or log)
}
  • Rebuild with debug symbols and optimizations disabled, run under a memory checker (valgrind or AddressSanitizer) and capture a debugger backtrace where the segfault occurs. These tools find invalid reads/writes and uninitialised uses that often show up only with optimizations enabled.
  • If SIMD/alignment is suspected, test with vectorization disabled or force aligned allocations for arrays used in hot loops; also consider compiler optimization reports to see which loops were vectorized.

General notes: random crashes almost always come from memory corruption or UB. Systematically narrow the failing iteration (add bounds assertions or small-range logging) and compare behaviour with/without optimization to isolate the guilty code path.

Recommended Answers

All 5 Replies

Member Avatar for Member #248612

It's only a hint that the compiler generated code which can be executed parallely, IIRC.

Member Avatar for nahmartin

sorry my c++ knowledge is self taught

thank you

when i run the code it will randomly crash with

segmentation fault (i thought this was linked to the compiler remark)

Member Avatar for wildgoose

When one vectorized their code the idea is to have the three or four components processed side by side.

Re-examine your loops as you have a problem. They're all exclusive but some are {0...2} and some are {0...3} for XYZ and XYZW processing. Was that intentional?

You haven't shown your declarations so difficult to tell if you're out of range thus causing your segmentation fault.

Also you only show snippets but do a pre-divide by zero check! Typically in vectors you're just not dividing a vector by a scalar. You are generating a product by multiplying a vector by a reciprocal scalar. If that is the case, if the divisor (typically a magnitude) is very close to zero, then don't do the 'division'. As the divident approaches zero, the result of the reciprocal-square root is negligible thus use the algebraic multiplicative identity (N = N * 1) thus N = N.

Member Avatar for nahmartin

thank you wildgoose

the loops were intentional one is position the other rotation (quaternions)

I have checked for for

pointing to un-initialised variables
and
pointing to outside of allocated vectors and matrices

what else would cause a segmentation fault

i do have this

string style;
char* output_file;

style = argv[1];
output_file = argv[14];

would either cause a segmentation error (Unfortunately i get this error at university using the icc 10.1 compiler so i cannot check myself)

Member Avatar for wildgoose

argv[] You really have 14 command line arguments? [0] is path.

In your matrics [][] you show i as an index but you don't show what it is set to! I'm assuming it contains a valid index?

Other then that I don't spot an indexing error. Provided your vectors are [4] and [4][4].
This is a good time to also make sure your vector's and matrices are properly aligned. The first step is Pseudo Vector code such as you're doing now. The next logical step is using SIMD (Single-Instruction Multiple Data) operands (Assembly Language).

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.