On 12/22/2015 02:54 AM, Nick Clifton wrote:
Hi Jeff,
PR 68913 notes that the test gcc.dg/lto/pr61886_0.c test fails on
targets whose C library does not provide a __fread_chk function.
Since the purpose of the test is to show that GCC will correctly
discard the invocation of __fread_chk_warn, we do not need to
actually
link against a real __fread_chk function. A dummy will do.
? Isn'the purpose of this test to verify the function alias resolution
code?
I think that it is, but that the test does this by requiring that gcc
only generates code that calls __fread_chk. Ie it does not generate any
code that calls __fread_chk_warn. If gcc did generate code that calls
__fread_chk_warn then that function's warning attribute would be
triggered and we would get the warning message associated with it - and
the test would fail.
But does the existence of the weak fread_chk change the interactions
inside IPA & LTO in such a way as to compromise the test?
One way to find out would be to check out a compiler before Honza's
change which fixed 61886, verify the test as written fails, verify the
test with your new weak symbol also fails. Honza didn't fix this until
early December, so you don't have to go terribly far back.
Since the test only links, it does not execute, there is no need to have
working versions of __fread_chk and __fread_chk_warn available. All
that is necessary is that a symbol called __fread_chk is available at
link time. (A symbol called __fread_chk_warn is not needed as
referencing this symbol triggers a warning, which causes the test to
fail). So providing a weak definition of __fread_chk should be
sufficient for those runtimes which do not provide their own definition.
Right. I'm not worried about any of this stuff. I'm worried about the
hideous problems with had in the IPA/LTO bits. Just look at the long
discussion in 61886.
jeff
