On Sun, 1 Dec 2024, Georg-Johann Lay wrote:
> > > > As a matter of interest, is the timeout/memory exhaustion observed with
> > > > host compilation or target execution?
> > > It happens during link, when the linker observes that the memory regions
> > > won't fit:
> > >
> > > .../avr/bin/ld: memcpy-a8.elf section `.text' will not fit in region
> > > `text'
> > > .../avr/bin/ld: address 0x82c174 of memcpy-a8.elf section `.data' is not
> > > within region `data'
> > > .../avr/bin/ld: address 0x82c17c of memcpy-a8.elf section `.bss' is not
> > > within region `data'
> > > .../avr/bin/ld: region `text' overflowed by 245074 bytes
> > > collect2: error: ld returned 1 exit status
> >
> > The memory overflow should be caught by ${tool}_check_unsupported_p.
> > Even without this patch, the testsuite should mark the tests as
> > UNSUPPORTED and not FAIL for avr.
>
> They ARE being reported as UNSUPPORTED. But it takes ~40m to arrive at
> these conclusions for all 5 tests. A whole testsuite run takes
> 60m...70m, so adding 40m for a single test just to see one UNSUPPORTED
> rushing by each minute is no fun. It's known in advance that these
> tests are pointless on AVR.
I agree it can be annoying under these circumstances.
> > On native x86_64-pc-linux-gnu:
> > $ time make check-gcc-c RUNTESTFLAGS="execute.exp=memcpy-a*.c"
> > # of expected passes 56
> >
> > real 8m37,778s
> > user 8m29,895s
> > sys 0m5,805s
> >
> > Should these tests instead be gated by "run_expensive_tests"?
>
> "in addition" instead of "instead" would be fine for me.
I've posted a change to this effect now.
> Though I don't know anything about when a test on a current hardware is
> deemed "expensive". For AVR, they are pointless *and* are consuming
> an offensive amount of time (otherwise I wouldn't care; there are many
> other tests that are beyond the memory constraints of AVRs).
I think it's subjective:
'run_expensive_tests'
Expensive testcases (usually those that consume excessive amounts
of CPU time) should be run on this target. This can be enabled by
setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a
non-empty string.
-- I think what constitutes "excessive amounts of CPU time" will vary
depending on the environment, but I guess the need to set the timeout
factor is a good indication. I wasn't aware of this effective-target
setting at the time I proposed the tests or I would have used it along
with the original submission.
Maciej
