/pr118067-2.c (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-7008/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without
Hi!
With the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html
hack we get slightly different error wording in one of the errors, given that
the test actually does use #embed, I think both wordings are just fine and
we should accept them.
Tested on x86_64-linux, committed to
, fix test builtins-1-p10-runnable.c
The test has two issues:
1) The test should generate execute abort() if an error is found.
However, the test contains a #define 0 which actually enables the
error prints not exectuting void() because the debug code is protected
by an #ifdef not #if. The #define
> From: Sandra Loosemore
> Sent: Friday, January 17, 2025 12:11 PM
>
Thanks for the quick fix!
Thx,
Haochen
> gcc/testsuite/ChangeLog
> * c-c++-common/gomp/metadirective-device.c: Don't add extra
> options
> for target ia32.
> * c-c++-common/gomp/metadirective-target-device-1
gcc/testsuite/ChangeLog
* c-c++-common/gomp/metadirective-device.c: Don't add extra options
for target ia32.
* c-c++-common/gomp/metadirective-target-device-1.c: Likewise.
---
gcc/testsuite/c-c++-common/gomp/metadirective-device.c | 2 +-
gcc/testsuite/c-c++-common
On Jan 16, 2025, at 11:42 AM, Alexandre Oliva wrote:
>
> Tests that include need to be skipped when libstdc++ is built
> in freestanding mode.
Ok.
> for gcc/testsuite/ChangeLog
>
> PR rtl-optimization/113994
> * g++.dg/pr113994.C: Require hosted libstdc++.
Tests that include need to be skipped when libstdc++ is built
in freestanding mode.
for gcc/testsuite/ChangeLog
PR rtl-optimization/113994
* g++.dg/pr113994.C: Require hosted libstdc++.
---
gcc/testsuite/g++.dg/torture/pr113994.C |1 +
1 file changed, 1 insertion(+)
dif
Replace some `__cplusplus > 201402L` preprocessor checks with more
expressive checks for the appropriate feature test macro.
libstdc++-v3/ChangeLog:
* include/bits/stl_map.h: Check __glibcxx_node_extract instead
of __cplusplus.
* include/bits/stl_multimap.h: Likew
This test should use __cpp_lib_ios_noreplace rather than the internal
__glibcxx_ios_noreplace macro.
libstdc++-v3/ChangeLog:
* testsuite/27_io/ios_base/types/openmode/case_label.cc: Use
standard feature test macro not internal one.
---
Tested x86_64-linux. Pushed to trunk
The alloc_ptr.cc test for std::set tries to use C++17 features
unconditionally, and tries to use the C++23 range members which haven't
been implemented for std::set yet.
Some of the range checks are left in place but commented out, so they
can be added after the ranges members are implem
libstdc++-v3/ChangeLog:
* testsuite/28_regex/traits/char/transform_primary.cc: Fix
subclause numbering in references to the standard.
---
Pushed to trunk.
.../testsuite/28_regex/traits/char/transform_primary.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
dif
On 1/10/25 1:38 AM, Robin Dapp wrote:
Hi,
the zbb-rol-ror and stack_save_restore tests use the -fno-lto option and
scan the final assembly. For an invocation like -flto ... -fno-lto the
output file we scan is still something like
zbb-rol-ror-09.ltrans0.ltrans.s.
Therefore skip the tests
While testing an unrelated C++ patch with "make check-c++-all", I
noticed that r15-6760-g38a13ea4117b96 added a test case that fails with
-fimplicit-constexpr.
The problem is that this test unconditionally expects an error stating
that a non-constexpr function is called, but that functi
Tested on x86_64-pc-linux-gnu, committing as obvious.
-- >8 --
GCC14 doesn't have the new spelling '-fmodules' for enabling modules;
use the old '-fmodules-ts' spelling instead.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr114630_a.C: Use -fmodules-ts instead of
-fmodules in test
/pr114630_a.C module-cmi X (gcm.cache/X.gcm)
FAIL: g++.dg/modules/pr114630_a.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/pr114630_a.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/pr114630_a.C -std=c++2b (test for excess errors)
with GCC configured with
../../gcc
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed by r15-6740.
PR c++/118391
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval20.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/lambda-uneval20.C | 15 +++
1 file changed, 15 insertions(+)
create m
On 2025-01-10 16:46, Richard Earnshaw (lists) wrote:
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
a pattern is needed that uses PUSH/BL/POP sequence instead of a single
B instruction
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
> a pattern is needed that uses PUSH/BL/POP sequence instead of a single
> B instruction to reuse an already existing function in the
The commit message contains an explanation.
commit 94d8de53388793f4d5fc0d0aa00fef32ca4aa870
Author: Vladimir N. Makarov
Date: Fri Jan 10 10:36:24 2025 -0500
[PR118017][LRA]: Fix test for i686
My previous patch for PR118017 contains a test which fails on i686. The patch fixes
[PATCH v5] Introduce strub:
machine-independent stack scrubbing"
implies, it here fails in the same way as:
> '__builtin_stack_address()' synthesizes code that fails to assemble.
> (Which is "OK".) To document the status quo, I've pushed to trunk branch
> comm
ess()' synthesizes code that fails to assemble.
(Which is "OK".) To document the status quo, I've pushed to trunk branch
commit 91dec10f8b7502bdd333d75ab7a9e23a58c3f32d
"nvptx: Add '__builtin_stack_address()' test case", see attached.
Grüße
T
Hi,
the zbb-rol-ror and stack_save_restore tests use the -fno-lto option and
scan the final assembly. For an invocation like -flto ... -fno-lto the
output file we scan is still something like
zbb-rol-ror-09.ltrans0.ltrans.s.
Therefore skip the tests when "-flto" is present. This gets rid
of a
On Fri, 10 Jan 2025, Alexandre Oliva wrote:
>
> There was a cut&pasto in the rr_and_mask's adjustment to match the
> combined type: the test on whether there was a mask already was
> testing the wrong variable, and then it might crash or otherwise fail
> accessing an un
There was a cut&pasto in the rr_and_mask's adjustment to match the
combined type: the test on whether there was a mask already was
testing the wrong variable, and then it might crash or otherwise fail
accessing an undefined mask. This only hit with checking enabled,
and rarel
/i386/pr118017.c (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6751/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --withou
Documenting the status quo.
PR target/65181
gcc/testsuite/
* gcc.target/nvptx/__builtin_stack_save___builtin_stack_restore-1.c:
Add.
---
...tin_stack_save___builtin_stack_restore-1.c | 32 +++
1 file changed, 32 insertions(+)
create mode 100644
gc
Documenting the status quo. This specific behavior relates to a 1994 change
(Subversion r7229, Git commit 15fc002672d643fd9d93d220027b5cd2aefc632c).
That one, however, isn't to blame here: we'd otherwise of course run into
nvptx' 'sorry, unimplemented: target cannot support alloca'.
PR ta
Documenting the status quo.
PR target/65181
gcc/testsuite/
* gcc.target/nvptx/alloca-2-O1.c: New.
---
gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c
d
766365c0c7023be55ebef67b70bf4
"nvptx: Add 'sorry, unimplemented: target cannot support alloca' test cases
[PR65181]",
see attached.
Grüße
Thomas
>From aae1db742a1766365c0c7023be55ebef67b70bf4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 11 Dec 2024 15:22:0
ommon/gomp/dispatch-11.c at line 45 (test for errors, line 43)
FAIL: c-c++-common/gomp/dispatch-11.c at line 52 (test for warnings, line 21)
FAIL: c-c++-common/gomp/dispatch-11.c at line 56 (test for warnings, line 25)
FAIL: c-c++-common/gomp/dispatch-11.c at line 79 (test for errors, line 77)
FAIL
rminated with signal 11 [Segmentation fault], core
> dumped
The latter is gone with 'ptxas' of, for example, CUDA 11.5 and later.
Pushed to trunk branch commit 84e90b69fba1cfa2a77942251ddfd0527fb22811
"nvptx: Re-enable "Stack alignment causes use of alloca" test cases&qu
Ok for trunk and releases/gcc-14?
--
Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
a pattern is needed that uses PUSH/BL/POP sequence instead of a single
B instruction to reuse an already existing function in the compile unit.
gcc/testsuite/ChangeLog:
* gcc.targe
nfo;
>> _13 = (uint) &__start_minfo;
>> _14 = (uint) &gdc.dso_slot;
>> _15 = {1, _14, _13, _12};
>> gdc.dso_initialized = 0;
>> MEM [(void *)&D.1974 + 16B] = {};
>> MEM [(void *)&D.1974] = _15;
>> _d_dso_registry
> _15 = {1, _14, _13, _12};
> gdc.dso_initialized = 0;
> MEM [(void *)&D.1974 + 16B] = {};
> MEM [(void *)&D.1974] = _15;
> _d_dso_registry (&D.1974);
>
> This causes the scan-tree-dump-not test to fail. As ModuleInfo is not
> what's being chec
_initialized = 0;
MEM [(void *)&D.1974 + 16B] = {};
MEM [(void *)&D.1974] = _15;
_d_dso_registry (&D.1974);
This causes the scan-tree-dump-not test to fail. As ModuleInfo is not
what's being checked for in PR110406, remove its generation altogether.
Bootstrapped an
The test was failing on x86 because longdouble128 only checks sizeof,
rather than a full 128-bit payload. Using _Float128 is more portable
and still exposes the original bug.
Tested on aarch64-linux-gnu and x86_64-linux-gnu, pushed as obvious.
Richard
gcc/testsuite/
PR target/118184
/pr118184.c -O0 execution test
FAIL: gcc.dg/torture/pr118184.c -O1 execution test
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6503/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable
; +/* { dg-options "-mdejagnu-cpu=power9 -O2" } */
> /* { dg-require-effective-target powerpc_vsx } */
This test is not typically needed at all, but yeah, it is possible some
tester decides to sabotage himself and disables VSX on new systems. The
extra check isn't really harmful anyway (it just might suggest to others
that it is required).
Okay for trunk and any backports you want. Thanks!
Segher
Andrew Pinski writes:
> On Wed, Jan 1, 2025, 9:38 AM Sam James wrote:
>
> gcc/ChangeLog:
>
> * doc/cpp.texi (Common Predefined Macros): Fix syntax.
>
> This looks obvious correct to me.
Agreed, I'll push it now.
>
> Thanks,
> Andrew
>
> ---
> gcc/doc/cpp.texi | 2 +-
> 1 file cha
On Wed, Jan 1, 2025, 9:38 AM Sam James wrote:
> gcc/ChangeLog:
>
> * doc/cpp.texi (Common Predefined Macros): Fix syntax.
>
This looks obvious correct to me.
Thanks,
Andrew
---
> gcc/doc/cpp.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/doc/cpp.texi
gcc/ChangeLog:
* doc/cpp.texi (Common Predefined Macros): Fix syntax.
---
gcc/doc/cpp.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 970c0a393971..4b0f2d9bb857 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1974
Ping!
please review.
Thanks & Regards
Jeevitha
On 15/10/24 12:49 pm, jeevitha wrote:
> Hi All,
>
> Removed powerpc*-*-* from the target test as it is always true. Simplified
> options by removing -mpower9-misc and -mvsx, which are enabled by default with
> -mdeja
So this BZ is a case where we incorrectly indicated that the operand
array was suitable for the t-head load/store pair instructions.
In particular there's a test which checks alignment, but that happens
*before* we know if the operands are going to be reversed. So the
routine reporte
Hi!
The test used #include "", so FAILed everywhere with
fatal error: : No such file or directory
Tested on x86_64-linux with RUNTESTFLAGS=conformance.exp=pr118196.cc
without/with the patch, committed to trunk as obvious.
2024-12-28 Jakub Jelinek
PR libstd
: 24_iterators/range_generators/pr118196.cc -std=gnu++23 (test for excess
errors)
FAIL: 24_iterators/range_generators/pr118196.cc -std=gnu++26 (test for excess
errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6447/usr
--enable-clocale
Hello-
This patch helps tools like contrib/compare_tests work out of the box for the
libitm testsuite. Without this change, compare_tests complains if the test
runs being compared were in different build directories.
I just moved the -B argument from one place to another, so the command line
> Am 22.12.2024 um 23:10 schrieb Christoph Müllner
> :
>
> Recently two test cases for PR118149 have been added.
> While pr118149-2.c works well for AArch64, pr118149.c fails
> because the expected optimization in forwprop4 cannot be applied
> as SLP vectorization do
Recently two test cases for PR118149 have been added.
While pr118149-2.c works well for AArch64, pr118149.c fails
because the expected optimization in forwprop4 cannot be applied
as SLP vectorization does not happen.
This patch fixes this issue by disabling the check on AArch64.
Signed-off-by
ssing it's similar to your other patch for attr-neon* tests?
And that the best / easiest course of action for the moment is to skip
this test on M-profile?
Exactly.
Without my patch, it would fail for armv8.1-m.main targets with -mfloat-
abi=hard due to that the include file "arm_neon.h&quo
On 2024-08-27 13:49, Richard Earnshaw (lists) wrote:
On 13/08/2024 17:18, Andre Vieira (lists) wrote:
I'm not a maintainer but I'd argue the entire test is bogus.
The error reporting in this area seems to be somewhat fragile, if you compile it with
'-march=armv7-a -mfloat
Ping!
please review.
Thanks & Regards
Jeevitha
On 02/12/24 2:04 pm, jeevitha wrote:
> Ping!
>
> please review.
>
> Thanks & Regards
> Jeevitha
>
> On 15/10/24 12:49 pm, jeevitha wrote:
>> Hi All,
>>
>> Removed powerpc*-*-* from the target t
oversight
when doing the update in r12-8108-g62082d278d1.
Anyway, the commit message suggest that it's only the constant that
is of
interrest, so I updated the test to only check the constant. Do you
think
this is enough, or is should the test case also verify that it's
used in
a "
On 9/5/24 3:20 AM, Jakub Jelinek wrote:
Hi!
Similarly for likely/unlikely attributes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-likely1.C: New test.
* g++.dg/cpp0x/attr
apped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-fallthrough1.C: New test.
* g++.dg/cpp0x/attr-fallthrough2.C: New test.
--- gcc/testsuite/g++.dg/cpp0x/attr-fallthrough1.C.jj 2024-09-04
On 9/5/24 3:17 AM, Jakub Jelinek wrote:
Hi!
This patch adds additional test coverage for the carries_dependency
attribute (unlike other attributes, the attribute actually isn't implemented
for real, so we warn even in the cases of valid uses because we ignore those
as well).
Bootstr
troduced in r12-5301,
right?
Ah, I see. The pr was referring to two tests:
gcc.target/arm/pr42093.c which is the jump tables test and
gcc.target/arm/pr43920-2.c which is the test you are working on.
the digits in those two PR numbers are identical, but in a different
order. When I looked earl
d1.
Anyway, the commit message suggest that it's only the constant that
is of
interrest, so I updated the test to only check the constant. Do you
think
this is enough, or is should the test case also verify that it's used in
a "set" expression?
Ok for trunk and releases/gcc
On 2024-12-12 12:02, Richard Earnshaw (lists) wrote:
On 10/11/2024 10:02, Torbjörn SVENSSON wrote:
Ok for trunk, releases/gcc-12, releases/gcc-13 and releases/gcc-14?
--
In version 6-2017-q1-update of the "GNU Arm Embedded Toolchain" build,
there are 2 pop instructions. In version 7-2018-q2
#x27;s only the constant that is of
interrest, so I updated the test to only check the constant. Do you think
this is enough, or is should the test case also verify that it's used in
a "set" expression?
Ok for trunk and releases/gcc-14?
--
The test case was re-writtend in r12-8108-g620
instances that this patch
series test
and in some cases fixes the expected output. This patch series does
not follow
a formal definition or a spec of how OMP interacts with SVE ACLE
types, so its
more of a proposed behaviour. Comments and discussion welcome.
This list is not exhaustive,
maximum one conditional instruction, force
Cortex-M4 to have a stable test case.
gcc/testsuite/ChangeLog:
* gcc.target/arm/thumb-ifcvt.c: Use -mtune=cortex-m4.
OK.
R.
Pushed as r15-6168-ge7615f6c99f and r14.2.0-556-gcbedb3394a2.
Kind regards,
Torbjörn
On 2024-12-04 12:46, Richard Earnshaw (lists) wrote:
On 21/11/2024 17:23, Torbjörn SVENSSON wrote:
I'm not sure how to verify that adding the parameter won't destroy the test.
I've tried to repoduce the ICE on old Arm builds of arm-none-eabi, but none of
them ICE. I suppose it
On 2024-12-04 19:52, Richard Earnshaw (lists) wrote:
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
The test case gcc.target/arm/its.c was created together with restriction
of IT blocks for Cortex-M7. As the test case fails on all tunes that
does not match Cortex-M7, explicitly test it for
On 2024-12-04 19:54, Richard Earnshaw (lists) wrote:
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
Update test case to use -mcpu=unset/-march=unset feature introduced in
r15-3606-g7d6c6a0d15c.
gcc/testsuite/ChangeLog:
* gcc.target/arm/lto/pr96939_0.c: Use effective-target
On 10/11/2024 13:38, Torbjörn SVENSSON wrote:
Hi Richard,
I'm not sure if I'm doing something wrong here, or if it was an oversight
when doing the update in r12-8108-g62082d278d1.
Anyway, the commit message suggest that it's only the constant that is of
interrest, so I updated t
On 10/11/2024 10:02, Torbjörn SVENSSON wrote:
Ok for trunk, releases/gcc-12, releases/gcc-13 and releases/gcc-14?
--
In version 6-2017-q1-update of the "GNU Arm Embedded Toolchain" build,
there are 2 pop instructions. In version 7-2018-q2-update, the next
version that still have a binary build
ira_prohibited_class_mode_regs
caused
FAIL: gcc.target/i386/pr117946.c (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6091/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c
Check the __glibcxx_polymorphic_allocator macro instead of just checking
whether __cplusplus > 201703L.
libstdc++-v3/ChangeLog:
* include/bits/memory_resource.h (polymoprhic_allocator): Use
feature test macro for P0339R6 features.
---
Tested x86_64-linux. Pushed to tr
On Mon, Dec 9, 2024 at 8:38 PM Hans-Peter Nilsson wrote:
>
> I could probably assume that this is what you had in mind,
> but anyway: Ok to commit?
OK.
> -- >8 --
> PR117973 covers the aspect of
> non-LOGICAL_OP_NON_SHORT_CIRCUIT targets for PR111456, for
> which the t
-std=c++26 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6063/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --withou
ninit-pr105562.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/warn/uninit-pr105562.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/warn/uninit-pr105562.C -std=gnu++26 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/m
I could probably assume that this is what you had in mind,
but anyway: Ok to commit?
-- >8 --
PR117973 covers the aspect of
non-LOGICAL_OP_NON_SHORT_CIRCUIT targets for PR111456, for
which the test-case gcc.dg/tree-ssa/pr111456-1.c started
failing as described in PR117954.
* gcc.dg/t
This testsuite only patch allows us to test code generation for CRC
functions using clmul instructions.
Conceptually it's trivial. We already have various execution tests in
gcc.dg/torture. We just define a new set of dg directives and include
the testcase in gcc.dg/torture.
The
-O1 execution test
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6016/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx
Hi!
On 2022-03-29T14:03:22+0200, Tom de Vries via Gcc-patches
wrote:
> [...]
>
> gcc/testsuite/ChangeLog:
>
> 2022-03-29 Tom de Vries
>
> PR target/104714
> * gcc.target/nvptx/march-map.c: New test.
Pushed to trunk branch commit ee6711ead30876daf2a8a66
Hi!
On 2022-03-01T09:00:45+0100, Tom de Vries via Gcc-patches
wrote:
> Add a few test-cases that test passing each -misa=sm_xx version and verify
> that
> the proper __PTX_SM__ is defined.
Pushed to trunk branch commit ed96ce81b19b76ba6a5edfe68dd86d8ea319c6d9
"nvptx: E
Hi!
On 2022-03-29T16:17:43+0200, Tom de Vries via Gcc-patches
wrote:
> [...]
>
> gcc/testsuite/ChangeLog:
>
> 2022-03-29 Tom de Vries
>
> PR target/104857
> * gcc.target/nvptx/ptx31.c: New test.
> * gcc.target/nvptx/ptx60.c: New test.
> *
On 06/12/2024 10:02, Christophe Lyon wrote:
> This test would fail if GCC is configured with non-default options,
> such as -mtune=cortex-a9.
>
> This 'unexpected' scheduling makes the DLSTP optimization generate
> subslr, #16
> bhi .L4
> l
This test would fail if GCC is configured with non-default options,
such as -mtune=cortex-a9.
This 'unexpected' scheduling makes the DLSTP optimization generate
subslr, #16
bhi .L4
lctp
pop {r4, r5, pc}
.L4:
sub ip, ip, #16
> > Removed powerpc*-*-* from the target test as it is always true. Simplified
> > options by removing -mpower9-misc and -mvsx, which are enabled by default
> > with
> > -mdejagnu-cpu=power9. The has_arch_pwr9 check is also true with
> > -mdejagnu-cpu=power9, so it
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test case to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/lto/pr96939_0.c: Use effective-target
> arm_arch_v8a.
>
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> The test case gcc.target/arm/its.c was created together with restriction
> of IT blocks for Cortex-M7. As the test case fails on all tunes that
> does not match Cortex-M7, explicitly test it for Cortex-M7. To have some
> additional fa
On 21/11/2024 17:23, Torbjörn SVENSSON wrote:
> I'm not sure how to verify that adding the parameter won't destroy the test.
> I've tried to repoduce the ICE on old Arm builds of arm-none-eabi, but none of
> them ICE. I suppose it should be safe to add the parameter as
gt; bx lr
>
> As Cortex-M7 only allow maximum one conditional instruction, force
> Cortex-M4 to have a stable test case.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/thumb-ifcvt.c: Use -mtune=cortex-m4.
OK.
R.
>
> Signed-off-by: Torbjörn SVENSSON
-functions (test for excess
errors)
FAIL: gfortran.dg/class_transformational_1.f90 -O3 -g (internal compiler
error: in make_ssa_name_fn, at tree-ssanames.cc:355)
FAIL: gfortran.dg/class_transformational_1.f90 -O3 -g (test for excess
errors)
with GCC configured with
../../gcc/configure
The previous target selector was not properly gating the tests to rv32
and rv64 targets. This was triggering an excess failure on rv32 targets
where it would try to run the zbc64 tests. Fix selector
Committed as obvious.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/crc-builtin-zbc32.c: Fi
Ping!
please review.
Thanks & Regards
Jeevitha
On 15/10/24 12:49 pm, jeevitha wrote:
> Hi All,
>
> Removed powerpc*-*-* from the target test as it is always true. Simplified
> options by removing -mpower9-misc and -mvsx, which are enabled by default with
> -mdeja
a target
> > version. Hence this check occasionally produces misdetections when build
> > and target differ. In some cases such as cygming, the header is only
> > installed after performing the build. Instead of resolving these
> > situations by guessing, defer the test to the ti
gming, the header is only
installed after performing the build. Instead of resolving these
situations by guessing, defer the test to the time of use and check for
the header using __has_include_next which will use the correct include
search path.
2024-04-30 Helmut Grohne
PR bootstrap/
libstdc++-v3/ChangeLog:
* testsuite/20_util/headers/utility/synopsis.cc: Add
declarations from C++11 and later.
---
It's a bit messy with all the macros, but I think it's still better to
have one test that runs as every -std mode than having 4+ tests that are
only valid
On Wed, Nov 20, 2024 at 08:02:34PM +0800, Cui, Lili wrote:
> PR target/116675
> * gcc.target/i386/pr116675.c: New test.
The test uses dg-do run and scan-assembler* at the same time,
that obviously doesn't work when pr116675.s isn't created at all,
so one gets
PASS:
On Thu, Nov 28, 2024 at 12:22 PM Jennifer Schmitz wrote:
>
> The test gcc.dg/tree-ssa/pow_fold_1.c was failing for 32-bit x86 due to
> incompatibility of '-fexcess-precision=16' with '-mfpmath=387'.
> In order to resolve this, this patch adds -msse -mfpmath=sse+38
On Thu, Nov 28, 2024 at 11:20:31AM +, Jennifer Schmitz wrote:
> The test gcc.dg/tree-ssa/pow_fold_1.c was failing for 32-bit x86 due to
> incompatibility of '-fexcess-precision=16' with '-mfpmath=387'.
> In order to resolve this, this patch adds -msse -mfpmath=
The test gcc.dg/tree-ssa/pow_fold_1.c was failing for 32-bit x86 due to
incompatibility of '-fexcess-precision=16' with '-mfpmath=387'.
In order to resolve this, this patch adds -msse -mfpmath=sse+387 for i?86-*-*.
We tested this by running the test on an x86_64 machine with
libstdc++-v3/ChangeLog:
PR libstdc++/117751
* testsuite/18_support/50594.cc: Edit dg-options to include the
-fno-assume-sane-operators-new-delete option.
---
Tested x86_64-linux. Pushed to trunk.
I checked the other tests that replace operator new and operator delete,
but
On 2024-11-26 16:33, Christophe Lyon wrote:
On 11/26/24 13:42, Torbjörn SVENSSON wrote:
Hi,
Sorry for the mess. I'm not sure how I managed to miss this...
Maybe I tested the GCC15 binaries on the GCC14 test tree.
Anyway, here is a fix that uses the assembler generated in GCC14.
The
On 11/26/24 13:42, Torbjörn SVENSSON wrote:
Hi,
Sorry for the mess. I'm not sure how I managed to miss this...
Maybe I tested the GCC15 binaries on the GCC14 test tree.
Anyway, here is a fix that uses the assembler generated in GCC14.
The csinc instruction was introduced in r15
Ping!
please review.
Thanks & Regards
Jeevitha
On 15/10/24 12:49 pm, jeevitha wrote:
> Hi All,
>
> Removed powerpc*-*-* from the target test as it is always true. Simplified
> options by removing -mpower9-misc and -mvsx, which are enabled by default with
> -mdeja
Hi,
Sorry for the mess. I'm not sure how I managed to miss this...
Maybe I tested the GCC15 binaries on the GCC14 test tree.
Anyway, here is a fix that uses the assembler generated in GCC14.
The csinc instruction was introduced in r15-1579-g792f97b44ff that
was not backported.
Ok for rel
On Fri, Nov 22, 2024 at 4:08 PM Haochen Jiang wrote:
>
> Hi all,
>
> Under FP8, we should not use AVX512F_LEN_HALF to get the mask size since
> it will get 16 instead of 8 and drop into wrong if condition. Correct
> the usage for vcvtneph2[b,h]f8[,s] runtime test.
>
>
1 - 100 of 1754 matches
Mail list logo
