On 06/10/2011 03:00 AM, Richard Earnshaw wrote:
> On 10/06/11 01:04, Janis Johnson wrote:
>> On 06/08/2011 03:39 AM, Richard Earnshaw wrote:
>>> On 08/06/11 03:14, Janis Johnson wrote:
On 06/07/2011 06:25 PM, Mike Stump wrote:
> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
>> On 06
On 10/06/11 01:04, Janis Johnson wrote:
> On 06/08/2011 03:39 AM, Richard Earnshaw wrote:
>> On 08/06/11 03:14, Janis Johnson wrote:
>>> On 06/07/2011 06:25 PM, Mike Stump wrote:
On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
> On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
>> On Tue
On 06/08/2011 03:39 AM, Richard Earnshaw wrote:
> On 08/06/11 03:14, Janis Johnson wrote:
>> On 06/07/2011 06:25 PM, Mike Stump wrote:
>>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
> On Tue, 7 Jun 2011, Janis Johnson wrote:
>
>>
On 06/08/2011 12:30 PM, Mike Stump wrote:
> On Jun 8, 2011, at 8:28 AM, Janis Johnson wrote:
>> The big question is whether such a test should be run for all multilibs
>> that might possibly pass the test, or only for default and for mulitlibs
>> that provide the same options.
>
> Here, reasonable
On Jun 8, 2011, at 3:39 AM, Richard Earnshaw wrote:
> I'm worried by this whole approach of command-line checking.
Right, and this was essentially my point originally. Luckily there is enough
beef I think behind the curtains to do everything that needs doing without
worrying about adding yet mo
On Jun 8, 2011, at 8:28 AM, Janis Johnson wrote:
> The big question is whether such a test should be run for all multilibs
> that might possibly pass the test, or only for default and for mulitlibs
> that provide the same options.
Here, reasonable people may disagree. I suspect in the end, we'll
On 06/08/2011 03:39 AM, Richard Earnshaw wrote:
> On 08/06/11 03:14, Janis Johnson wrote:
>> On 06/07/2011 06:25 PM, Mike Stump wrote:
>>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
> On Tue, 7 Jun 2011, Janis Johnson wrote:
>
>>
On 08/06/11 03:14, Janis Johnson wrote:
> On 06/07/2011 06:25 PM, Mike Stump wrote:
>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
>>> On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
On Tue, 7 Jun 2011, Janis Johnson wrote:
> Several tests in gcc.target/arm use dg-options with -mc
On 06/07/2011 06:25 PM, Mike Stump wrote:
> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
>> On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
>>> On Tue, 7 Jun 2011, Janis Johnson wrote:
>>>
Several tests in gcc.target/arm use dg-options with -mcpu=, which
causes compiler warnings or
On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
> On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
>> On Tue, 7 Jun 2011, Janis Johnson wrote:
>>
>>> Several tests in gcc.target/arm use dg-options with -mcpu=, which
>>> causes compiler warnings or errors when the multilib flags include
>>> -mar
On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
> On Tue, 7 Jun 2011, Janis Johnson wrote:
>
>> Several tests in gcc.target/arm use dg-options with -mcpu=, which
>> causes compiler warnings or errors when the multilib flags include
>> -march=. This patch causes those tests to be skipped.
On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
> On Tue, 7 Jun 2011, Janis Johnson wrote:
>
>> Several tests in gcc.target/arm use dg-options with -mcpu=, which
>> causes compiler warnings or errors when the multilib flags include
>> -march=. This patch causes those tests to be skipped.
On Tue, 7 Jun 2011, Janis Johnson wrote:
> Several tests in gcc.target/arm use dg-options with -mcpu=, which
> causes compiler warnings or errors when the multilib flags include
> -march=. This patch causes those tests to be skipped. It also
> prevents gcc.target/arm/20090811-1.c from ru
Several tests in gcc.target/arm use dg-options with -mcpu=, which
causes compiler warnings or errors when the multilib flags include
-march=. This patch causes those tests to be skipped. It also
prevents gcc.target/arm/20090811-1.c from running with multilibs that
would override -mcpu or
14 matches
Mail list logo
