Bug 357035 - Uninitialized variable of type double is reported twice in intel-compiled application.
Summary: Uninitialized variable of type double is reported twice in intel-compiled app...
Status: RESOLVED NOT A BUG
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.10 SVN
Platform: RedHat Enterprise Linux Linux
: NOR minor
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-22 12:13 UTC by Tanya
Modified: 2015-12-22 14:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
a reproducer application (108 bytes, text/plain)
2015-12-22 12:13 UTC, Tanya
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tanya 2015-12-22 12:13:20 UTC
Created attachment 96257 [details]
a reproducer application

If an application is built with intel compiler, memcheck reports uninitialized variables of type double twice.

Steps to build and run the test:
    icc -O0 double_report.c -o double_report_icc
    valgrind -q ./double_report_icc
A reproducer (double_report.c) is attached.

Expected result (reported for gcc-compiled application):
==xxxx== Conditional jump or move depends on uninitialised value(s)
==xxxx==    at 0xxxxxxx: main (in /<file_path>/double_report_icc)
==xxxx==

Actual result:
==xxxx== Conditional jump or move depends on uninitialised value(s)
==xxxx==    at 0xxxxxxx: main (in /<file_path>/double_report_icc)
==xxxx==
==xxxx== Conditional jump or move depends on uninitialised value(s)
==xxxx==    at 0xxxxxxx: main (in /<file_path>/double_report_icc)
==xxxx==
Comment 1 Tom Hughes 2015-12-22 14:23:51 UTC
Unfortunately because you've blanked out the addresses it's hard to tell what's going on here... If the addresses are different then the answer would seem to be simply that the compiler is generating code that reads the variable twice. Even if they're the same then the only reasonable explanation I can see is that the compiled code is passing through that instruction twice when run.

In short I suspect this is simply an artefact of the code generated by the compiler rather than any bug in valgrind.
Comment 2 Tanya 2015-12-22 14:36:56 UTC
Tom Hughes, yes, you are correct, the variable is actually read twice. Please feel free to close/discard the ticket.
Comment 3 Tom Hughes 2015-12-22 14:46:24 UTC
Thanks for confirming that.