On 02/16/2012 04:32 PM, Mike Stump wrote:
On Feb 16, 2012, at 12:47 PM, Rainer Orth wrote:
Even with the 20-second timeout, I was seeing lots of failures on slower
machines, like sparc, alpha, or mips. I've had good success with the
following patch which uses the default dejagnu timeout instead
On Feb 16, 2012, at 12:47 PM, Rainer Orth wrote:
> Even with the 20-second timeout, I was seeing lots of failures on slower
> machines, like sparc, alpha, or mips. I've had good success with the
> following patch which uses the default dejagnu timeout instead of some
> arbitrary value. It even ta
Andrew MacLeod writes:
> On 02/09/2012 09:38 AM, Uros Bizjak wrote:
>> On Thu, Feb 9, 2012 at 3:12 PM, Aldy Hernandez wrote:
>>
>> It was me, and the sole reason was that timeout didn't worked and the
>> log filled the file system. After timeout functionality was fixed, the
>> timeout was forced
On 02/09/2012 09:38 AM, Uros Bizjak wrote:
On Thu, Feb 9, 2012 at 3:12 PM, Aldy Hernandez wrote:
It was me, and the sole reason was that timeout didn't worked and the
log filled the file system. After timeout functionality was fixed, the
timeout was forced to 10 seconds. It is an arbitrary numb
On Thu, Feb 9, 2012 at 3:12 PM, Aldy Hernandez wrote:
>> I think there was a defect for that... Anyway, I think 10 seconds just
>> came out of someones imagination, but I'm not sure. Was that you Aldy?
>
>
> I really can't remember, but it's possible.
It was me, and the sole reason was that time
I think there was a defect for that... Anyway, I think 10 seconds just
came out of someones imagination, but I'm not sure. Was that you Aldy?
I really can't remember, but it's possible.
Given thats the case, I'd be more tempted long term to simply disable
the line by line output into the lo
On 02/08/2012 04:22 PM, Mike Stump wrote:
On Feb 8, 2012, at 5:11 AM, Andrew MacLeod wrote:
On 02/07/2012 07:55 PM, Mike Stump wrote:
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
test
On Feb 8, 2012, at 8:02 AM, Andrew MacLeod wrote:
> Presuming that it runs properly, is this OK for mainline?
Ok.
On Feb 8, 2012, at 5:11 AM, Andrew MacLeod wrote:
> On 02/07/2012 07:55 PM, Mike Stump wrote:
>> On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
>>> Currently we are failing...
>>>
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
>>> simulation test
>>> FAIL: gcc.dg/simulate
On 02/08/2012 11:43 AM, Jack Howarth wrote:
So something like the following changes:
I'm running a testsuite run on x86-64 right now, I'll try arm as well
shortly. Presuming that it runs properly, is this OK for mainline?
Andrew,
I can confirm that this eliminates the unexpected failu
On Wed, Feb 08, 2012 at 11:02:02AM -0500, Andrew MacLeod wrote:
> On 02/08/2012 09:47 AM, Andrew MacLeod wrote:
>>
>> I propose increasing the time to 20 seconds and reduce the log file.
>> I believe the timeout as made really short because of the size of the
>> log file when the timeout was n
On 02/08/2012 09:47 AM, Andrew MacLeod wrote:
I propose increasing the time to 20 seconds and reduce the log file.
I believe the timeout as made really short because of the size of the
log file when the timeout was needed. I htink it was an arbitrary
number. Doubling the execution time and
On 02/08/2012 09:27 AM, Jack Howarth wrote:
On Wed, Feb 08, 2012 at 09:00:00AM -0500, Andrew MacLeod wrote:
On 02/08/2012 08:37 AM, Iain Sandoe wrote:
Well - it depends. You don't know whether the test will eventually
terminate,
but yes, you could interpret "UNRESOLVED" as exactly what that is
On Wed, Feb 08, 2012 at 09:00:00AM -0500, Andrew MacLeod wrote:
> On 02/08/2012 08:37 AM, Iain Sandoe wrote:
>>
>>> Well - it depends. You don't know whether the test will eventually
>>> terminate,
>>> but yes, you could interpret "UNRESOLVED" as exactly what that is. A
>>> definite finishes-ne
On 02/08/2012 08:37 AM, Iain Sandoe wrote:
Well - it depends. You don't know whether the test will eventually
terminate,
but yes, you could interpret "UNRESOLVED" as exactly what that is. A
definite finishes-never would be a FAIL of course. The question is
on which
side to err.
There w
On 8 Feb 2012, at 13:33, Richard Guenther wrote:
On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod
wrote:
On 02/07/2012 07:55 PM, Mike Stump wrote:
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod wrote:
> On 02/07/2012 07:55 PM, Mike Stump wrote:
>>
>> On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
>>>
>>> Currently we are failing...
>>>
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
>>> simulation test
>>> FAIL: gcc.d
On 02/07/2012 07:55 PM, Mike Stump wrote:
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread simulation
test
FAIL: gcc.
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
> Currently we are failing...
>
> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
> test
> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread simulation
> test
> FAIL: gcc.dg/simulate-thread/atomic-load-
On Wed, Dec 07, 2011 at 08:09:06PM +0100, Uros Bizjak wrote:
> On Wed, Dec 7, 2011 at 7:58 PM, Iain Sandoe
> wrote:
>
> >>> Currently we are failing...
> >>>
> >>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
> >>> simulation test
> >>> FAIL: gcc.dg/simulate-thread/atomic-loa
On Wed, Dec 7, 2011 at 7:58 PM, Iain Sandoe
wrote:
>>> Currently we are failing...
>>>
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread
>>> simulation test
>>> FAIL: gcc.dg/simulate-thre
On 7 Dec 2011, at 18:47, Uros Bizjak wrote:
On Wed, Dec 7, 2011 at 7:43 PM, Jack Howarth
wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
simulation test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread
simulation test
On Wed, Dec 7, 2011 at 7:43 PM, Jack Howarth wrote:
> Currently we are failing...
>
> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
> test
> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread simulation
> test
> FAIL: gcc.dg/simulate-thread/atomic-lo
23 matches
Mail list logo
