odb: Bazel build fails on linux/aarch64 — char fc compared to EOF in def/lef lexers

Open Beginner friendly
  • Is something wrong?
#12,095 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@shivarammysore is already working on this.

Since Nov 3, 2026.

  • #12105 by @shivarammysore — open

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
80/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
databases

Research direction

Start with the comment-skipping loops near line 531 of src/odb/src/def/def/def_keywords.cpp and line 691 of src/odb/src/lef/lef/lef_keywords.cpp, where fc is declared as char but holds the int result of GETC() or lefGetc(). Change the declaration to int in both files, leaving the other comparisons as they are. Done when the two -Wtautological-constant-out-of-range-compare errors no longer occur in the Bazel build on linux/aarch64.

Written by the indexing model from the issue text.

Description

bazel bug odb
Summary

The Bazel build of //:openroad fails on linux/aarch64 at master f3d27840b65a. Two translation units fail with the same error, and with --keep_going they are the only two failures in the build:

src/odb/src/def/def/def_keywords.cpp:567:16: error: result of comparison of constant -1 with expression of type 'char' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
src/odb/src/lef/lef/lef_keywords.cpp:729:16: error: result of comparison of constant -1 with expression of type 'char' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
Cause

In both lexers the comment-skipping loop stores the result of GETC() / lefGetc() in char fc (def_keywords.cpp:531, lef_keywords.cpp:691) and then tests fc == EOF. Both functions return int and return EOF (-1) at end of input.

  • On aarch64 Linux char is unsigned, so EOF is stored as 255 and the test can never be true. The warning is correct, and -Werror makes it a build failure.
  • x86_64 and Apple arm64 both use signed char, so CI on those platforms does not see this.
Runtime effect (from reading the code, not observed)
  • aarch64: if a # comment is the last line of a DEF/LEF file with no trailing newline, GETC() keeps returning EOF. fc never equals EOF or '\n', so the loop never exits.
  • x86_64: a 0xFF byte inside a comment compares equal to EOF, so the lexer returns early.
Suggested fix

Declare fc as int in both functions, matching the return type of GETC() / lefGetc(). The other comparisons in those blocks (settings->CommentChar, '&', magic[...], '\n') work unchanged with an int. The neighbouring EOF checks in the same files (ch, c, cc) already use int and are not flagged.

Reproduce

On a native linux/arm64 host (we used a GitHub-hosted ubuntu-24.04-arm runner, ubuntu:24.04 container, bazelisk 1.27.0):

bazelisk build --config=release --//:platform=cli --keep_going //:openroad

The hermetic toolchain is llvm-toolchain-minimal-linux-arm64. The same command at the same commit builds cleanly on x86_64.

Happy to send a PR if that's useful.

Dominant language
Verilog
Stars
3.2k
Forks
1.1k
Avg merge
2d 9h
Merged PRs (30d)
270

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from The-OpenROAD-Project/OpenROAD

All issues in The-OpenROAD-Project/OpenROAD

Similar issues

More Databases issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.