то ж дуже очевидна задачка, розв'яжіть її самі

Ну в мене вийшло якось так. Перевірте пліз, бо мого теста може і не вистачити

#include <iostream>
#include <cstdlib>
#include <cmath>

using namespace std;

int main(int argc, char** argv) {
    system("chcp 1251 >> nul");
    setlocale(LC_ALL, "UKR");
    cout.setf(ios::boolalpha);
    
    int x, y;
    cout << " X = "; cin >> x;
    cout << " Y = "; cin >> y;
    
    bool ok = (x==y);
    bool ok1 = ((x%2==1)||(y%2==1));
    goto tp;
    
    cout << " Answer - " << ok << endl;
    tp:
    cout << " Answer - " << ok1 << endl;
         
    cout << endl << endl << endl << endl << endl << endl << endl << endl << endl;
    system("pause");
    return 0;
}

тепер ясно, я назви тих значків забув

Я чогось думав, у наші часи на тих, хто пише goto, нападають динозаври.
До рядка, який іде після безумовного переходу перед найближчою після нього міткою, потрапити неможливо, тому можете спокійно його стерти чи закоментувати — на хід роботи це не вплине. А позбувшись його, ви отримаєте

goto tp;
tp: 

тобто, перехід на мітку, що стоїть у тому ж місці, куди б ми потрапили, якби goto не було; переходів на tp з інших місць програми також нема — можете стерти й ці два рядки.

Це, звичайно, добре, що сучасні процесори працюють достатньо швидко, щоб ми не відчували різниці між обчисленнями цих виразів, але "(x^y)&1" є оптимальнішим, а "(x+y)%2" змушує ганяти зайві біти при додаванні і немає гарантії, що компілятор проведе оптимізацію для ...%2.
І на рахунок "лякало б менше", такі операції (&, ^, |, &&, ||) мають вивчатися перед арифметичними операціями, бо вони простіші, тобто потребують менше бітових перетворень.

Але як? Хіба що перед goto можна дописати if або while, тоді перехід стане умовним — відповідно, в «виключену» зону стане можливо потрапити.

Хоча справді, загальноприйнята практика в наш час — закоментувати непотрібний рядок. Це краще ще й тому, що закоментований код при компіляції пропускається (а обійдений — усе одно компілюється) — не треба турбуватися про помилки в непотрібних рядках, а кінцева відкомпільована програма виходить компактнішою. А ще, перехід на мітку поганий тим, що імена міток, якщо їх декілька, можна переплутати, а тоді довго намагатися зрозуміти, в якому порядку програма виконується.

Та ну, на всіх відомих мені архітектурах (тобто не лише тих, де я реально кодив на асмі, а і тих, де я лише читав документацію, сюди входять і дво- та чотири-бітові секції арифметико-логічних пристроїв секціонованих процесорів) всі базові операції АЛП між двома регістрами займають однаковий час. Тобто різний час виконання XOR і ADD це щось взагалі нереальне.
Щодо оптимізації, то сперечатися важче, але для сучасного компілятора при хоч якійсь оптимізації (не аналог -O0 для gcc) вважаю відмінність вкрай малоймовірною
.
Що стосується gcc, то лінукс-x86-84, arm-none-eabi для Cortex-M3 і avr-gcc, як я щойно перевірив, навіть при -O0 для обох цих варіантів дає код, що відрізняється лише одним рядком, add замість xor (eor), про час виконання якого див. вище.