This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: target/6569: sparc-sun-solaris2.7 C testsuite regression in compile/20011119-2.c


At 16:40 07.05.2002, Mark Mitchell wrote:


>--On Tuesday, May 07, 2002 03:14:49 PM +0200 Franz Sirl 
><Franz.Sirl-kernel@lauterbach.com> wrote:
>
>>At 14:45 07.05.2002, Kaveh R. Ghazi wrote:
>>>  > From: Mark Mitchell <mark@codesourcery.com>
>>>  >
>>>  > >> Can you try the attached patch? It seems to work for me, but the
>>>  > >> bootstrap hasn't completed yet. While I was at it, I improved the
>>>  > >> placing of the warning messages. I'm still a bit confused, cause it
>>>  > >> sometimes seems olddecl and newdecl appeared to be swapped
>>>  > >> compared to their sourcefile ordering.
>>>  > >
>>>  > > FYI, bootstrap+regtest on x86-linux-gnu completed successfully.
>>>  >
>>>  > OK; once you have confirmation of the SPARC results go ahead and
>>>  > check it in.
>>>
>>>Unfortunately, the patch did not solve the problem listed in the PR.
>>>I still get the same 'as' errors from compile/20011119-2.c
>>>
>>>compile/20011119-2.c:3: warning: weak declaration of `foo' after first
>>>use  results in unspecified behavior
>>>/usr/ccs/bin/as: "/var/tmp//ccQOIg1d.s", line 51: error: invalid operand
>>>--------------------------------------------------^^^^^
>>
>>Yeah, I managed to get access to a solaris-2.8 machine, even though I
>>wasn't able to bootstrap with Solaris as/ld (see below), I was able to
>>reproduce the failure. Re-checking on x86-linux-gnu revealed that it even
>>doesn't fix the problem there, so I must have mixed something up
>>yesterday. Frankly, I'm a bit at a loss here, cause I've tried several
>>strategies yesterday and they either didn't fix the testcase or caused
>>some of the weak tests to fail. Especially I tried to use the TREE_USED
>>flag of the WEAK_DECLS TREE_LIST to mark when a weak already had been
>>assembled, but it didn't work out :-(. I seem to misunderstand something
>>about how the tree structures are handled.
>
>I'll look into this problem.

FYI, this is the patch I'm currently playing with, it would fix 20011119-2, 
but these fail:

FAIL: gcc.dg/weak-3.c scan-assembler weak[^     ]*[     ]ffoo1b
FAIL: gcc.dg/weak-3.c scan-assembler weak[^     ]*[     ]ffoo1c
FAIL: gcc.dg/weak-3.c scan-assembler weak[^     ]*[     ]ffoo1e
FAIL: gcc.dg/weak-5.c scan-assembler weak[^     ]*[     ]vfoo1b
FAIL: gcc.dg/weak-5.c scan-assembler weak[^     ]*[     ]vfoo1c

I don't understand what I'm doing wrong :-(.

Franz.

Attachment: gcc-weaksym-9x1.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]