use maximum start_x from overlapping blockages found when cutting rows

[openroad-ci]

Summary

Fixes #10146.
Use std::max when updating start_origin_x.

Type of Change

• Bug fix

Impact

Tapcell are not placed overlapping with macros.

Verification

• I have verified that the local build succeeds (./etc/Build.sh).
• I have run the relevant tests and they pass.
• My code follows the repository's formatting guidelines.
• I have signed my commits (DCO).

Related Issues

#10146

[gemini-code-assist]

Code Review

This pull request modifies the cutRow function in src/odb/src/db/util.cpp to ensure start_origin_x is updated correctly using std::max when handling blockages. A review comment identifies a potential issue where invalid segments could still be created if seg_end is less than start_origin_x, suggesting a conditional check or interval merging as a more robust solution.

[gemini-code-assist]

While this change correctly updates start_origin_x for overlapping blockages, it doesn't prevent the creation of invalid segments. If a blockage overlaps with a previous one, start_origin_x could be greater than blockage.first in the next iteration. This would cause seg_end (calculated on line 102) to be less than start_origin_x, leading to an invalid segment being created on line 103.

A check should be added before line 103 to ensure seg_end > start_origin_x, for example:

if (seg_end > start_origin_x) {
  segments.emplace_back(start_origin_x, seg_end);
}

A more robust long-term solution would be to merge the overlapping row_blockage_xs intervals after sorting. This would simplify the loop and make the logic clearer.

References

1. When analyzing code within a loop, consider the entire loop structure. Operations at the beginning of the loop or pre-processing (like merging intervals) can affect the logic within the loop body, potentially simplifying it or making certain checks redundant.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"