Bug 114627 - undefined behavior in tree-profile.cc while compiling gcc.misc-tests/gcov-18.c
Summary: undefined behavior in tree-profile.cc while compiling gcc.misc-tests/gcov-18.c
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: testsuite-fail
Depends on:
Blocks: ubsan
  Show dependency treegraph
 
Reported: 2024-04-07 09:43 UTC by Filip Kastl
Modified: 2024-09-10 09:59 UTC (History)
1 user (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Kastl 2024-04-07 09:43:38 UTC
Compiling gcc.misc-tests/gcov-19.c using ubsan-instrumented GCC

gcc testsuite/gcc.misc-tests/gcov-19.c -fdiagnostics-plain-output -fcondition-coverage -ftest-coverage -lm -o ./gcov-19.exe

results in

/home/worker/buildworker/tiber-gcc-ubsan/build/gcc/tree-profile.cc:1090:48: runtime error: shift exponent 64 is too large for 64-bit type 'long long unsigned int'

Compiler configured with
--enable-languages=default,jit,lto,go,d --enable-host-shared --enable-checking=release --disable-multilib --with-build-config=bootstrap-ubsan
Comment 1 Richard Biener 2024-04-08 08:45:23 UTC
it's not a regression from older GCC since -fcondition-coverage is new
Comment 2 GCC Commits 2024-04-09 07:58:06 UTC
The master branch has been updated by J?rgen Kvalsvik <jkv@gcc.gnu.org>:

https://gcc.gnu.org/g:a2447556a5405d2cde20afc134b90cd1d199ce04

commit r14-9864-ga2447556a5405d2cde20afc134b90cd1d199ce04
Author: Jørgen Kvalsvik <j@lambda.is>
Date:   Mon Apr 8 15:19:55 2024 +0200

    Generate constant at start of loop, without UB
    
    Generating the constants used for recording the edges taken for
    condition coverage would trigger undefined behavior when an expression
    had exactly 64 (== sizeof (1ULL)) conditions, as it would generate the
    constant for the next iteration at the end of the loop body, even if there
    was never a next iteration. By moving the check and constant generation
    to the top of the loop and hoisting the increment flag there is no
    opportunity for UB.
    
            PR middle-end/114627
    
    gcc/ChangeLog:
    
            * tree-profile.cc (instrument_decisions): Generate constant
            at the start of loop.
Comment 3 Martin Jambor 2024-09-10 09:59:54 UTC
So, should this be marked as fixed?