Re: More variants of C/C++ test cases for 'constructor', 'destructor' function attributes with priority
On Jun 4, 2024, at 11:30 AM, Thomas Schwinge wrote: > > For my recent work on > "nvptx target: Global constructor, destructor support, via nvptx-tools 'ld'", > I needed more variants of C/C++ test cases for 'constructor', > 'destructor' function attributes with priority: in particular, split into > separate translation units, in combination with internal linkage > variants. Out of that fell the following four patches. OK to push? Ok. Watch out for help requests from hp, rs6000, solaris and darwin. I'll presume this won't break on linux. If you haven't had it tested on something else beyond your target, would be nice to have someone else chime in before it goes in. If there are holes in other targets completeness, I'll pre-approve the knock outs to turn off portions of the tests that run.
Re: [PATCH] [testsuite] conditionalize dg-additional-sources on target and type
On May 23, 2024, at 6:28 AM, Alexandre Oliva wrote; > I came up with an entirely different approach: > > > g++.dg/vect/pr95401.cc has dg-additional-sources, and that fails when > check_vect_support_and_set_flags finds vector support lacking for > execution tests: tests decay to compile tests, and additional sources > are rejected by the compiler when compiling to a named output file. > > At first I considered using some effective target to conditionalize > the additional sources. There was no support for target-specific > additional sources, so I added that. > > But then, I found that adding an effective target to check whether the > test involves linking would just make for busy work in this case, and > so I went ahead and adjusted the handling of additional sources to > refrain from adding them on compile tests, reporting them as > unsupported. > > That solves the problem without using the newly-added machinery for > per-target additional sources, but I figured since I'd implemented it > I might as well contribute it, since there might be other uses for it. > > Regstrapped on x86_64-linux-gnu. Also tested on ppc64-vx7r2 with > gcc-13. Ok to install? Ok.
Re: [PATCH] vax: resolve long-standing documentation bugs re floating-point codegen [PR79646]
On Apr 26, 2024, at 11:17 AM, Abe Skolnik wrote: You never need to do any work in .po files, omit that part and repost.
Re: [PATCH v2] [testsuite] require sqrt_insn effective target where needed
On Apr 22, 2024, at 2:56 AM, Alexandre Oliva wrote: > > This patch takes feedback received for 3 earlier patches, and adopts a > simpler approach to skip the still-failing tests, that I believe to be > in line with ppc maintainers' expressed preferences. > https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565939.html > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566617.html > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566521.html > Ping?-ish :-) > > > Some tests fail on ppc and ppc64 when testing a compiler [with options > for] for a CPU [emulator] that doesn't support the sqrt insn. > > The gcc.dg/cdce3.c is one in which the expected shrink-wrap > optimization only takes place when the target CPU supports a sqrt > insn. > > The gcc.target/powerpc/pr46728-1[0-4].c tests use -mpowerpc-gpopt and > call sqrt(), which involves the sqrt insn that the target CPU under > test may not support. > > Require a sqrt_insn effective target for all the affected tests. > > Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also testing > with gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install? Ok.
Re: [PATCH] [testsuite] introduce strndup effective target
On Apr 18, 2024, at 4:32 AM, Alexandre Oliva wrote: > > On Apr 16, 2024, Alexandre Oliva wrote: > >> * gcc.dg/builtin-dynamic-object-size-1.c: Likewise. >> * gcc.dg/builtin-dynamic-object-size-2.c: Likewise. >> * gcc.dg/builtin-dynamic-object-size-3.c: Likewise. >> * gcc.dg/builtin-dynamic-object-size-4.c: Likewise. > > These hunks were missing from the patch I posted No worries, thanks for all the hard work.
Re: [PATCH] [testsuite] [arm] accept empty init for bfloat16
On Apr 15, 2024, at 8:50 PM, Alexandre Oliva wrote:
>
> Complete r13-2205, adjusting an arm-specific test that expects a
> no-longer-issued error at an empty initializer.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
I did see Richard's comment. First order is the current language should work.
If people who put in the changing language want a test case for the old
language, it is reasonable to expect them to do that work. Indeed, I kinda
expect coverage already for that feature in another test case.
Ok.
> for gcc/testsuite/ChangeLog
>
> * gcc.target/arm/bfloat16_scalar_typecheck.c: Accept C23
>empty initializers.
> ---
> .../gcc.target/arm/bfloat16_scalar_typecheck.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> index 8c80c55bc9f4c..04ede93bda152 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> @@ -42,7 +42,7 @@ bfloat16_t footest (bfloat16_t scalar0)
> short initi_1_4 = glob_bfloat; /* { dg-error {invalid conversion from type
> 'bfloat16_t'} } */
> double initi_1_5 = glob_bfloat; /* { dg-error {invalid conversion from type
> 'bfloat16_t'} } */
>
> - bfloat16_t scalar2_1 = {}; /* { dg-error {empty scalar initializer} } */
> + bfloat16_t scalar2_1 = {};
> bfloat16_t scalar2_2 = { glob_bfloat };
> bfloat16_t scalar2_3 = { 0 }; /* { dg-error {invalid conversion to type
> 'bfloat16_t'} } */
> bfloat16_t scalar2_4 = { 0.1 }; /* { dg-error {invalid conversion to type
> 'bfloat16_t'} } */
> @@ -94,7 +94,7 @@ bfloat16_t footest (bfloat16_t scalar0)
>
> /* Compound literals. */
>
> - (bfloat16_t) {}; /* { dg-error {empty scalar initializer} } */
> + (bfloat16_t) {};
> (bfloat16_t) { glob_bfloat };
> (bfloat16_t) { 0 }; /* { dg-error {invalid conversion to type 'bfloat16_t'}
> } */
> (bfloat16_t) { 0.1 }; /* { dg-error {invalid conversion to type
> 'bfloat16_t'} } */
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
> Free Software Activist GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] [c++] [testsuite] adjust contracts9.C for negative addresses
On Apr 15, 2024, at 8:20 PM, Alexandre Oliva wrote: > > The test expected the address of a literal string, converted to long > long, to yield a positive value. That expectation doesn't necessarily > hold, and the test fails where it doesn't. > > Adjust the test to use a pointer that will compare as expected. > > Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-, > aarch64-, x86- and x86_64-vxworks7r2. Ok to install? Ok.
Re: [PATCH] testsuite: Define _POSIX_C_SOURCE for test
On Mar 10, 2024, at 10:26 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk?
Ok.
> As the tests assume that strndup() is visible (only part of
> POSIX.1-2008) define the guard to ensure that it's visible. Currently,
> glibc appears to always have this defined in C++, newlib does not.
>
> Without this patch, fails like this can be seen:
>
> Testing analyzer/strndup-1.c, -std=c++98
> .../strndup-1.c: In function 'void test_1(const char*)':
> .../strndup-1.c:11:13: error: 'strndup' was not declared in this scope; did
> you mean 'strncmp'?
> .../strndup-1.c: In function 'void test_2(const char*)':
> .../strndup-1.c:16:13: error: 'strndup' was not declared in this scope; did
> you mean 'strncmp'?
> .../strndup-1.c: In function 'void test_3(const char*)':
> .../strndup-1.c:21:13: error: 'strndup' was not declared in this scope; did
> you mean 'strncmp'?
>
> Patch has been verified on Linux.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/analyzer/strndup-1.c: Define _POSIX_C_SOURCE.
>
> Signed-off-by: Torbjörn SVENSSON
> ---
> gcc/testsuite/c-c++-common/analyzer/strndup-1.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> b/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> index 85ccae85d83..577ece0cfba 100644
> --- a/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> +++ b/gcc/testsuite/c-c++-common/analyzer/strndup-1.c
> @@ -1,4 +1,5 @@
> /* { dg-skip-if "no strndup in libc" { *-*-darwin[789]* *-*-darwin10*
> hppa*-*-hpux* *-*-mingw* *-*-vxworks* } } */
> +/* { dg-additional-options "-D_POSIX_C_SOURCE=200809L" } */
>
> #include
> #include
Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64
On Feb 15, 2024, at 6:08 AM, Jonathan Yong <10wa...@gmail.com> wrote:
>
> Attached patch OK?
Ok.
> Copy/pasted for review convenience.
>
> diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c
> b/gcc/testsuite/c-c++-common/Wrestrict.c
> index 4d005a618b3..57a3f67e21e 100644
> --- a/gcc/testsuite/c-c++-common/Wrestrict.c
> +++ b/gcc/testsuite/c-c++-common/Wrestrict.c
> @@ -381,14 +381,14 @@ void test_memcpy_range_exceed (char *d, const char *s)
> T (d + i, s + 1, 3); /* { dg-warning "accessing 3 bytes at offsets
> \\\[\[0-9\]+, \[0-9\]+] and 1 overlaps 1 byte" "memcpy" } */
> #if __SIZEOF_SIZE_T__ == 8
> - /* Verfiy the offset and size computation is correct. The overlap
> - offset mentioned in the warning plus sthe size of the access must
> + /* Verify the offset and size computation is correct. The overlap
> + offset mentioned in the warning plus the size of the access must
> not exceed DIFF_MAX. */
> - T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target lp64 } } */
> - T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target lp64 } } */
> + T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> + T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> - T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target lp64 } } */
> - T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target lp64 } } */
> + T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset
> 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> + T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at
> offset 9223372036854775802" "LP64" { target { lp64 || llp64 } } } */
> #elif __SIZEOF_SIZE_T__ == 4
> T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
> \\\[2147483645, 2147483647] overlaps 3 bytes at offset 2147483642" "ILP32" {
> target ilp32 } } */
> T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets
> \\\[2147483645, 2147483647] and 0 overlaps 3 bytes at offset 2147483642"
> "ILP32" { target ilp32 } }
> */<0001-c-c-common-Wrestrict.c-fix-some-typos-and-enable-for.patch>
Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization
On Feb 26, 2024, at 7:56 AM, Alejandro Colomar wrote: > > I don't see an obvious order in that file. Where would you put the > option? The best place, would be to put it just after: -Warray-bounds -Warray-bounds=n This is a functional style grouping that best mirrors the existing ordering. A runner up would be next to the string options or near a "terminating NUL", but after review, these don't seem more suitable. > Do you want me to sort(1) it first, and then insert the new > option in alphabetic order? No. Let others play at that.
Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization
On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote:
>
> Warn about the following:
>
>char s[3] = "foo";
No ObjC specific impact here, so no need for ObjC review.
As a member of the peanut gallery, I like the patch.
Joseph, this is been submitted 5 times over the past year. Any thoughts?
> Initializing a char array with a string literal of the same length as
> the size of the array is usually a mistake. Rarely is the case where
> one wants to create a non-terminated character sequence from a string
> literal.
>
> In some cases, for writing faster code, one may want to use arrays
> instead of pointers, since that removes the need for storing an array of
> pointers apart from the strings themselves.
>
>char *log_levels[] = { "info", "warning", "err" };
> vs.
>char log_levels[][7] = { "info", "warning", "err" };
>
> This forces the programmer to specify a size, which might change if a
> new entry is later added. Having no way to enforce null termination is
> very dangerous, however, so it is useful to have a warning for this, so
> that the compiler can make sure that the programmer didn't make any
> mistakes. This warning catches the bug above, so that the programmer
> will be able to fix it and write:
>
>char log_levels[][8] = { "info", "warning", "err" };
>
> This warning already existed as part of -Wc++-compat, but this patch
> allows enabling it separately. It is also included in -Wextra, since
> it may not always be desired (when unterminated character sequences are
> wanted), but it's likely to be desired in most cases.
>
> Since Wc++-compat now includes this warning, the test has to be modified
> to expect the text of the new warning too, in .
>
> Link:
> Link:
> Link:
>
Re: [PATCH] testsuite: Fix up lra effective target
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote: > > There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION > target. I think claiming for it that it is a lra target is strange (even > though it effectively returns true for targetm.lra_p ()), unsure if it > supports asm goto with outputs or not, if it does and we want to test it, > perhaps we should introduce asm_goto_outputs effective target and use > lra || nvptx-*-* for that? Since the port people have to maintain that code in general, I usually leave it to them to try and select a cheap, maintainable way to manage it. If people want to pave the way, I'd tend to defer to them, having thought about more than I.
Re: [PATCH] testsuite: Fix up lra effective target
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>
> Given the recent discussions on IRC started with Andrew P. mentioning that
> an asm goto outputs test should have { target lra } and the lra effective
> target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
> we clearly have 14 other targets which don't support LRA and a couple of
> further ones which have an -mlra/-mno-lra switch (whatever default they
> have), seems to me the effective target is quite broken.
>
> Ok for trunk?
Ok.
Re: [PATCH] testsuite: Add support for scanning assembly with comparitor
On Feb 12, 2024, at 11:38 AM, Edwin Lu wrote:
>
> There is currently no support for matching at least x lines of assembly
> (only scan-assembler-times). This patch would allow setting upper or lower
> bounds.
>
> Use case: using different scheduler descriptions and/or cost models will
> change
> assembler output. Testing common functionality across tunes would require a
> separate testcase per tune since each assembly output would be different. If
> we
> know a base number of lines should appear across all tunes (i.e. testing
> return
> values: we expect at minimum n stores into register x), we can lower-bound the
> test to search for scan-assembler-bound {RE for storing into register x} >= n.
> This avoids artificially inflating the scan-assembler-times expected count due
> to the assembler choosing to perform extra stores into register x (using it as
> a temporary register).
>
> The testcase would be more robust to cpu/tune changes at the cost of not being
> as granular towards specific cpu tuning.
I didn't see an Ok? Just in case you forgot, yes, this is ok.
Re: [PATCH] testsuite: Define _POSIX_SOURCE for tests [PR113278]
On Feb 15, 2024, at 9:03 AM, Torbjörn SVENSSON wrote: > > Ok for trunk? Ok. > gcc/testsuite/ChangeLog: > PR113278 > * c-c++-common/analyzer/fileno-1.c: Define _POSIX_SOURCE. > * c-c++-common/analyzer/flex-with-call-summaries.c: Same. > * c-c++-common/analyzer/flex-without-call-summaries.c: Same.
Re: Unreviewed c++ and libgomp testsuite patches
> On Feb 12, 2024, at 5:27 AM, Rainer Orth > wrote: > > The following patches have remained unreviewed for a week or more: > > testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706] >https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644842.html Jason commented. > Probably needs a C++ maintainer, although I've Cc'ed the testcase author > for good measure. > > libgomp: testsuite: Don't XPASS libgomp.c/alloc-pinned-1.c etc. on > non-Linux targets [PR113448] > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644967.html I'm fine with this as well. Ok.
Re: [PATCH] i386, testsuite: adjust asm patterns
On Feb 10, 2024, at 10:07 AM, FX Coudert wrote: > > The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is > partly because symbols are prefixed with underscore, and also because the > order of operands in the addition is reversed (but I think it’s valid still). > The code generated is this: > > _func: > LFB0: >pushq %rbp > LCFI0: >movq%rsp, %rbp > LCFI1: > # 8 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 1 >@ _func > # 0 "" 2 > # 9 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 1 >@ 4+_var > # 0 "" 2 >nop >popq%rbp > LCFI2: >ret > > > > I’m adjusting the pattern accordingly. > OK to push? Ok.
Re: [PATCH] testsuite: Update test case to comply with GCC14 changes
On Feb 10, 2024, at 7:21 AM, Torbjörn SVENSSON wrote: > > I have confirmed that this updated pr97969.c file still hangs with > gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969. > > Ok for trunk? Ok.
Re: [PATCH v2] testsuite: Pattern does not match when using --specs=nano.specs
On Feb 8, 2024, at 9:44 AM, Torbjörn SVENSSON wrote: > > Changes since v1: > - Replaced .* with [^\r\n]* to avoid matching newline. > > Ok for trunk and releases/gcc-13? Ok.
Re: [PATCH] testsuite: Pattern does not match when using --specs=nano.specs
On Feb 6, 2024, at 8:58 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk and releases/gcc-13?
Ok. If .* goes across newlines, you might want to not use ..
> -if {![regexp -- "/${compiler}(\\.exe)? -quiet.*$compiler_pattern"
> $gcc_output]} {
> +if {![regexp -- "/${compiler}(\\.exe)? .*-quiet.*$compiler_pattern"
> $gcc_output]} {
Re: [PATCH] testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-bit Solaris/x86
On Jan 24, 2024, at 1:01 AM, Rainer Orth wrote: > > gcc.target/i386/pr70321.c FAILs on 32-bit Solaris/x86 since its > introduction in > > commit 43201f2c2173894bf7c423cad6da1c21567e06c0 > Author: Roger Sayle > Date: Mon May 30 21:20:09 2022 +0100 > >PR target/70321: Split double word equality/inequality after STV on x86. > > FAIL: gcc.target/i386/pr70321.c scan-assembler-times mov 1 > > The failure happens because 32-bit Solaris/x86 defaults to > -fno-omit-frame-pointer. > > Fixed by specifying -fomit-frame-pointer explicitly. > > Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. > > Ok for trunk? Ok.
Re: [PATCH] testsuite: i386: Fix gcc.target/i386/avx512vl-stv-rotatedi-1.c on 32-bit Solaris/x86
On Jan 24, 2024, at 1:12 AM, Rainer Orth wrote: > > gcc.target/i386/avx512vl-stv-rotatedi-1.c FAILs on 32-bit Solaris/x86 > since its introduction in > > commit 4814b63c3c2326cb5d7baa63882da60ac011bd97 > Author: Roger Sayle > Date: Mon Jul 10 09:04:29 2023 +0100 > >i386: Add AVX512 support for STV of SI/DImode rotation by constant. > > FAIL: gcc.target/i386/avx512vl-stv-rotatedi-1.c scan-assembler-times > vpro[lr]q 29 > > While the test depends on -mstv, 32-bit Solaris/x86 defaults to > -mstackrealign which is incompatible. > > The patch thus specifies -mstv -mno-stackrealign explicitly. > > Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. > > Ok for trunk? Ok.
Re: [PATCH] testsuite, asan, hwsan: Add libstdc++ deps where required.
On Jan 30, 2024, at 2:30 AM, Iain Sandoe wrote: > > tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux, > OK for trunk? Ok. If asan people want to chime in...
Re: [PATCH] testsuite, ubsan: Add libstdc++ deps where required.
On Jan 30, 2024, at 2:31 AM, Iain Sandoe wrote: > > tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux, > OK for trunk? Ok. If the ubsan people want to review this, certainly, happy to have them chime in.
Re: [PATCH] testsuite, Objective-C++: Update link flags [PR112863].
On Jan 28, 2024, at 7:03 AM, Iain Sandoe wrote: > > Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, > OK for trunk? Ok. If you discover needed updates, please feel free to drop them in.
Re: Ping [PATCH] testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators
On Jan 12, 2024, at 2:52 AM, Hans-Peter Nilsson wrote: > > Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.) > > On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote: > >> Tested mmix-knuth-mmixware (where all torture-variants of >> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native >> x86_64-pc-linux-gnu. Also stepped through the test for native, >> w/wo. RUN_FRACTION defined to see that it worked as intended. >> >> You may wonder what about the "sibling" tests inline-mem-cmp-1.c and >> inline-mem-cpy-cmp-1.c. Well, they FAIL, but not because of >> timeouts(!) To be continued >> >> Ok to commit? Ok.
Re: [PATCH] Allow overriding EXPECT
On Dec 21, 2023, at 8:49 AM, Christophe Lyon wrote: > > While investigating possible race conditions in the GCC testsuites > caused by bufferization issues, I wanted to investigate workarounds > similar to GDB's READ1 [1], and I noticed it was not always possible > to override EXPECT when running 'make check'. > > This patch adds the missing support in various Makefiles. Ok.
Re: [PATCH] Testsuite: restrict test to nonpic targets
On Dec 11, 2023, at 12:29 AM, FX Coudert wrote: > > The test is currently failing on x86_64-apple-darwin. This patch requires > nonpic, as suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 > by Andrew Pinski. > > OK to commit? Ok.
Re: [PATCH] testsuite: require avx_runtime for some tests
On Nov 6, 2023, at 2:59 AM, Marc Poulhiès wrote: > > These 3 tests fails parsing the 'vect' dump when not using -mavx. Make > the dependency explicit. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/vect-ifcvt-18.c: Add dep on avx_runtime. > * gcc.dg/vect/vect-simd-clone-16f.c: Likewise. > * gcc.dg/vect/vect-simd-clone-18f.c: Likewise. > --- > Tested on x86_64-linux and x86_64-elf. > > Ok for master? Ok.
Re: [PATCH] testsuite: refine gcc.dg/analyzer/fd-4.c test for newlib
On Nov 6, 2023, at 3:01 AM, Marc Poulhiès wrote:
>
> Contrary to glibc, including stdio.h from newlib defines mode_t which
> conflicts with the test's type definition.
>
> .../gcc/testsuite/gcc.dg/analyzer/fd-4.c:19:3: error: redefinition of typedef
> 'mode_t' with different type
> ...
> .../include/sys/types.h:189:25: note: previous declaration of 'mode_t' with
> type 'mode_t' {aka 'unsigned int'}
>
> Defining _MODE_T_DECLARED skips the type definition.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/analyzer/fd-4.c: Fix for newlib.
> ---
> Tested on x86_64-linux and x86_64-elf.
>
> Ok for master?
Ok,
Re: [PATCH] testsuite: skip gcc.target/i386/pr106910-1.c test when using newlib
On Nov 6, 2023, at 2:57 AM, Marc Poulhiès wrote:
>
> Using newlib produces a different codegen because the support for c99
> differs (see libc_has_function hook).
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr106910-1.c: Disable for newlib.
> ---
> Tested on x86_64-linux and x86_64-elf.
>
> OK for master?
Ok, but nix the first blank line?
> gcc/testsuite/gcc.target/i386/pr106910-1.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr106910-1.c
> b/gcc/testsuite/gcc.target/i386/pr106910-1.c
> index c7685a32183..00c93f444b6 100644
> --- a/gcc/testsuite/gcc.target/i386/pr106910-1.c
> +++ b/gcc/testsuite/gcc.target/i386/pr106910-1.c
> @@ -1,4 +1,6 @@
> +
This one.
> /* { dg-do compile { target { ! ia32 } } } */
> +/* { dg-skip-if "newlib libc math causes different codegen" { newlib } } */
> /* { dg-options "-msse4.1 -O2 -Ofast" } */
> /* { dg-final { scan-assembler-times "roundps" 9 } } */
> /* { dg-final { scan-assembler-times "cvtps2dq" 1 } } */
Re: [PATCH] testsuite/gcc.dg/uninit-pred-9_b.c:20: Fix XPASS for various targets
On Nov 24, 2023, at 7:15 PM, Hans-Peter Nilsson wrote:
>
> While looking at the various targets, I found that the m32r
> target has two options implemented as opposites:
> -mbranch-cost=1 and -mbranch-cost=2, that have a bug that
> makes them yield their functionally opposite effect;
> i.e. -mbranch-cost=$arg, arg={1, 2} yields BRANCH_COST(x, y)
> 3-$arg. Anyway, the default is 1, unknown if that's
> deliberate. (I won't add a PR, just CC:ing the maintainer.)
>
> Tested for
> XPASSing targets: m32r-elf and cris-elf
> XFAILing targets: loongarch64-unknown-linux-gnuf64 and ia64-linux.
>
> Ok to commit?
Ok.
> * gcc.dg/uninit-pred-9_b.c: Remove xfail for line 20. Pass
> --param=logical-op-non-short-circuit=0. Comment why.
Re: [PATCH #4/4] testsuite: discard c++ exclusion on underaligned pointer warning
On Nov 19, 2023, at 6:34 PM, Alexandre Oliva wrote: > > Having extended check_and_warn_address_or_pointer_of_packed_member to > find the packed (short) enum pointer in the cast expression coming > from the C++ front-end, and amended the C++ front end to mark short > enums as TYPE_PACKED, C++ issues the same warning that C does for > c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c, > so drop the exclusion. > > Regstrapped on x86_64-linux-gnu, also tested on arm-eabi with default > cpu on trunk, and with tms570 on gcc-13. Ok to install? Ok.
Re: [PATCH] testsuite: tsan: add fallback overload for pthread_cond_clockwait
On Nov 8, 2023, at 5:49 PM, Alexandre Oliva wrote: > > LTS GNU/Linux distros from 2018, still in use, don't have > pthread_cond_clockwait. There's no trivial way to detect it so as to > make the test conditional, but there's an easy enough way to silence > the fail due to lack of the function in libc, and that has nothing to > do with the false positive that this is testing against. > > Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on i686- and > x86_64-, on distros that offer and that lack pthread_cond_clockwait. Ok > to install? Ok.
Re: testsuite: introduce hostedlib effective target
On Nov 8, 2023, at 8:29 AM, Alexandre Oliva wrote: > > On Nov 5, 2023, Mike Stump wrote: > >> that, otherwise, I'll approve this version. > > FWIW, this version is not usable as is. Something went wrong in my > testing, and several regressions only visible in hosted mode made to the > version I posted, that adds some missing end-of-comment markers for the > added dg directives, and moving the new dg directive to the end so as to > not disturb line numbers. I've got a fully fixed and properly tested > version, but since it's about as big as the original patch, I'll only > post it upon request. Updates and fixes to the original plan are fine. I'm still planning on letting you decide based upon input from everyone. :-)
Re: [PATCH] testsuite: arg-pushing reqs -mno-accumulate-outgoing-args
On Nov 8, 2023, at 7:55 AM, Alexandre Oliva wrote: > > gcc.target/i386/pr95126-m32-[34].c expect push instructions that are > only present with -mno-accumulate-outgoing-args, so make that option > explicit rather than dependent on tuning. > > Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on i686- and > x86_64-. Ok to install? Ok.
Re: [PATCH] Testsuite, i386: Mark test as requiring dfp
On Nov 5, 2023, at 12:33 PM, FX Coudert wrote: > > kind ping for this easy patch > > >> Le 30 oct. 2023 à 15:19, FX Coudert a écrit : >> >> Hi, >> >> The test is currently failing on x86_64-apple-darwin with "decimal >> floating-point not supported for this target”. >> Marking the test as requiring dfp fixes the issue. >> >> OK to push? Ok.
Re: [PATCH] testsuite: check for and use -mno-strict-align where needed
On Oct 19, 2023, at 8:16 PM, Alexandre Oliva wrote: > > On Mar 10, 2021, Alexandre Oliva wrote: > >> ppc configurations that have -mstrict-align enabled by default fail >> gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into >> MEM_REFs, which defeats the tested-for strlen optimization. > > I've combined this patch with other patches that added -mno-strict-align > to tests that needed it on targets configured with -mstrict-align > enabled by default, and conditioned the use of the flag to targets that > support it. > > Regstrapped on x86_64-linux-gnu, ppc64le-linux-gnu, also tested on a > ppc-vx7r2 configured with -mstrict-align. Ok to install? Ok.
Re: [PATCH 1/2] testsuite: Add and use thread_fence effective-target
On Oct 2, 2023, at 1:24 AM, Christophe Lyon wrote: > > ping? > > On Sun, 10 Sept 2023 at 21:31, Christophe Lyon > wrote: > Some targets like arm-eabi with newlib and default settings rely on > __sync_synchronize() to ensure synchronization. Newlib does not > implement it by default, to make users aware they have to take special > care. > > This makes a few tests fail to link. > > This patch adds a new thread_fence effective target (similar to the > corresponding one in libstdc++ testsuite), and uses it in the tests > that need it, making them UNSUPPORTED instead of FAIL and UNRESOLVED. > > 2023-09-10 Christophe Lyon > > gcc/ > * doc/sourcebuild.texi (Other attributes): Document thread_fence > effective-target. > > gcc/testsuite/ > * g++.dg/init/array54.C: Require thread_fence. > * gcc.dg/c2x-nullptr-1.c: Likewise. > * gcc.dg/pr103721-2.c: Likewise. > * lib/target-supports.exp (check_effective_target_thread_fence): > New. Ok.
Re: testsuite: introduce hostedlib effective target
On Nov 1, 2023, at 6:11 PM, Alexandre Oliva wrote: > > Several C++ tests fail with --disable-hosted-libstdcxx, whether > because stdc++ext gets linked in despite not being built, because > standard headers are included but that are unavailable in this mode, > or because headers are (mistakenly?) expected to introduce > declarations such as for ::abort, but in this mode they don't. > > This patch introduces an effective target for GCC test, equivalent to > one that's available in the libstdc++-v3 testsuite, and arranges for > all such tests to be skipped when libstdc++-v3 is not hosted. > > This patch was tested with arm-eabi, with libstdc++-v3 configured with > --disable-hosted-libstdcxx, on gcc-13, and with x86_64-linux-gnu > likewise on trunk. In the latter, there are a number of additional > fails that appear to be related, and that I'm yet to investigate, but > this is big enough already, so I figured I'd post this and see whether > the approach is regarded as sound and acceptable before proceeding any > further. WDYT? Ok to install, to deal with other targets > incrementally? Ick. I wish there were fewer changed lines and not 1 per test case. It feels like we've painted ourselves into a corner. That said, I'd rather have a nice solid game plan that is better and suggest it over this approach but, the best I can think of it something that can notice after the fact during an error, and during error processing, trim or expect, which is awfully vague. So, instead of commenting more, I'd ask if anyone has a nice, good concrete idea and say I want to withdraw from the vague. If someone comes up with something you think is better, easy, smaller and or other goodness and you want to go that direction, I'd encourage that, otherwise, I'll approve this version.
Re: [PATCH] testsuite: Force use of -c when precompiling headers
On Oct 27, 2023, at 8:11 AM, Christophe Lyon wrote: > > In some configurations of our validation setup, we always call the > compiler with -Wl,-rpath=XXX, which instructs the driver to invoke the > linker if none of -c, -S or -E is used. > > This happens to be the case in the PCH tests, where dg-flags-pch sets > dg-do-what-default to precompile. > > This works most of the time, in absence of any linker option, the > compiler defaults to generating a precompiled header (otherwise the > linker complains because it cannot find 'main'). > > This small patch forces the use of '-c' when generating the .gch file, > which is sufficient not to invoke the linker. > > Arguably, this could be seen as a dejagnu bug: in gcc-dg-test-1 (in > gcc-dg.exp), we set compile_type to "precompiled_header", which is not > one of the supported values in dejagnu's default_target_compile (in > target.exp). > > 2023-10-27 Christophe Lyon > > gcc/testsuite/ > * lib/dg-pch.exp (dg-flags-pch): Add -c when generating the > precompiled header. Ok.
Re: [PATCH] testsuite: Allow general skips/requires in PCH tests
On Oct 26, 2023, at 5:34 AM, Richard Sandiford wrote: > dg-pch.exp handled dg-require-effective-target pch_supported_debug > as a special case, by grepping the source code. This patch tries > to generalise it to other dg-require-effective-targets, and to > dg-skip-if. > > There also seemed to be some errors in check-flags. It used: > >lappend $args [list ] > > which treats the contents of args as a variable name. I think > it was supposed to be "lappend args" instead. From the later > code, the element was supposed to be itself, rather than > a singleton list containing . > > We can also save some time by doing the common early-exit first. > > Doing this removes the need to specify the dg-require-effective-target > in both files. Tested by faking unsupported debug and checking that > the tests were still correctly skipped. > > Tested on aarch64-linux-gnu. OK to install? Ok.
Re: [testsuite] note pitfall in how outputs.exp sets gld
On Jun 22, 2023, at 10:35 PM, Alexandre Oliva wrote: > > This patch documents a glitch in gcc.misc-tests/outputs.exp: it checks > whether the linker is GNU ld, and uses that to decide whether to > expect collect2 to create .ld1_args files under -save-temps, but > collect2 bases that decision on whether HAVE_GNU_LD is set, which may > be false zero if the linker in use is GNU ld. Configuring > --with-gnu-ld fixes this misalignment. Without that, atsave tests are > likely to fail, because without HAVE_GNU_LD, collect2 won't use @file > syntax to run the linker (so it won't create .ld1_args files). > > Long version: HAVE_GNU_LD is set when (i) DEFAULT_LINKER is set during > configure, pointing at GNU ld; (ii) --with-gnu-ld is passed to > configure; or (iii) config.gcc sets gnu_ld=yes. If a port doesn't set > gnu_ld, and the toolchain isn't configured so as to assume GNU ld, > configure and thus collect2 conservatively assume the linker doesn't > support @file arguments. > > But outputs.exp can't see how configure set HAVE_GNU_LD (it may be > used to test an installed compiler), and upon finding that the linker > used by the compiler is GNU ld, it will expect collect2 to use @file > arguments when running the linker. If that assumption doesn't hold, > atsave tests will fail. > > Does it make sense to put this in? I'd like to preserve this knowledge > somehow, and I suppose this would be most useful for someone observing > these failures and trying to figure out why they come about, so this > seems the best place for them. Ok to install? Ok.
Re: PING^2: Re: [PATCH 1/3] testsuite: move handle-multiline-outputs to before check for blank lines
On Jun 20, 2023, at 10:21 AM, David Malcolm wrote: > Does this testsuite patch look OK? > > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620275.html > > Thanks > David > > On Mon, 2023-06-12 at 19:11 -0400, David Malcolm wrote: >> Please can someone review this testsuite patch: >> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620275.html >> >> Thanks >> Dave >> >> On Wed, 2023-05-31 at 14:06 -0400, David Malcolm wrote: >>> I have followup patches that require checking for multiline >>> patterns >>> that have blank lines within them, so this moves the handling of >>> multiline patterns before the check for blank lines, allowing for >>> such >>> multiline patterns. >>> >>> Doing so uncovers some issues with existing multiline directives, >>> which >>> the patch fixes. Ok.
Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)
On Jun 12, 2023, at 1:35 AM, Bernhard Reutner-Fischer wrote: > > On Sat, 10 Jun 2023 11:29:36 -0700 > Mike Stump wrote: > >> On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer >> wrote: > >>>But well. Either way, what >>> should we do about remote env, if there is one? If the target >>> supports it, send it and skip otherwise? > >> So, to focus a >> conversation, which target, which host, canadian? Which part of the >> environment? What part is missing you want to fix? Want to unify >> between targets... and so on. >> > > The most recent target where this came up again was GCN i think. > See the last block in > https://inbox.sourceware.org/gcc-patches/20230508195217.4897009f@nbbrfq/ > and Thomas' reference therein to Tobias' > https://inbox.sourceware.org/gcc-patches/018bcdeb-b3bb-1859-cd0b-a8a92e26d...@codesourcery.com/ > > thoughts? I kinds like the remote_setenv approach, but the low level details when one gets in there and wires up all they need to make it work are important. If someone wants to tilt at the problem, I'm inclined to let them find the incantation they like and approve it. I'd rather approve a patch that takes us a step closer to perfection then go another 10 years. For quoting. I like quite using ' if there is no ' in the string. For each ' in the string, replace it with '\'', inelegant, but easier to reason about and don't have to worry about as many meta characters if you try and go the "" route. This assumes something like sh is taking in commands. This isn't always the case. One can canadian into a windows box or some other weird thing so the mechanism used has to be next to the thing that knows what it is talking to. Just because someone contributes code for talking to sh, doesn't mean they have to bother with windows or other weird stuff. The next person to come along can tilt at that.
Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)
On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer wrote: > > On 9 June 2023 19:18:45 CEST, Mike Stump via Gcc-patches > wrote: >> simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd >> say do it in python at the bottom as it would be nice to switch over to >> python in the next 5-20 years and away from tcl. > > Yes, i guess we have all pondered this for way long enough, but it is a lot > of work still. > > The nice side effect would be that we see such hogs easier and earlier, at > least more comfortable. But well. Either way, what should we do about remote > env, if there is one? If the target supports it, send it and skip otherwise? Testing is a large barrel of monkeys with a ton of small points, each of which is critical in some one. It is hard to talk about generalities when those details are very specific. So, to focus a conversation, which target, which host, canadian? Which part of the environment? What part is missing you want to fix? Want to unify between targets... and so on.
Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)
On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes > about 10 minutes to run for cris-elf in the "gdb simulator" I'd let the libstdc++ people comment on specific things. I'll comment on general things. We could let line count (or word count or character count) scale the timeout in part, we could record times in a db and put an expected run time into test cases or in an along side db. We could have factors for slow systems, slow simulators. A 5 GHz x86_64 will likely be faster that a 40 year old pdp11. We can have these scale factors trigger off OS, cpu statically, and/or we can do a quick bogomips calculation and let that scale it and record that scaling factor in the build tree. A wealth of possibilities. Solutions that require maintenance or test case modification are annoying. Solutions that need port work are annoying. I'd be tempted to say bogomips into the build (test) tree. There are two parts, time to compile test cases and time to run them. I'd be fine with a half solution that only does what you need. The other part can be done by someone that has a need. I'd invite comments by others on other solutions or commentary on downsides. For example, having a 208 thread count machine that takes 2-3 minutes to run the full testsuite is nice. A problem arises when 4-10 test cases suddenly start timing out. You then go to around 10-53 minutes to test, which is annoying. Anything that boosts the timeouts can hinder early port bring up, which, we'd like to avoid. I mention it without much a solution other than a db approach in the test tree that records each test case and can identify test cases that timeout and trim the timeout for them to something nicer like base + 50% once they timeout with a larger allotment of time. We could entertain wild thoughts. For example, make a run cache that caches run results given an object. See an object in the future, just look it up in a hash cache for the object and return those results instead of running it. This can give you a large speedup in testing and would simultaneously advantage all slow simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd say do it in python at the bottom as it would be nice to switch over to python in the next 5-20 years and away from tcl. A object cache in python, should be fairly small wether it is used for remembering run times from previous runs and setting a timeout based upon it, or as a does it run and pass or run and fail cache. The caches are likely only part of the problem, one still needs to have a timeout when no cache entry it present. They can speed testing for the day to day grind of people that run 1-200 times a week.
Re: Tighten 'dg-warning' alternatives in 'c-c++-common/Wfree-nonheap-object{,-2,-3}.c' (was: [PATCH] correct -Wmismatched-new-delete (PR 98160, 98166))
On Jun 7, 2023, at 8:01 AM, Thomas Schwinge wrote:
> On 2020-12-08T13:46:32-0700, Martin Sebor via Gcc-patches
> wrote:
>> The attached changes [...]
>
> ... eventually became commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
> "Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111,
> PR middle-end/98160)".
>
>> * c-c++-common/Wfree-nonheap-object-2.c: New test.
>> * c-c++-common/Wfree-nonheap-object-3.c: New test.
>> * c-c++-common/Wfree-nonheap-object.c: New test.
>
> OK to push the attached
> "Tighten 'dg-warning' alternatives in
> 'c-c++-common/Wfree-nonheap-object{,-2,-3}.c'"?
Ok.
Re: Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s' (was: [PATCH] add -Wmismatched-new-delete to middle end (PR 90629))
On Jun 7, 2023, at 7:54 AM, Thomas Schwinge wrote: > > On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches > wrote: >> Attached is a simple middle end implementation of detection of >> mismatched pairs of calls to C++ new and delete, along with >> a substantially enhanced implementation of -Wfree-nonheap-object. > > This eventually became commit dce6c58db87ebf7f4477bd3126228e73e497 > "Add support for detecting mismatched allocation/deallocation calls". > Already in this original patch submission: > >> diff --git a/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s >> b/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s >> new file mode 100644 >> index 000..e69de29bb2d > > OK to push the attached > "Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s'"? Ok.
Re: [testsuite] bump some tsvc timeouts
On Jun 7, 2023, at 1:12 AM, Alexandre Oliva wrote: > > Several tests are timing out when targeting x86-*-vxworks with qemu. > > Bump their timeout factor. Ok. I think these are obvious to people that have to work with simulators and the testsuite so if you want to self approve you can.
Re: [PATCH] [i386] Support type _Float16/__bf16 independent of SSE2.
LLM, machine learning and AI likes coding with data types that are weird, float16, bf16, 8 bit float and 4 bit floats. Longer term, would be nice to natively support these everywhere. Would be nice to trial run them in the compiler, sort it all out, so that the implementation experience can drive language adoption. A little speculative and a little narrow focus for the field, but, AI isn't going away in the next 20 years I don't think. Anyway, I like the direction. On Apr 19, 2023, at 12:15 AM, liuhongt via Gcc-patches wrote: > That said, these fundamental types whose presence/absence depends on ISA flags > are quite problematic IMHO, as they are incompatible with the target > attribute/pragmas. Whether they are available or not available depends on > whether in this case SSE2 is enabled during compiler initialization (aka after > parsing command line options) and then they are available or unavailable to > everything else based on that. > -comments end-- > > Enable _Float16 and __bf16 all the time but issue errors when the
Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]
On Mar 30, 2023, at 6:51 AM, Alexandre Oliva wrote: > > On Mar 30, 2023, Alexandre Oliva wrote: > >> If we're dropping the renaming, I suppose we could also revert Jakub's >> change. I suppose this patch will take care of it, pending testing... > > Regstrapped on x86_64-linux-gnu and also tested on arm-vx7r2 (with > gcc-12), where I used to get fails after an unsupported modules.exp > test, but there are no curly braces in the log files after the patch. > Ok to install? Ok.
Re: [Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64
On Feb 27, 2023, at 2:29 AM, Jonathan Yong via Gcc-patches wrote: > > Attached patch OK? Ok. >* c-c++-common/Warray-bounds.c: Fix excess warnings on > > LLP64.<0001-c-c-common-Warray-bounds.c-fix-excess-warnings-on-LL.patch>
Re: [PATCH] [testsuite] enable -maltivec like vect_int for signbit-2.c
On Mar 25, 2023, at 1:33 AM, Alexandre Oliva wrote: > > Explicitly enable altivec if it's supported. vect_int tests for > powerpc_altivec_ok, but without the explicit option, if altivec is not > enabled by default, we end up expecting vectorization that doesn't > occur. > > Regstrapped on ppc64-linux-gnu. Also tested with ppc64-vxworks7r2 > (gcc-12). Ok to install? Ok. > for gcc/testsuite/ChangeLog > > * gcc.dg/signbit-2.c: Add -maltivec if supported.
Re: [PATCH] testsuite: always use UTF-8 in scan-sarif-file[-not] [PR105959]
On Mar 20, 2023, at 3:06 PM, David Malcolm via Gcc-patches wrote: > > c-c++-common/diagnostic-format-sarif-file-4.c is a test case for > quoting non-ASCII source code in a SARIF diagnostic log. > > The SARIF standard mandates that .sarif files are UTF-8 encoded. > > PR testsuite/105959 notes that the test case fails when the system > encoding is not UTF-8, such as when the "make" invocation is prefixed > with LC_ALL=C, whereas it works with in a UTF-8-locale. > > The root cause is that dg-scan opens the file for reading using the > "system" encoding; I believe it is falling back to treating all files as > effectively ISO 8859-1 in a non-UTF-8 locale. > > This patch fixes things by adding a mechanism to dg-scan to allow > callers to (optionally) specify an encoding to use when reading the > file, and updating scan-sarif-file (and the -not variant) to always > use UTF-8 when calling dg-scan, fixing the test case with LC_ALL=C. > OK for trunk? Ok.
Re: [PATCH] [testsuite] test for weak_undefined support and add options
On Mar 15, 2023, at 11:40 PM, Alexandre Oliva wrote: > > On Mar 15, 2023, Alexandre Oliva wrote: > >> Regstrapped on ppc64-linux-gnu. Also tested (with gcc-12) on multiple >> *-vxworks7r2 targets (arm, aarch64, ppc64, x86, x86_64). Ok to install? > > Further testing revealed a problem in my attempted use of lappend in > aapcs64.exp, in the previous version of the patch. Fixed in this one, > retested on aarch64-vxworks7r2. Ok to install? Ok.
Re: [PATCH] testsuite: Support scanning tree-dumps
On Mar 6, 2023, at 10:52 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ok to apply? Ok. > * lib/target-supports.exp (check_compile): Support scanning tree-dumps.
Re: [PATCH 1/3] testsuite: Add tail_call effective target
On Mar 6, 2023, at 10:45 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ok to commit? Ok. > -- >8 -- > The RTL "expand" dump is the first RTL dump, and it also appears to be > the earliest trace of the target having implemented sibcalls. > Including the "," in the pattern searched for, to try and avoid > possible false matches, but there doesn't appear to be any identifiers > or target names nearby so this is just belts and suspenders. Using > "tail_call" as a shorter and more commonly used term than a derivative > of "sibling calls", and expecting only gcc folks to have heard of > "sibcalls". > > * lib/target-supports.exp (check_effective_target_tail_call): New.
Re: Ping: [PATCH 1/2] testsuite: Provide means to regexp in multiline patterns
Ok On Mar 3, 2023, at 5:58 PM, Hans-Peter Nilsson wrote: > > Ping... > >> From: Hans-Peter Nilsson >> Date: Fri, 24 Feb 2023 20:16:03 +0100 >> >> Ok to commit?
Re: [PATCH 0/2] LoongArch: testsuite: Fix tests related to stack
On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches wrote: > > Some trivial test case fixes. Ok for trunk? Ok.
Re: Ping: [PATCH] testsuite: Tweak gcc.dg/attr-aligned.c for CRIS
On Feb 27, 2023, at 5:54 PM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ping... Ok. > >> From: Hans-Peter Nilsson >> Date: Thu, 16 Feb 2023 21:05:29 +0100 > >> Asking for the lines outside the "#if __CRIS__" part. >> Ok to commit? >> >> -- >8 -- >> tm.texi says for BIGGEST_ALIGNMENT (from which >> __BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that >> any data type can require on this machine, in bits." >> >> That is, using that value might be too strict for alignment >> of *functions* and CRIS requires at least 16-bit alignment >> for functions. But, one purpose of the test is to test that >> alignment can be set to a large but valid value, so pick >> 512, which has some use as a historically required alignment >> for certain I/O descriptors. >> >> * gcc.dg/attr-aligned.c: Adjust comment for ALIGN_MAX_STATIC. >> (ALIGN_MAX_STATIC): Set to 512 for CRIS. >> --- >> gcc/testsuite/gcc.dg/attr-aligned.c | 8 +++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/gcc/testsuite/gcc.dg/attr-aligned.c >> b/gcc/testsuite/gcc.dg/attr-aligned.c >> index 887bdd0f3799..4f0c885dc812 100644 >> --- a/gcc/testsuite/gcc.dg/attr-aligned.c >> +++ b/gcc/testsuite/gcc.dg/attr-aligned.c >> @@ -18,6 +18,10 @@ >> # else >> # define ALIGN_MAX_STATIC ALIGN_MAX_HARD >> # endif >> +#elif __CRIS__ >> +/* __BIGGEST_ALIGNMENT__ doesn't cover functions (16 bits for CRIS). */ >> +# define ALIGN_MAX_STATIC 512 >> +# define ALIGN_TOO_BIG_OFILE (ALIGN_MAX_HARD << 1) >> #elif pdp11 >> # define ALIGN_MAX_STATIC 2 >> /* Work around a pdp11 ICE (see PR target/87821). */ >> @@ -29,7 +33,9 @@ >> /* Is this processor- or operating-system specific? */ >> # define ALIGN_MAX_STATIC ALIGN_MAX_HARD >> #else >> - /* Guaranteed to be accepted regardless of the target. */ >> + /* Guaranteed to be accepted regardless of the target for objects. >> + This might not be true for alignment of functions though, so >> + may need to be set to a target-specific value above. */ >> # define ALIGN_MAX_STATIC __BIGGEST_ALIGNMENT__ >>/* Guaranteed to be rejected regardless of the target. */ >> # define ALIGN_TOO_BIG_OFILE (ALIGN_MAX_HARD << 1) >> -- >> 2.30.2 >>
Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log
On Feb 27, 2023, at 9:59 AM, Hans-Peter Nilsson wrote:
>
>> From: Mike Stump
>> Date: Mon, 27 Feb 2023 09:41:18 -0800
>
>>> diff --git a/gcc/testsuite/lib/multiline.exp
>>> b/gcc/testsuite/lib/multiline.exp
>>> index 84ba9216642e..5eccf2bbebc1 100644
>>> --- a/gcc/testsuite/lib/multiline.exp
>>> +++ b/gcc/testsuite/lib/multiline.exp
>>
>>> - ${maybe_x}pass "$title was found: \"$escaped_regex\""
>>> + ${maybe_x}pass "$title was found"
>>> } else {
>>> - ${maybe_x}fail "$title not found: \"$escaped_regex\""
>>> + ${maybe_x}fail "$title not found"
>>
>> Side remark:
>>
>> So, the string on pass and the string on fail are supposed
>> to be exactly the same. Regression analysis works only if
>> the string is the same. "regexp test", might be
>> suggestive enough and can be the same spelling for both.
>
> Right. Should I changed it now?
Sure. Not required, but would be nice.
> (Pro: see above. Con: again meddling with regression-test history.)
Only new tests that don't have any polish do this sort of thing. :-)
> Like (editing on the fly here) as the "found" part seems
> redundant:
>
>>> - ${maybe_x}pass "$title was found"
>>> + ${maybe_x}pass "$title"
>>> } else {
>>> - ${maybe_x}fail "$title not found"
>>> + ${maybe_x}fail "$title"
Yes, same difference. Both strings should be identical.
Thanks.
Re: [PR100127] Test for coroutine header in clang-compatible tests
On Feb 22, 2023, at 12:04 PM, Alexandre Oliva wrote: > > That would change what gets tested with clang, I suppose, but I hope > that's for the better. I wondered what to do at the #else above, and > decided to spell it a little differently. Retested on x86_64-linux-gnu > (trunk) and arm-vxworks7r2 (gcc-12), ok to install? Ok.
Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log
On Feb 24, 2023, at 9:54 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ok to commit?
Ok. Thanks.
> diff --git a/gcc/testsuite/lib/multiline.exp b/gcc/testsuite/lib/multiline.exp
> index 84ba9216642e..5eccf2bbebc1 100644
> --- a/gcc/testsuite/lib/multiline.exp
> +++ b/gcc/testsuite/lib/multiline.exp
> - ${maybe_x}pass "$title was found: \"$escaped_regex\""
> + ${maybe_x}pass "$title was found"
> } else {
> - ${maybe_x}fail "$title not found: \"$escaped_regex\""
> + ${maybe_x}fail "$title not found"
Side remark:
So, the string on pass and the string on fail are supposed to be exactly the
same. Regression analysis works only if the string is the same. "regexp
test", might be suggestive enough and can be the same spelling for both.
Re: [PATCH] Drop need for constant I in ctf test
On Feb 16, 2023, at 10:59 PM, Alexandre Oliva wrote: > > Though I is supposed to be a constant expression, this is not the case > on vxworks, but this is not what this debug information format test is > testing for, so use real constants to initialize complex variables. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? Ok.
Re: [PATCH] [arm] xfail fp-uint64-convert-double-* on all arm targets
On Feb 16, 2023, at 10:20 PM, Alexandre Oliva wrote: > > It wasn't long ago that I xfailed these tests on arm-*-eabi, but the > fail is expected on all other arm targets: even when hard float is > available, conversions between 64-bit integers and double are always > emulated on ARM, and the emulation disregards rounding modes. So, > bump the xfail to all of arm-*-*. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? Ok.
Re: [arm] [testsuite] asm-flag-4.c: match quotes in expected message
On Feb 16, 2023, at 10:15 PM, Alexandre Oliva wrote: > > Quotes were added around the "asm" keyword in the message expected by > the test, so the test needs adjusting. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). > Ok to install? Ok.
Re: testsuite: Fix pr55569.c excess errors
On Dec 20, 2022, at 1:22 AM, Jonathan Yong via Gcc-patches wrote: > > This fixes the following: > > Excess errors: > > gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:12: warning: overflow in > conversion from 'long long unsigned int' to 'long int' changes value from > '4611686018427387903' to '-1' [-Woverflow] > > gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:34: warning: iteration > 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations] > > Patch OK? Ok.
Re: [PATCH] testsuite: btf: Fix btf-datasec-1.c for RISC-V
On May 10, 2022, at 6:31 PM, Kito Cheng via Gcc-patches wrote: > > LGTM, that's only added a new option for RISC-V and won't affect all > other targets, so I assume I can approve that. Yes. Usual and customary for ports.
Re: [PATCH Rust front-end v2 02/37] gccrs: Add nessecary hooks for a Rust front-end testsuite
Ok. > On Aug 24, 2022, at 4:59 AM, herron.phi...@googlemail.com wrote: > > From: Philip Herron > > This copy's over code from other front-end testsuites to enable testing > for the rust front-end specifically. > > Co-authored-by: Marc Poulhiès > Co-authored-by: Thomas Schwinge > --- > gcc/testsuite/lib/rust-dg.exp | 49 + > gcc/testsuite/lib/rust.exp| 186 ++
Re: [PATCH Rust front-end v2 02/37] gccrs: Add nessecary hooks for a Rust front-end testsuite
Ok. > On Aug 24, 2022, at 4:59 AM, herron.phi...@googlemail.com wrote: > > From: Philip Herron > > This copy's over code from other front-end testsuites to enable testing > for the rust front-end specifically. > > Co-authored-by: Marc Poulhiès > Co-authored-by: Thomas Schwinge > --- > gcc/testsuite/lib/rust-dg.exp | 49 + > gcc/testsuite/lib/rust.exp| 186 ++ -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: Rust frontend patches v1
On Aug 10, 2022, at 11:56 AM, Philip Herron wrote: > > For my v2 of the patches, I've been spending a lot of time ensuring > each patch is buildable. It would end up being simpler if it was > possible if each patch did not have to be like this so I could split > up the front-end in more patches. Does this make sense? In theory, > when everything goes well, does this still mean that we can merge in > one commit, or should it follow a series of buildable patches? I've > received feedback that it might be possible to ignore making each > patch an independent chunk and just focus on splitting it up as small > as possible even if they don't build. It is a waste of time to make each build. The all go in together, or not at all. The patches are split for review only. You can then maintain approval status for each individually and perform adjustments and updates for each patch. Once all pieces have been approved in their final form, you can then commit the whole at once. It is this commit, before you commit, that you regression test, integration test, and ensure that final form is good. If not, you bounce back to update for all the pieces that need it, approval for those edits, and lather, rinse, repeat. It is handy for larger work (like this) to be on a git branch so that followers can see the totality of the work and experiment with it in the large. I'd usually do the commit to the main branch as a squashed commit without the review edit histories or the "bad stuff" the reviewers had you change or the merge records even.
Re: [PATCH] i386 testsuite: cope with --enable-default-pie
On Jul 11, 2022, at 6:47 PM, Alexandre Oliva wrote: > > Running the testsuite on a toolchain build with --enable-default-pie > had some unexpected fails. > Regstrapped on x86_64-linux-gnu, and also tested on i686-linux-gnu, with > and without --enable-default-pie on both platforms. Ok to install? Ok. > PS: There's at least one additional FAIL with --enable-default-pie in > the trunk, namely gcc.target/i386/mvc7.c > WDYT? Seems reasonable.
Re: [PATCH] testsuite: add missing dg-require-effective-target fpic
Ok.
On May 5, 2022, at 2:35 AM, Marc Poulhies via Gcc-patches
wrote:
>
> Marc Poulhiès writes:
>
>> Require effective target fpic for newly added test.
>>
>> gcc/testsuite/
>> * g++.dg/ext/visibility/visibility-local-extern1.C: Add missing
>> dg-require-effective-target fpic.
>>
>> Tested on x86_64-linux. Ok for master?
>>
>> ---
>> gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> b/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> index 40c20199d0c..6fb1cc7f381 100644
>> --- a/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> +++ b/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> @@ -1,6 +1,7 @@
>> // PR c++/103291
>> // { dg-additional-options -fpic }
>> // { dg-final { scan-assembler-not "@GOTPCREL" } }
>> +// { dg-require-effective-target fpic }
>>
>> #pragma GCC visibility push(hidden)
>
> ping ?
Re: [PATCH] testsuite/s390: Adapt test expections.
On Apr 4, 2022, at 4:52 AM, Robin Dapp via Gcc-patches wrote: > OK for trunk? > +/* Since r12-4475-g247c407c83f001 the following immediates are being > + converted and directly stored in the literal pool so no explicit > + conversion is necessary. */ Not fan of git revision numbers in the source code. Also, having historical behaviors most of the time isn't useful/interesting, so I'd generally omit such descriptions.
Re: [PATCH v6 11/12] LoongArch Port: gcc/testsuite
On Jan 28, 2022, at 5:49 AM, chenglulu wrote: > > gcc/testsuite/ > >* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch. >* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support. >* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch. >* gcc.dg/20020312-2.c: Add LoongArch support. >* gcc.dg/loop-8.c: Skip on LoongArch. >* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise. >* gcc.dg/tree-ssa/ssa-fre-3.c: Likewise. >* go.test/go-test.exp: Define the LoongArch target. >* lib/target-supports.exp: Like wise. >* gcc.target/loongarch/loongarch.exp: New file. >* gcc.target/loongarch/tst-asm-const.c: Like wise. Ok.
Re: [PATCH] testsuite: Fix up tree-ssa/divide-7.c testcase [PR95424]
On Jan 29, 2022, at 8:26 AM, Jakub Jelinek via Gcc-patches wrote: > > This test fails everywhere, because ? doesn't match literal ?. > It should use \\? instead. I've also changed those .s in there. > Tested on x86_64-linux (-m32/-m64) and powerpc64le-linux, ok for trunk? Ok.
Re: [PATCH] Fix spelling of ones' complement.
On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches wrote: > > Nitpicking time. It's spelled "ones' complement" rather than "one's > complement". I didn't go into config/. > > Ok for trunk? So, is it two's complement or twos' complement then? Seems like it should be the same, but wikipedia suggests it is two's complement, as does google. If that is wrong, you should go edit it as well. :-)
Re: [PATCH] testsuite, Darwin : Do not claim 'GAS' for cctools assembler.
On Aug 19, 2021, at 1:02 PM, Iain Sandoe wrote: > > Although the cctools assembler is based of GNU GAS, it is from a > very old version (1.38) which does not support many of the features > that the target supports test is expecting***. > > tested on i686 and x86_64 darwin versions using the cctools as. > OK for master? Ok.
Re: [PATCH] wwwdocs: Clarify meaning of "not issued by" in bugs web page
On Jul 27, 2021, at 10:30 AM, Martin Sebor via Gcc-patches wrote: > On 7/27/21 9:16 AM, Jonathan Wakely via Gcc-patches wrote: >> Secondly, releases are not issued by the GNU Project at all, they're >> issued by the GCC release managers. > > I (and I suspect most users unfamiliar with the inner workings of > the project) think of release managers as acting on behalf of > the whole project, so even though they technically cut the release > it's still put out by the project as a whole. I agree. The GCC releases we put out are GCC project releases, and GNU project software releases.
Re: Add '__OPTIMIZE__' DejaGnu selector
On May 18, 2021, at 9:02 AM, Thomas Schwinge wrote: > Is the attached "Add '__OPTIMIZE__' DejaGnu selector" OK to push after > testing? Ok.
Re: [GOVERNANCE] Where to file complaints re project-maintainers?
This isn't a patch to gcc, please stop posting non-technical content to this
list. Please review what this list is for and the rules for this list before
you post again, thanks.
> On May 14, 2021, at 7:47 AM, abebeos via Gcc-patches
> wrote:
>
> Hi there IT-fascists, clowns, master-clowns,
> totally-confused-incompetent-code-plumbers,
> activity-trapped-silent-high-performers,
> stay-out-of-trouble-silent-high-performers! (Guess where G.J. Lay fits in
> the collection...).
>
> Please be aware that I do not read any messages here (including the one I'm
> replying to), in this unregulated circus-show ("The GCC Project"). I've
> polluted my mind enough with your nonsense justifications, to be honest it
> is becoming quite disgusting.
>
> If any serious person from the FSF (as to my tiny research, the FSF is in
> the end legally and ethically responsible for what happens on GCC) want to
> comment on this, please send me additionally a copy of your message.
>
> FSF:
>
> Copyright: https://www.fsf.org/about/dmca-notice
> Privacy: https://www.fsf.org/about/free-software-foundation-privacy-policy
> IT-fascists, Bullying, discrimination, workers-abuse, rigged voting
> processes: ???
Re: fix asm-not pattern in dwarf2/inline5.c
On Apr 27, 2021, at 8:32 AM, Alexandre Oliva wrote: > > The test is supposed to check that the abstract lexical block of a > function that was inlined doesn't have attributes, and that the > concrete inlined lexical block does. > The problem is that '[.../...]+ +[^(].*' matches '/ (DIE...', because > '[^(]' may match the second blank, and after that anything goes. > Ok to install? Ok.
Re: add rv64im{,c,fc} multilibs
On Feb 24, 2021, at 1:10 AM, Alexandre Oliva wrote: > > On Feb 23, 2021, Jim Wilson wrote: >> If we add default multilibs for you > > *nod*, it's a very familiar issue to me, I know where that's coming > from, no worries. So, what I'd do is if you have a triplet component that isn't used much, say, the middle one, you can embed the vendor there, and use the vendor to trigger which multilib set you want. i386-unknown-linux becomes i386-telcovendor2-linux and then telcovendor2 selects new multilib set. The generic port, selects the base multilib set, and no one, other then a vendor build would select the vendor set. That's one solution, there are others. For example, on a system, you can smell the previously installed multilib set, and default to building those.
Re: c++: Macros need to be GTY-reachable [PR 99023]
On Feb 18, 2021, at 6:15 AM, Jakub Jelinek via Gcc-patches wrote: > > On Wed, Feb 17, 2021 at 01:46:37PM -0500, Nathan Sidwell wrote: >> I'd missed that macros were allocated from GC storage, and that they can >> become unattached from an identifier, and therefore not GC-reachable. >> And then bad things happen. Fixed by making the module machinery's >> reference vector a GC root. >> >> PR c++/99023 >>gcc/cp/ >>* module.cc (struct macro_export): Add GTY markers. >>(macro_exports): Likewise, us a va_gc Vector. >>gcc/testsuite/ >>* g++.dg/modules/pr99023_a.H: New. >>* g++.dg/modules/pr99023_b.H: New. > > I must say I don't know much about modules, but seeing the second set > of > 100KB g++.dg/modules/ testcases Indeed, a test case that shows a memory error, likely is misguided at any size as we don't have a system to reliably detect when we are wondering outside the GTY sandbox.
Re: [PATCH][testsuite] (committed) Fix sed script errors in complex tests
On Jan 15, 2021, at 1:13 AM, Tamar Christina via Gcc-patches wrote: > I ran sed script late over the tests which accidentally > introduced a syntax error in the tests. > > This fixes it. > > Committed under the obvious rule. > > Ok for master? :-) Which is it? Anyway, Ok.
Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...
On Jan 1, 2021, at 6:41 PM, Alexandre Oliva wrote:
>
> On Jan 1, 2021, Mike Stump wrote:
>
>> On Jan 1, 2021, at 3:37 PM, Alexandre Oliva wrote:
>>>
>>> On Dec 29, 2020, Mike Stump wrote:
>>>
>>>> a[i-1] = i;
>>>
>>> 'fraid that won't pass:
>>>
>>> for (int i = 0; i < n; i++) {
>>> assert (a[i] == i);
>>> }
>
>> Ok, how about your version with the comment updated?
>
> Err, are we talking about the same testcase?
> There aren't any comments in this one.
Oh, It's possible the comments were stripped from the bug report or initial
email. Never mind then about the comment part.
Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...
On Jan 1, 2021, at 3:37 PM, Alexandre Oliva wrote:
>
> On Dec 29, 2020, Mike Stump wrote:
>
>> a[i-1] = i;
>
> 'fraid that won't pass:
>
>for (int i = 0; i < n; i++) {
>assert (a[i] == i);
>}
Ok, how about your version with the comment updated?
Re: disable some aapcs/vfp*.c test if not arm_fp16_alternative_ok
On Dec 22, 2020, at 1:47 PM, Alexandre Oliva wrote: > > The tests use -mfp16-format=alternative, and so should not be run > if that option isn't supported. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: fix testsuite/g++.dg/init/new26.C for C++-14 and later
On Dec 22, 2020, at 1:40 PM, Alexandre Oliva wrote: > > This test fails during the execution on VxWorks 7 when using > C++-14 and C++-17. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: g++.dg/tls/pr79288.C: Skip on vxworks_kernel (TLS model not supported)
On Dec 22, 2020, at 1:57 PM, Alexandre Oliva wrote: > > The only TLS model supported in VxWorks kernel mode is local-exec. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: compile gcc.target/arm/{pr78255-2.c, memset-inline-2.c} with -mno-long-calls
On Dec 22, 2020, at 1:56 PM, Alexandre Oliva wrote: > > This change adds -mno-long-calls to the list of compiler options > to make sure we generate short call code, allowing the assembly > matching to pass. > > This is added unconditionally to the dg-options (as opposed to using > dg-additional-options) because this test is already specific to ARM > targets, and -mno-long-calls is available on all ARM targets. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Fix testsuite/g++.old-deja/g++.mike/p658.C build failure on VxWorks RTP
On Dec 22, 2020, at 1:45 PM, Alexandre Oliva wrote: > > The conflicting definition of OK is present in VxWorks RTP headers too. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. Ok to stylize all the #undef in the same way. This is one happens to use a slightly different stye then the others as I recall.
Re: Fix testsuite/g++.dg/opt/20050511-1.C compilation error on VxWorks 7
On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote: > > In VxWorks 7, UINT32 is defined in both modes, kernel and rtp. Adjust > the work around accordingly. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...
On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote:
>
> The constexpr iteration dereferenced an array element past the end of
> the array.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
How about:
a[i-1] = i;
instead? This I think better matches the comment in the code, and preserves
the expected output as well.
If you like that and that works, Ok for that version.
> from Jerome Lambourg
> for gcc/testsuite/ChangeLog
>
>* g++.dg/cpp1y/constexpr-66093.C: Fix bounds issue.
> ---
> gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> index ad3169210d29a..3d742cfebd83d 100644
> --- a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> @@ -19,7 +19,7 @@ private:
>
> constexpr A f() {
> A a{};
> -for (int i = 1; i <= n; i++) {
> +for (int i = 0; i < n; i++) {
> a[i] = i;
> }
> return a;
Re: Skip testsuite/g++.old-deja/g++.pt/const2.C on vxworks_kernel
On Dec 22, 2020, at 1:43 PM, Alexandre Oliva wrote:
>
> Linking in vxworks kernel-mode is partial linking, so missing symbols
> are not detected.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
Generally nicer to bunch all like ones ("partial link" for example) together.
Re: Remove VxWorks-specific test directives in g++.dg/warn/miss-format-1.C
On Dec 22, 2020, at 1:42 PM, Alexandre Oliva wrote: > > These are no longer applicable. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Undefine ERROR in g++.dg/tree-ssa/copyprop.C
On Dec 22, 2020, at 1:41 PM, Alexandre Oliva wrote: > > VxWorks headers define ERROR as a macro, which conflicts with the use > in the test. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: skip testsuite/g++.dg/other/anon5.C on vxworks_kernel targets
On Dec 22, 2020, at 1:40 PM, Alexandre Oliva wrote: > > The vxworks kernel-mode linking is partial linking, so it cannot > detect missing symbols. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Add conditions on VxWorks versions for gcc.dg/vxworks/initpri?.c
On Dec 22, 2020, at 1:37 PM, Alexandre Oliva wrote: > > Adjust vxworks initpri expectations, given that vxworks7 has switched > to .init_array. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. I suppose I should say that if the port maintainers want to chime in and recommend a different solution or have different idea on how to do things, I'd encourage them to chime in. I'm kicking in only because no one else has yet, and thats roughly what I do.
