v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on Windows.
v2 -> v3:
Use alternative approach by having platform specific code in module.cc.
Truth table for the new expression:
c:\foo -> true
c:/foo -> true
/foo -> true
\foo -> true
c:foo
v1 -> v2:
Updated expression in bad-mapper-3.C
Ok for trunk?
---
Without the patch, the output for bad-mapper-3.C would be:
/src/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-3.C:2:1: error: unknown
Compiled Module Interface: no such module
As this line is unexpected, the test case would fail.
v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on Windows.
Ok for trunk?
-
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A:Foo' is treated as
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A:Foo' is treated as an absolute
path by the module loader and is likely not found.
Without this patch, the test case pr98944_c.C fails
Without this patch, the following error is reported on Windows:
In file included from t:\build\arm-none-eabi\include\c++\11.3.1\string:54,
from
t:\build\arm-none-eabi\include\c++\11.3.1\bits\locale_classes.h:40,
from
t:\build\arm-none-eabi\include\c++\11.3.1\b
Without the patch, the output for bad-mapper-3.C would be:
/src/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-3.C:2:1: error: unknown
Compiled Module Interface: no such module
As this line is unexpected, the test case would fail.
The same problem can also be seen for g++.dg/modules/bad-mapper-2.C.
In commit 081c96621da, the call to resize_reg_info() was moved before
the call to remove_scratches() and the latter one can increase the
number of regs and that would cause an out of bounds usage on the
reg_renumber global array.
Without this patch, the following testcase randomly fails with:
duri
When generating the makefile, make sure that the paths are quoted so
that a native Windows path works within Cygwin.
Without this patch, this error is reported by the DejaGNU test suite:
make: [T:\ccMf0kI3.mk:3: T:\ccGEvdDp.ltrans0.ltrans.o] Error 1 (ignored)
The generated makefile fragment with
For systems with HAVE_DOS_BASED_FILE_SYSTEM set, only override the
pointer if the backslash pattern matches.
Output without this patch:
.../gcc/testsuite/gcc.dg/cpp/pr71681-2.c:5:10: fatal error: a/t2.h: No such
file or directory
With patch applied, no output and the test case succeeds.
libcpp/
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementa
Depending on the DejaGNU board definition, the .gnu.sgstubs section
might be placed on different locations in order to suite the target.
With this patch, the start location of the section is overrideable
from the board definition with the fallback of the previously
hardcoded location.
gcc/testsuit
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementa
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementa
Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
enough to know if the execution will enter an endless loop, or if it
will give a meaningful result. As the execution test only work when
VMA and LMA are equal, make sure that this condition is met.
gcc/ChangeLog:
* doc/s
libstdc++-v3/testsuite:
* 20_util/bind/ref_neg.cc: Prune Windows paths too.
Co-Authored-By: Yvan ROUX
Signed-off-by: Torbjörn SVENSSON
---
libstdc++-v3/testsuite/20_util/bind/ref_neg.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/20_util
The ':' is reserved in filenames on Windows.
Can't find any specification for this, but when there is no filename
defined in the map file, GCC will replace the ':' with a '-' in the
generated filename for the module.
Without this patch, the test case failes with:
.../ben-1_a.C:4:8: error: failed t
When the mapper can't be executed, Windows report the error like:
.../bad-mapper-1.C: error: failed CreateProcess mapper 'this-will-not-work'
On Linux, the same error is reported this way:
.../bad-mapper-1.C: error: failed execvp mapper 'this-will-not-work'
This patch allows both output forms to
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-e
In the test cases, it's clearly written that intrinsics are not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By changing to dg-skip-if, the entire test case is omitted.
gcc/testsuite/ChangeLog:
The "RISC-V specific attributes" section should be at the same level
as "PowerPC-specific attributes".
gcc/ChangeLog:
* doc/sourcebuild.texi: Fix chapter level.
Signed-off-by: Torbjörn SVENSSON
---
gcc/doc/sourcebuild.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
For some test cases, it's required that the optional module mapper
"g++-mapper-server" is built. As the server is not required, the
test cases will fail if it can't be found.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_is_prog_name_available):
New.
* lib/targ
The cmse-15.c testcase fails at -Os because ICF means that we
generate
secure3:
b secure1
which is OK, but does not match the currently expected
secure3:
...
bx r[0-3]
gcc/testsuite/ChangeLog:
* gcc.target/arm/cmse/cmse-15.c: Align with -Os improvements.
Co-Au
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementa
Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
enough to know if the execution will enter an endless loop, or if it
will give a meaningful result. As the execution test only work when
VMA and LMA are equal, make sure that this condition is met.
2022-09-16 Torbjörn SVENSSON
In the test cases, it's clearly written that intrinsics is not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By changing to dg-skip-if, the entire test case is omitted.
gcc/testsuite/ChangeLog:
*
The linker script should not be prefixed with "-Wl," - it's not an
input file and does not interfere with the new dump output filename
strategy.
gcc/testsuite/ChangeLog:
* lib/gcc-defs.exp: Do not prefix linker script with "-Wl,".
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/lib
After moving the testglue in commit 9d503515cee, the jump to exit and
abort is too far for the 'b' instruction on Cortex-M0. As most of the
C code would generate a 'bl' instruction instead of a 'b'
instruction, lets do the same for the inline assembler.
The error seen without this patch:
/tmp/ccc
In the test case, it's clearly written that intrinsics is not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By chaning to dg-skip-if, the entire test case is omitted.
gcc/testsuite/ChangeLog:
* g
When the -fzero-call-used-regs command line option is used with an
unsupported value, indicate that it's a value problem instead of an
option problem.
Without the patch, the error is:
In file included from gcc/testsuite/c-c++-common/zero-scratch-regs-8.c:5:
gcc/testsuite/c-c++-common/zero-scratch-
Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
enough to know if the execution will enter an endless loop, or if it
will give a meaningful result. As the execution test only work when
VMA and LMA are equal, make sure that this condition is met.
2022-09-16 Torbjörn SVENSSON
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e89eb343528..be146855ed8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -641,6 +641,7 @@ YunQiang Su
-fzero-call-used-regs=all and -fzero-call-used-regs=all-gpr are not
supported on arm*. On arm-none-eabi, the testcases fails with:
sorry, unimplemented: '-fzero-call-used-regs' not supported on this target
2022-09-15 Torbjörn SVENSSON
gcc/testsuite/ChangeLog:
* c-c++-common/zero-sc
PR/95720
When the status wrapper is used, the gluefile need to be prefixed with
-Wl, in order for the test cases to have the dump files with the
expected names.
gcc/testsuite/ChangeLog:
* gcc/testsuite/lib/g++.exp: Moved gluefile block to after
flags have been prefixed for the t
When testing a cross toolchain outside the build tree, the binary name
for gcov is prefixed with the triplet.
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov.exp: Respect triplet when looking for gcov.
* gcc.misc-tests/gcov.exp: Likewise.
Signed-off-by: Torbjörn SVENSSON
---
gcc/te
When testing a cross toolchain outside the build tree, the binary name
for gcov is prefixed with the tripplet.
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov.exp: Respect tripplet when looking for gcov
* gcc.misc-tests/gcov.exp: Likewise
Signed-off-by: Torbjörn SVENSSON
---
gcc/te
35 matches
Mail list logo
