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

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

#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 tp;
    cout << " Answer - " << ok << endl;
    tp:

треба робити просто

//    cout << " Answer - " << ok << endl;

якщо рядків кілька, то

    /*
    cout << " Answer - " << ok << endl;
    */

Це краще за goto, бо дійсно виключає виконання цих рядків, а у вас лишається можливість, що десь іще відбудеться перехід по goto в ніби-то "виключену" зону.

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

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

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