It can be useful to customize the build wrapper for local needs: for
instance, one may need to compile additional objects to add
initialization code depending on the target board or multilibs in use.
2020-09-14 Torbjörn SVENSSON
* lib/libgloss.exp (build_wrapper): Call build_wrapper_hoo
On Tue, 19 May 2020 at 00:36, Jacob Bachmeyer wrote:
>
> Rob Savoye wrote:
> > On 5/18/20 2:16 PM, Jacob Bachmeyer wrote:
> >
> >> My work on DejaGnu is one of my hobbies. However, DejaGnu is a
> >> relatively stable project, so I do not expect it to require much time.
> >>
> >
> > To adequatel
On Wed, 13 May 2020 at 19:44, Jonathan Wakely via Gcc wrote:
>
> On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc wrote:
> >
> > I've changed the subject to match the 2015, 2017 and 2018 email threads.
> >
> > On May 13, 2020, at 3:26 AM, Thomas Schwinge
> > wrote:
> > >
> > > Comparing DejaGnu
On Wed, 5 Jun 2019 at 12:42, Pedro Alves wrote:
>
> On 6/4/19 5:22 PM, Christophe Lyon wrote:
> > Hi,
> >
> > I've been debugging a problem where we clear "isremote" with:
> > unset_board_info isremote
> > set_board_info isremote 0
> > but
Hi,
I've been debugging a problem where we clear "isremote" with:
unset_board_info isremote
set_board_info isremote 0
but this isn't taken into account correctly by is_remote (in
framework.exp), when we use target variants, because is_remote removes
the target variant specifications.
For instance
On 2 June 2017 at 11:35, Georg-Johann Lay wrote:
> Hi, when I am running gcc test suite
>
> $ make check-gcc RUNTESTFLAGS='-all ubsan.exp=float-cast-overflow-2.c'
>
> === gcc tests ===
>
> Schedule of variations:
> unix
>
> Running target unix
> Using /usr/share/dejagnu/baseboa
On 31 March 2016 at 16:11, Christophe Lyon wrote:
> On 31 March 2016 at 12:20, Ben Elliston wrote:
>> On Thu, Mar 31, 2016 at 12:11:59PM +0200, Christophe Lyon wrote:
>>
>>> But since we currently have "|&cat", we do redirect stderr, so the
>>> &qu
On 13 April 2016 at 00:19, Ben Elliston wrote:
> Hi Christophe
>
> On Tue, Apr 12, 2016 at 05:02:28PM +0200, Christophe Lyon wrote:
>
>> The attached patch fixes this. Note that I also needed to patch
>> GCC's testsuite/lib/gcc-dg.exp because we now return unresolv
t 0] }
}
set result [list $status [lindex $result 1]]
}
I will submit it separately of course.
OK?
Christophe
2016-04-12 Christophe Lyon
* lib/rsh.exp (rsh_exec): Handle regexp return status.
diff --git a/lib/rsh.exp b/lib/rsh.exp
index 123f245..c5d1cfc 10
On 31 March 2016 at 12:20, Ben Elliston wrote:
> On Thu, Mar 31, 2016 at 12:11:59PM +0200, Christophe Lyon wrote:
>
>> But since we currently have "|&cat", we do redirect stderr, so the
>> "and that standard error is not redirected" claude above is not
On 30 March 2016 at 10:47, Ben Elliston wrote:
> On Wed, Mar 30, 2016 at 10:15:46AM +0200, Christophe Lyon wrote:
>
>> Well, I re-ran it, and I still have no evidence of using standard_wait.
>> Are you running native validations?
>
> Yes.
>
>> I remind you
On 31 March 2016 at 12:03, Ben Elliston wrote:
> On Thu, Mar 31, 2016 at 11:11:14AM +0200, Christophe Lyon wrote:
>
>> It seems that the remote stdout/stderr are merged by tcl, rather
>> than dejagnu, since replacing "|&cat" in dejagnu with "2>/dev/nul
On 31 March 2016 at 11:06, Maxim Kuvyrkov wrote:
> On Mar 30, 2016, at 6:36 PM, Christophe Lyon
> wrote:
>>
>> On 30 March 2016 at 15:44, Maxim Kuvyrkov wrote:
>>> Hi Ben,
>>> Hi Christophe,
>>>
>>> [TL;DR] Will it be a problem for d
On 30 March 2016 at 17:28, Yvan Roux wrote:
> On 30 March 2016 at 17:18, Christophe Lyon wrote:
>> On 30 March 2016 at 17:03, Yvan Roux wrote:
>>> Hi,
>>>
>>> https://lists.gnu.org/archive/html/dejagnu/2015-07/msg0.html
>>>
>>> this
ses. It does send its output to stderr, so I expected the test
to fail given its output was discarded.
Any idea why stderr it still reaching dejagnu?
> --
> Maxim Kuvyrkov
> www.linaro.org
>
>
>
>> On Mar 30, 2016, at 11:47 AM, Ben Elliston wrote:
>>
>> On
On 30 March 2016 at 17:03, Yvan Roux wrote:
> Hi,
>
> https://lists.gnu.org/archive/html/dejagnu/2015-07/msg0.html
>
> this patch introduced a new failure related to GDB testing, but this
> time in GCC guality part of the testsuite. When
> gcc/testsuite/gcc.dg/guality/example.c is executed w
On 29 March 2016 at 22:20, Ben Elliston wrote:
> On Tue, Mar 29, 2016 at 10:09:20PM +0200, Christophe Lyon wrote:
>
>> However, a manual of the gcc testsuite indicates that we don't use
>> standard_wait.
>
> I think you're wrong. :-)
>
> $ make RUNTESTFLAG
On 26 March 2016 at 15:29, Ben Elliston wrote:
> I found the problem. The sanitiser execution tests produce a lot of
> output (~20KB on stderr). Somtimes, when EOF is matched in
> standard_wait, there are unmatched characters left in the expect
> buffer. These need to be appended to $output. Th
On 26 March 2016 at 00:25, Ben Elliston wrote:
> On Fri, Mar 25, 2016 at 05:54:53PM +0100, Christophe Lyon wrote:
>
>> At this point, I don't know where the problem is. We've been seeing
>> random results mostly in the sanitizer tests for months.
>
> I'll
On 25 March 2016 at 17:01, Rob Savoye wrote:
> On 03/25/2016 08:57 AM, Christophe Lyon wrote:
>
>> Well, as Yvan showed with his recent patches, we seem to be using
>> DejaGnu in an unusual configuration, which uncovers corner case bugs.
>
> As I've mentione
On 25 March 2016 at 05:20, Ben Elliston wrote:
> On Thu, Mar 24, 2016 at 03:53:16PM +0100, Christophe Lyon wrote:
>
>> We suspect that the non-ordered nature of stdout vs stderr is causing
>> random problems in our GCC validations.
>
> Really? We've been testing
Hi,
We suspect that the non-ordered nature of stdout vs stderr is causing
random problems in our GCC validations.
I wanted to experiment with forcing separation between stdout and
stderr, then concatenating them, but so far I haven't been able to
twist dejagnu to do so.
I wanted to make use of
Hi,
I have spent some time trying to understand why isatty(2) in a target
program returned a different value when I executed the GCC testsuite
natively on an ARM board and when executed via qemu.
It turns out that:
- when running natively, stderr is handled as a pipe between the
target program an
23 matches
Mail list logo
