Ebiarat's blog

By Ebiarat, history, 7 weeks ago, In English

Hi everyone! for now i was using this
#pragma GCC target ("avx2") #pragma GCC optimization ("O3") #pragma GCC optimization ("unroll-loops") in my template ,howewer i got WA 2 times due to this pragmas.

i have heard that pragmas can cause TLE but i have never heard that this can cause WA. So can any one tell how pragmas really work and why it can cause WA?

 
 
 
 
  • Vote: I like it
  • -8
  • Vote: I do not like it

»
7 weeks ago, # |
  Vote: I like it +3 Vote: I do not like it

Without any other information or a source code to look at, I can only speculate that it might have been a usual case of a https://en.wikipedia.org/wiki/Heisenbug

»
7 weeks ago, # |
  Vote: I like it +3 Vote: I do not like it

gcc at -O2 and up will try to remove as much code as possible (fastest code is nonexistent code) and if you happen to be using something that's reliable/predictable but technically undefined behavior, it'll look like sections of your code are just weirdly missing. A TLE can come from a loop being told to terminate after an int rolls over at its max, buuut since that predictable reliable rollover to min is technically undefined, the check that depends on that value will just get nuked and the loop allowed to run indefinitely. Again, given the 'take it out if undefined' behavior from some types of optimizations, it's not hard to imagine something similar resulting in a WA. Or not. Hard to say without any code.

  • »
    »
    7 weeks ago, # ^ |
    Rev. 4   Vote: I like it 0 Vote: I do not like it

    https://pastebin.com/XTizxz2t exactly same code with pragmas get WA. however there is no statement in english so i cant give u a link for problem. But if u want i can tell u a problem statement its quite interesting problem indeed

    • »
      »
      »
      7 weeks ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Hard to say without asking for more and more context (re: problem or platform)...

      A thing that looks like it could be at-all system-dependent-ish is the integer casts on 1e## which are floating point literals + another int. If you write out those sums into their respective integer literal forms (with type suffix thingy), that'd serve to at least rule out this overly specific type of bug... but even then that'd be stoopid weird since the warnings are clear that they're not even used except for nax which isn't especially large/overflow-y...?