IOI 2026 Grading Environment

All submissions at IOI 2026 will be evaluated through CMS (Contest Management System).

Contestants' C++ submissions are compiled on Linux using GCC version 13.3 or later – matching the compiler installed on the contestant machines themselves.

CMS will display the precise compilation command used for each submission. For most task types, it follows this pattern:

/usr/bin/g++ -DEVAL -std=gnu++20 -O2 -pipe -static -s -o task grader.cpp task.cpp

CMS may flag a submission with a Protocol Violation verdict when a program doesn't interact with the grader the way the task statement requires. Common triggers include:

• Reading directly from standard input or writing to standard output when this isn't permitted
• Calling exit()

Other protocol mistakes – especially incorrect calls to grader functions – are usually treated as a wrong answer rather than a protocol violation, and will appear in CMS as one of:

• Output isn't correct: Invalid argument – a grader function was called with arguments that don't satisfy the task's constraints
• Output isn't correct: Too many calls – a grader function was invoked more times than the task allows

For tasks that include output-only subtasks, contestants may submit:

• No more than one C++ source file
• Any number of output files – including zero – with at most one output file per output-only subtask

Submissions are scored as follows:

• For programming subtasks, the source file (when present) is compiled and graded; if none is submitted, that subtask scores 0.
• For each output-only subtask: if a dedicated output file was submitted for it, that file is graded directly. If not, but a source file was submitted, CMS compiles and runs it, then grades the resulting output according to the protocol described for that specific subtask in the task statement.

Each task on the contest system comes with a downloadable package containing:

• Sample graders
• Reference/sample solutions
• Example test data
• Scripts to compile, run, and submit your solution

Every task also includes a special subtask numbered 0, worth zero points. Unless the task statement says otherwise, its test data is identical to the sample cases shown in the statement and included in the attachment package.

When testing locally, contestants are encouraged to use the scripts provided in the attachment package rather than compiling manually. Note that the contest uses the -std=gnu++20 standard.

The sample grader included with each task is a simplified tool meant to help you run your own solution – it is not the same grader CMS uses for official judging. In many cases it does nothing more than print your solution's output, without checking whether it's actually correct.

When you run your solution through the sample grader, make sure your input strictly matches the format and constraints given in the task statement; deviating from this may produce unpredictable results. Unless stated otherwise, tokens on the same line are separated by a single space.

Input/output formats in task statements are written using symbolic placeholders. For example:

N         M
A[0]      A[1]    …    A[N-1]
P[0]      Q[0]
P[1]      Q[1]
…
P[M-1]    Q[M-1]

Here's how to read it:

1. Line 1 holds N and M, separated by a space.
2. Line 2 holds N space-separated values: A[0] through A[N-1].
3. Important. This notation doesn't guarantee at least three values appear – N could be 1 (a single value) or even 0 (an empty line).
4. The following M lines each hold one pair from arrays P and Q. As with N, M could be 0 or 1.

If a call to a sample grader function breaks one of the task's constraints, the sample grader will typically print an error and stop immediately. Unless the task says otherwise, the message will be one of:

• Invalid argument – the function was called with values that violate a stated or implied constraint
• Too many calls – the function was called more times than the task statement allows

Contestants are welcome to look through the sample grader's source code to understand exactly what causes this error, and may even modify their local copy to print more detailed diagnostics.

Besides uploading through the CMS website, contestants can also submit using the submit script bundled in each task's attachment package.

• For tasks that take a single source file, run the script with one argument – the name of that file.
• For tasks that accept or require output files, run the script with all the files you want to submit (output files, source code, or both). Output files must follow the exact naming convention shown in the CMS interface; to make this easier, the attachment package already includes empty placeholder files with the correct names.

The script first tries to submit your files online through CMS. If that succeeds, your submission and its feedback will show up in the CMS interface as usual. If it fails for any reason – including a timeout – the submission is instead saved locally on your machine.

After the contest ends, the scientific committee gathers any locally saved submissions and imports them into CMS in chronological order. If a contestant ends up with more submissions than the task allows, online submissions are prioritized over offline ones, and among offline submissions, earlier ones take precedence over later ones.