Re: [PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

> Date: Wed, 14 Aug 2024 22:12:23 -0500 > From: Jacob Bachmeyer > Done and pushed to Savannah as commit > ed301dbd6a3d769670503ccfda1ea31b58d02547. Please confirm that this > solves the problem. Confirmed*... > (Also note that you can now run DejaGnu from a Git checkout, simply use > the "r

Re: [PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

> Date: Wed, 14 Aug 2024 20:58:04 -0500 > From: Jacob Bachmeyer > Reply-To: jcb62...@gmail.com > Hans-Peter Nilsson wrote: > > (CC to the dejagnu project as a heads-up) > > > > Regtested cris-elf with a fresh newlib checkout where 2640 > > libstdc++-v3 tes

[PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

(CC to the dejagnu project as a heads-up) Regtested cris-elf with a fresh newlib checkout where 2640 libstdc++-v3 tests otherwise fail due to the stubbed newlib _getentropy. Ok to commit? -- >8 -- Newer newlib trigger warnings about certain functions not implemented (_getentropy) when testing li

Re: Generalizing DejaGnu timeout scaling (was: Re: [PATCH DejaGNU/GCC 0/1] Support per-test execution timeout factor)

On Wed, 3 Jan 2024, Jacob Bachmeyer wrote: > Comments before I start on an implementation? I'd suggest to await the conclusion of the debate: I *think* I've proved that dg-timeout-factor is already active as intended (all parts of a test), specifically when the compilation result is executed (f

Re: [PATCH DejaGNU/GCC 0/1] Support per-test execution timeout factor

On Wed, 3 Jan 2024, Maciej W. Rozycki wrote: > On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote: > > > > The test execution timeout is different from the tool execution timeout > > > where it is GCC execution that is being guarded against taking excessive > > >

Re: [PATCH DejaGNU/GCC 0/1] Support per-test execution timeout factor

On Tue, 12 Dec 2023, Maciej W. Rozycki wrote: > Hi, > > This patch quasi-series makes it possible for individual test cases > identified as being slow to request more time via the GCC test harness by > providing a test execution timeout factor, applied to the tool execution > timeout set glob

heads-up: libgloss scripts in board files and "-Wl,"-stripping bad

To summarize what I wrote in , the use in board files of scripts which are installed as part of libgloss, is problematic when testing the simulator, where most tests just require an assembler and linker. Not sure how to fix that other tha

Re: SIM env. variable question in baseboards

> From: Steve Ellcey > Date: Fri, 25 May 2012 19:09:13 +0200 > So, as a strawman proposal, perhaps we should have a baseboard that > checks the env. variables: > > DEJAGNU_SIM > DEJAGNU_SIM_LDFLAGS > DEJAGNU_SIM_CFLAGS Sounds great. > I wonder if we should also allow somethin

Re: SIM env. variable question in baseboards

> From: Steve Ellcey > Date: Fri, 25 May 2012 02:06:34 +0200 > Are you thinking of something like: > > if {[info exists DEJAGNU_SIM_LDFLAGS]} { > set_board_info ldflags "$DEJAGNU_SIM_LDFLAGS" > } > else { > set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags]" > } No, "appendin

Re: SIM env. variable question in baseboards

> From: "Steve Ellcey " > Date: Thu, 24 May 2012 23:03:22 +0200 > I am trying to create a generic baseboard file in dejagnu for use in > testing GCC with a simulator. Most GCC targets already have baseboard files that fit the simulators (for newlib targets) that cohabit with gdb, but a generic b

Re: ping*2: [RFA:] testsuite infrastructure for options implied by dg-final methods

> From: Mike Stump > Date: Fri, 4 Nov 2011 17:53:05 +0100 > On Nov 4, 2011, at 6:47 AM, Hans-Peter Nilsson > wrote: > > Ping again, CC:ing testsuite maintainers. > > With the number of qualified individuals commenting in the > thread, I was going to stay out of it.

Re: ping*2: [RFA:] testsuite infrastructure for options implied by dg-final methods

> From: Mike Stump > Date: Fri, 4 Nov 2011 18:54:22 +0100 > On Nov 4, 2011, at 10:41 AM, Hans-Peter Nilsson wrote: > > I'll wait a few days. > > No need to wait. :-) If someone finds a way and is > motivated, they will fix this and the other instances. :-

sh64-sim.exp?

I have this sh64-sim.exp baseboard to go with the src/sim/sh64 simulator in the official (sourceware gdb CVS) repository. I know this was in the sourceware dejagnu repository. A STFW returns the src-cvs commit messages but the links don't work; use

Testing on HEAD, summary

Executive summary: native, sim and board tests say it's fine; at least no worse than dejagnu-1.4.4; somewhat better. Ship it! ;) A "git show" says the my latest update is, and verified with to be the official latest commit (h

Re: honoring gcc test stack size

> Date: Wed, 13 Feb 2008 14:20:38 -0600 > From: Joel Sherrill <[EMAIL PROTECTED]> > Hans-Peter Nilsson wrote: > > but > > if so, it seems simplest to fake a simulator as: > > set_board_info sim false > > > > > I'll try that next. In case i

Re: honoring gcc test stack size

> From: "Dave Korn" <[EMAIL PROTECTED]> > Date: Wed, 13 Feb 2008 17:50:42 - > On 13 February 2008 16:36, Hans-Peter Nilsson wrote: > As a datapoint, the standard per-thread stack allocation on win32 platforms > is 2MB. That might make a more reasonable

Re: honoring gcc test stack size

> Date: Wed, 13 Feb 2008 10:59:17 -0600 > From: Joel Sherrill <[EMAIL PROTECTED]> > OK. I will add it to the GCC Projects page. > Would this go into the Bug Patrol section of the > Beginner Projects section? By the name of it, it sounds like it. I'm not sure a non-executable setup would make mu

Re: honoring gcc test stack size

> Date: Wed, 13 Feb 2008 10:12:45 -0600 > From: Joel Sherrill <[EMAIL PROTECTED]> > Would it make sense in the future as a (beginner?) > GCC project to let me generate a set of GCC testresults > and let someone see which tests have issues honoring > the stack size. > > (Run 1) Run with a small 2-

Headsup: HEAD of dejagnu (correctly) less warnings, marks unresolved test-cases

In my gcc autotester, I check cris-elf using cris-sim (all sources are in gcc and src trees) on a Fedora 8 amd64. I'm also using amd64 Debian machines in the gcc build farm, but not for autotesting. That setup doesn't reveal that many differences (more later), because I mentioned, Debian tracks d

HEAD dejagnu fails for ld tests, ld-cris/warn3

I'm using my various autotester setups to check dejagnu HEAD for the upcoming (wishfully anyway) 1.5. I'm not used to git, but "git show" says the latest update is commit 94dbf2fc904ce3446aa513e41edac6a3edaf316d Author: Ben Elliston <[EMAIL PROTECTED]> Date: Mon Feb 11 21:48:59 2008 +1100 With

Re: honoring gcc test stack size

> Date: Tue, 12 Feb 2008 15:47:14 -0600 > From: Joel Sherrill <[EMAIL PROTECTED]> > I investigated one failure: pr20621-1.x3 You mean gcc/testsuite/gcc.c-torture/execute/pr20621-1.c at -O3? >From the looks of it, it would take about 2*0x4000*4 bytes stack. > and discovered that it is using a LOT

Re: Assistance Request

> From: "Dave Korn" <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 18:52:27 - > On 12 February 2008 18:19, Hans-Peter Nilsson wrote: Dave wrote: > >> # The simulator isn't really remote. > >> set_board_info isremote 0 > >&g

Re: Assistance Request

> From: "Dave Korn" <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 16:05:18 - > On 12 February 2008 15:48, Joel Sherrill wrote: > > I am getting arguments through now. I am on Fedora 8 > > and the DejaGNU RPM doesn't seem to support ~/.dejagnurc. No, it must be for some other reason. It does

Re: Assistance Request

> Date: Mon, 11 Feb 2008 11:26:41 -0600 > From: Joel Sherrill <[EMAIL PROTECTED]> > RTEMS applications do not return the exit status > to the environment. So it will have to print > pass/fail based on the exit value. I vaguely > remember this not being a big deal for DejaGNU. As Dave mentioned,

patch: fix s/case/switch/ oops in cris-sim.exp and h8300.exp

my original cris-sim.exp). GCC tests are still in progress. I didn't scrutinize any of the other s/case/switch/ changes. 2008-02-11 Hans-Peter Nilsson <[EMAIL PROTECTED]> * baseboards/h8300.exp: Use -- before switch argument that may begin with "-".

patch: Makefile.am baseboard_SCRIPTS missing files

Testing HEAD using the gcc testsuite for cris-elf *without* my local cris-sim.exp revealed an inconsistency in baseboard_SCRIPTS; cris-sim.exp and at least two other files aren't installed. To fix it, I searched for an automake feature corresponding to GNU make $(wildcard baseboards/*.exp) but not

dos2unix baseboards/cris-sim.exp

I checked out dejagnu, hoping to get time to test for the new release, with various setups testing gcc/binutils/sim. I see for some reason, baseboards/cris-sim.exp has "DOS format"; carriage returns before line-feeds. I'm not sure how that happened. I see I passed it as an attachment probably us

Episode 1.4.4: A New Release

I didn't find any plans or notes about a newer release than dejagnu-1.4.4 in the archives. So, can I please have one? ;) It would have saved me from scratching my head about a strange difference in test-results between gcc testruns targeting a simulator on Debian etch system compared to a Fedora

Ping*2: baseboards/cris-sim.exp

I sent this reminder a week ago, but I don't see the message in the ml archives. Anyway, it still seems true. (Browsing http://savannah.gnu.org/cgi-bin/viewcvs/dejagnu/dejagnu/> I don't see any CVS activity at all in the last three months; perhaps the CVS has moved?) I did not get a comment on i

Ping: baseboards/cris-sim.exp

I did not get a comment on it, nor do I see it in CVS. Time for a ping. http://lists.gnu.org/archive/html/dejagnu/2005-01/msg9.html>. Thanks. brgds, H-P ___ DejaGnu mailing list DejaGnu@gnu.org http://lists.gnu.org/mailman/listinfo/dejagnu