This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, testsuite]: Fix PR target/48055; FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto
On Thu, Mar 10, 2011 at 3:59 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>> <richard.guenther@gmail.com> wrote:
>>
>>>> Using binutils-2.21, a couple of
>>>> gcc.c-torture/execute/builtins/__-chk.c testcases fail on
>>>> alphaev68-pc-linux-gnu (-lto) with:
>>>>
>>>> /usr/lib/gcc/alpha-unknown-linux-gnu/4.4.5/../../../../alpha-unknown-linux-gnu/bin/ld:
>>>> Warning: alignment 8 of symbol `buf5' in
>>>> /tmp/ccgnDykf.ltrans1.ltrans.o is smaller than 16 in
>>>> /tmp/ccc3QsSw.o.ironly
>>>> /usr/lib/gcc/alpha-unknown-linux-gnu/4.4.5/../../../../alpha-unknown-linux-gnu/bin/ld:
>>>> Warning: alignment 8 of symbol `buf7' in
>>>> /tmp/ccgnDykf.ltrans1.ltrans.o is smaller than 16 in
>>>> /tmp/ccc3QsSw.o.ironly
>>>> /usr/lib/gcc/alpha-unknown-linux-gnu/4.4.5/../../../../alpha-unknown-linux-gnu/bin/ld:
>>>> Warning: alignment 8 of symbol `buf1' in
>>>> /tmp/ccgnDykf.ltrans1.ltrans.o is smaller than 16 in
>>>> /tmp/ccc3QsSw.o.ironly
>>>>
>>>> Attached patch fixes these failures.
>>>
>>> I think this needs more investigation as there are no conflicting
>>> definitions of those vars that would warrant this kind of diagnostic from ld.
>>>
>>> We probably bring the vars local by making them hidden and distribute
>>> them to multiple ltrans units (with only one definiton obviously and multiple
>>> externs).
>>
>> Jan claims that this problem is a linker bug, so perhaps the patch is
>> still suitable for the gcc testsuite. The patch doesn't alter tests in
>> any way, while it avoids false positives due to linker bugs.
>
> Are you sure? ?Making the vars static enables folding the zero initialization.
I was looking at other similar testcases (snprintf-chk.c,
vsprintf-chk.c), where uninitialized buffer is declared as static (and
it didn't fail lto tests). Anyway, let's ask the author of the test
(CC'd).
> I don't think we should make testsuite changes to paper over bugs
> elsewhere.
How far do we want to reach in case the test uncovers the problem in
(sort of...) unrelated product?
Uros.