Am 01.12.24 um 19:15 schrieb Dimitar Dimitrov:
On Sun, Dec 01, 2024 at 12:32:55PM +0100, Georg-Johann Lay wrote:
Am 01.12.24 um 05:45 schrieb Maciej W. Rozycki:
On Sat, 30 Nov 2024, Georg-Johann Lay wrote:
The gcc.c-torture/execute/memcpy-a[1248].c tests consumed more time
than the whole rest of the test suite, just to come up with
a "memory full" even at -Os. Skipped thusly.
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.
Compilation takes much host time for other targets too.
Ja, but with the difference that test ARE being conducted.
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.
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).
Johann
Regards
Dimitar
