Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In tcwg_flang_build/main-aarch64, after:
| commit llvmorg-22-init-14086-g046ae8553606
| Author: Christopher Ferris <cferris1000(a)users.noreply.github.com>
| Date: Mon Nov 10 14:17:23 2025 -0800
|
| [scudo] Small cleanup of memory tagging code. (#166860)
|
| Make the systemSupportsMemoryTagging() function return even on system
| that don't support memory tagging. This avoids the need to always check
| if memory tagging is supported before calling th function.
| ... 5 lines of the commit log omitted.
Produces Failure:
| Results changed to
| # reset_artifacts:
| -10
| # true:
| 0
| # build_llvm -- clang;lld;flang;clang-tools-extra openmp :
| # FAILED
| # First few build errors in logs:
| # 00:10:20 ld.lld: error: undefined symbol: __cxa_guard_acquire
| # 00:10:20 ld.lld: error: undefined symbol: __cxa_guard_release
| # 00:10:20 clang++: error: linker command failed with exit code 1 (use -v to see invocation)
|
| From
| # reset_artifacts:
| -10
| # true:
| 0
| # build_llvm -- clang;lld;flang;clang-tools-extra openmp :
| 1
Used configuration :
tcwg_flang_build/main-aarch64
We track this bug report under https://linaro.atlassian.net/browse/LLVM-2115. Please let us know if you have a fix.
If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in
* https://ci.linaro.org/job/tcwg_flang_build--main-aarch64-build/6073/artifac…
The full lists of regressions and improvements as well as configure and make commands are in
* https://ci.linaro.org/job/tcwg_flang_build--main-aarch64-build/6073/artifac…
Current build : https://ci.linaro.org/job/tcwg_flang_build--main-aarch64-build/6073/artifac…
Reference build : https://ci.linaro.org/job/tcwg_flang_build--main-aarch64-build/6070/artifac…
Instruction to reproduce the build : https://gitlab.com/LinaroLtd/tcwg/ci/interesting-commits/-/raw/master/llvm/…
Full commit : https://github.com/llvm/llvm-project/commit/046ae855360614c5980d0ced0c55b5d…
On 2025-11-04 12:03, ci_notify(a)linaro.org wrote:
> Dear contributor,
>
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
>
> In gcc_check master-aarch64, after:
> | commit gcc-16-5025-g0013501e462
> | Author: Siddhesh Poyarekar <siddhesh(a)gotplt.org>
> | Date: Mon Nov 3 17:02:00 2025 -0600
> |
> | lto/122515: Fix archive offset types for i686
> |
> | On i686, offsets into object archives could be 64-bit, but they're
> | inconsistently treated across the lto, which may sometimes result in
> | truncation of those offsets for large archives.
> | ... 36 lines of the commit log omitted.
>
> Produces 3 regressions:
> |
> | regressions.sum:
> | Running gcc:gcc.dg/lto/lto.exp ...
> | UNRESOLVED: gcc.dg/lto/pr122515 c_lto_pr122515_0.o-c_lto_pr122515.a execute -flto=auto -ffat-lto-objects
> | UNRESOLVED: gcc.dg/lto/pr122515 c_lto_pr122515_0.o-c_lto_pr122515.a link -flto=auto -ffat-lto-objects
> | FAIL: gcc.dg/lto/pr122515, ar returned 1: /WORKSPACE/abe/builds/destdir/aarch64-unknown-linux-gnu/bin/gcc-ar: Cannot find plugin 'liblto_plugin.so'
>
> Used configuration :
> *CI config* tcwg_gcc_check master-aarch64
> *configure and test flags:* none, autodetected on aarch64-unknown-linux-gnu
>
> We track this bug report under https://linaro.atlassian.net/browse/GNU-1744. Please let us know if you have a fix.
>
> If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
>
> The information below contains the details of the failures, and the ways to reproduce a debug environment:
>
> You can find the failure logs in *.log.1.xz files in
> * https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/4333/artifac…
> The full lists of regressions and improvements as well as configure and make commands are in
> * https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/4333/artifac…
The Jenkins instance seems to be down. Is there another way to find out
how this was configured? ISTM that liblto_plugin.so may not have been
built.
Sid
Hi Linaro folks!
It seems that the system running the armv8l has a pretty old pascal
compiler. I checked the log and it seems that, with that compiler
version, using fpc -g will generate stabs information, rather than DWARF
information.
So in one sense, these regressions are expected, but more importantly,
you should take a look at updating the armv8l machine so that pascal
tests can continue working
On 10/23/25 10:42 AM, ci_notify(a)linaro.org wrote:
> Dear contributor,
>
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
>
> In gdb_check master-arm, after:
> | commit gdb-17-branchpoint-577-gbaeb632f1b7
> | Author: Guinevere Larsen <guinevere(a)redhat.com>
> | Date: Wed Jan 22 14:05:01 2025 -0300
> |
> | gdb: Remove stabs support from ELF files
> |
> | This commit makes it so that GDB won't read stabs information from ELF
> | files. If stabs is detected in an ELF file, the reader now warns the user
> | that stabs is not supported.
> | ... 6 lines of the commit log omitted.
>
> Produces 118 regressions:
> |
> | regressions.sum:
> | Running gdb:gdb.pascal/case-insensitive-symbols.exp ...
> | FAIL: gdb.pascal/case-insensitive-symbols.exp: gdb_breakpoint: set breakpoint at case-insensitive-symbols.pas:43
> | Running gdb:gdb.pascal/floats.exp ...
> | FAIL: gdb.pascal/floats.exp: Going to second breakpoint (the program is no longer running)
> | FAIL: gdb.pascal/floats.exp: Test sin(pi) is equal to 0
> | ... and 119 more
>
> Used configuration :
> *CI config* tcwg_gdb_check master-arm
> *configure and test flags:* none, autodetected on armv8l-unknown-linux-gnueabihf
>
> We track this bug report under https://linaro.atlassian.net/browse/GNU-1715. Please let us know if you have a fix.
>
> If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
>
> The information below contains the details of the failures, and the ways to reproduce a debug environment:
>
> You can find the failure logs in *.log.1.xz files in
> * https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/3112/artifact/ar…
> The full lists of regressions and improvements as well as configure and make commands are in
> * https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/3112/artifact/ar…
> The list of [ignored] baseline and flaky failures are in
> * https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/3112/artifact/ar…
>
> Current build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/3112/artifact/ar…
> Reference build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/3111/artifact/ar…
>
> Instruction to reproduce the build : https://gitlab.com/LinaroLtd/tcwg/ci/interesting-commits/-/raw/master/gdb/s…
>
> Full commit : https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=baeb632f1b7ce…
--
Cheers,
Guinevere Larsen
It/she
On Tue, Oct 28, 2025 at 12:07 PM <ci_notify(a)linaro.org> wrote:
>
> Dear contributor,
>
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
>
> In gcc_check master-aarch64, after:
> | commit gcc-16-4667-gdcf69bdcd49
> | Author: H.J. Lu <hjl.tools(a)gmail.com>
> | Date: Sun Oct 26 08:42:20 2025 +0800
> |
> | c: Try the type with the previous function attributes
> |
> | When there are 2 conflicting function declarations, try the new type
> | with the previous TYPE_ATTRIBUTES if the current declaration has no
> | TYPE_ATTRIBUTES to support
> | ... 44 lines of the commit log omitted.
>
> Produces 19 regressions:
> |
> | regressions.sum:
> | Running gcc:gcc.target/aarch64/sme/aarch64-sme.exp ...
> | FAIL: gcc.target/aarch64/sme/streaming_mode_1.c (test for errors, line 10)
> | FAIL: gcc.target/aarch64/sme/streaming_mode_1.c (test for errors, line 121)
> | FAIL: gcc.target/aarch64/sme/streaming_mode_1.c (test for errors, line 16)
> | FAIL: gcc.target/aarch64/sme/streaming_mode_1.c (test for errors, line 30)
> | ... and 15 more
>
After
commit dcf69bdcd49bccd901bfb01db7c15530e9a70dc0
Author: H.J. Lu <hjl.tools(a)gmail.com>
Date: Sun Oct 26 08:42:20 2025 +0800
c: Try the type with the previous function attributes
gcc no longer issues an error for:
void sc_c () [[arm::streaming_compatible]];
void sc_c () {}
Instead, the previous type attributes are applied to the current function
definition. The resulting function definition is compatible with the
previous declaration.
PR c/122427
* gcc.target/aarch64/sme/streaming_mode_1.c: Remove dg-error.
--
H.J.
On Wed, 29 Oct 2025 at 22:04, <ci_notify(a)linaro.org> wrote:
>
> Dear contributor,
>
> Our automatic CI has detected problems related to your patch(es). Please find some details below.
>
> In gcc_check master-aarch64, after:
> | commit gcc-16-4709-gc55c1de3a9a
> | Author: Jonathan Wakely <jwakely(a)redhat.com>
> | Date: Tue Oct 28 12:15:52 2025 +0000
> |
> | libstdc++: Simplify std::regex_traits::value
> |
> | We don't need to use an istringstream to convert a hex digit to its
> | numerical value. And if we don't use istringstream there, we don't need
> | to include <sstream> in <regex>.
> | ... 8 lines of the commit log omitted.
>
> Produces 3 regressions:
> |
> | regressions.sum:
> | Running g++:g++.dg/dg.exp ...
> | FAIL: g++.dg/warn/uninit-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)
>
> Used configuration :
> *CI config* tcwg_gcc_check master-aarch64
> *configure and test flags:* none, autodetected on aarch64-unknown-linux-gnu
>
> We track this bug report under https://linaro.atlassian.net/browse/GNU-1735. Please let us know if you have a fix.
>
> If you have any questions regarding this report, please ask on linaro-toolchain(a)lists.linaro.org mailing list.
Fixed at r16-4714-gcc78f8523832d6
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
>
> The information below contains the details of the failures, and the ways to reproduce a debug environment:
>
> You can find the failure logs in *.log.1.xz files in
> * https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/4300/artifac…
> The full lists of regressions and improvements as well as configure and make commands are in
> * https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/4300/artifac…
> The list of [ignored] baseline and flaky failures are in
> * https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/4300/artifac…
>
> Current build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/4300/artifac…
> Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/4299/artifac…
>
> Instruction to reproduce the build : https://gitlab.com/LinaroLtd/tcwg/ci/interesting-commits/-/raw/master/gcc/s…
>
> Full commit : See in git+ssh://linaroci@gcc.gnu.org/git/gcc.git
Hi folks,
I have a strong suspicion that this bot has an incremental build issue
right now.
Can someone trigger a clean build please?
Thanks!
Mehdi
---------- Forwarded message ---------
From: <llvm.buildmaster(a)lab.llvm.org>
Date: Tue, Oct 28, 2025 at 12:51 AM
Subject: ☠ Buildbot (LLVM Buildbot): flang-arm64-windows-msvc - failed
build (failure) (main)
To: Mehdi Amini <joker.eph(a)gmail.com>
Cc: <llvm.buildmaster(a)lab.llvm.org>
The Buildbot has detected a new failure on builder flang-arm64-windows-msvc
while building flang,mlir.
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/207/builds/9096
Worker for this Build: linaro-armv8-windows-msvc-01
Blamelist:
Mehdi Amini <joker.eph(a)gmail.com>
BUILD FAILED: failed build (failure)
Step 5 (build-unified-tree) failure: build (failure)
...
359 | return {APFloat(*smt, value.real()), APFloat(*smt,
value.imag())};
| ^
c:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\complex(1315,5):
note: 'complex' has been explicitly marked deprecated here
1315 | _DEPRECATE_NONFLOATING_COMPLEX
| ^
c:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\yvals_core.h(1450,7):
note: expanded from macro '_DEPRECATE_NONFLOATING_COMPLEX'
1450 | [[deprecated("warning STL4037: "
\
| ^
1 warning generated.
84.583 [1719/10/276] Building CXX object
tools/mlir/lib/Dialect/MemRef/IR/CMakeFiles/obj.MLIRMemRefDialect.dir/MemRefDialect.cpp.obj
FAILED:
tools/mlir/lib/Dialect/MemRef/IR/CMakeFiles/obj.MLIRMemRefDialect.dir/MemRefDialect.cpp.obj
C:\Users\tcwg\scoop\shims\ccache.exe
C:\Users\tcwg\scoop\apps\llvm-arm64\current\bin\clang-cl.exe /nologo -TP
-DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE
-D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE
-D_CRT_SECURE_NO_WARNINGS -D_GLIBCXX_ASSERTIONS -D_HAS_EXCEPTIONS=0
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/tools/mlir/lib/Dialect/MemRef/IR
-IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/lib/Dialect/MemRef/IR
-IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/tools/mlir/include
-IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include
-IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/include
-IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/llvm/include
/DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj
/permissive- -Werr
or=unguarded-availability-new /W4 -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers
-Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override
-Wstring-conversion -Wno-pass-failed -Wmisleading-indentation
-Wctad-maybe-unsupported /Gw -Wundef -Werror=mismatched-tags
-Werror=global-constructors /O2 /Ob2 -std:c++17 -MD /EHs-c- /GR- -UNDEBUG
/showIncludes
/Fotools/mlir/lib/Dialect/MemRef/IR/CMakeFiles/obj.MLIRMemRefDialect.dir/MemRefDialect.cpp.obj
/Fdtools\mlir\lib\Dialect\MemRef\IR\CMakeFiles\obj.MLIRMemRefDialect.dir\
-c --
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/lib/Dialect/MemRef/IR/MemRefDialect.cpp
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/lib/Dialect/MemRef/IR/MemRefDialect.cpp:9:
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/Conversion/ConvertToEmitC/ToEmitCInterface.h:14:
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/IR/OpDefinition.h:22:
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/IR/Dialect.h:17:
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/IR/OperationSupport.h:19:
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/IR/BuiltinAttributes.h(359,14):
warning: 'complex' is deprecated: warning STL4037: The effect of
instantiating the template std::complex for any type other than float,
double, or long double is unspecified. You can define
_SILENCE_NONFLOATING_COMPLEX_DEPRECATION_WARNING to suppress this warning.
[-Wdeprecated-declarations]
359 | return {APFloat(*smt, value.real()), APFloat(*smt,
value.imag())};
| ^
c:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\complex(1315,5):
note: 'complex' has been explicitly marked deprecated here
1315 | _DEPRECATE_NONFLOATING_COMPLEX
| ^
c:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include\yvals_core.h(1450,7):
note: expanded from macro '_DEPRECATE_NONFLOATING_COMPLEX'
1450 | [[deprecated("warning STL4037: "
\
| ^
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/lib/Dialect/MemRef/IR/MemRefDialect.cpp:12:
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/Dialect/MemRef/IR/MemRef.h:13:
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/Dialect/Arith/IR/Arith.h:17:
In file included from
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/Interfaces/ControlFlowInterfaces.h:371:
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/tools/mlir/include\mlir/Interfaces/ControlFlowInterfaces.h.inc(1118,84):
error: no viable conversion from '::mlir::RegionSuccessor' to
'::mlir::RegionBranchPoint'
1118 | return
(llvm::cast<ConcreteOp>(tablegen_opaque_val)).getMutableSuccessorOperands(point);
|
^~~~~
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/tools/mlir/include\mlir/Interfaces/ControlFlowInterfaces.h.inc(435,23):
note: in instantiation of member function
'mlir::detail::RegionBranchTerminatorOpInterfaceInterfaceTraits::Model<mlir::memref::AtomicYieldOp>::getMutableSuccessorOperands'
requested here
435 | Model() : Concept{getMutableSuccessorOperands,
getSuccessorRegions} {}
| ^
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/Support/InterfaceSupport.h(238,46):
note: in instantiation of member function
'mlir::detail::RegionBranchTerminatorOpInterfaceInterfaceTraits::Model<mlir::memref::AtomicYieldOp>::Model'
requested here
238 | new (malloc(sizeof(InterfaceModel))) InterfaceModel();
| ^
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/Support/InterfaceSupport.h(225,7):
note: in instantiation of function template specialization
'mlir::detail::InterfaceMap::insertModel<mlir::detail::RegionBranchTerminatorOpInterfaceInterfaceTraits::Model<mlir::memref::AtomicYieldOp>>'
requested here
225 | insertModel<typename T::ModelT>();
| ^
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/Support/InterfaceSupport.h(199,10):
note: in instantiation of function template specialization
'mlir::detail::InterfaceMap::insertPotentialInterface<mlir::RegionBranchTerminatorOpInterface::Trait<mlir::memref::AtomicYieldOp>>'
requested here
199 | (map.insertPotentialInterface<Types>(), ...);
| ^
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/IR/OpDefinition.h(1877,43):
note: in instantiation of function template specialization
'mlir::detail::InterfaceMap::get<mlir::OpTrait::ZeroRegions<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::ZeroResults<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::ZeroSuccessors<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::OneOperand<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::HasParent<mlir::memref::GenericAtomicRMWOp>::Impl<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::OpInvariants<mlir::memref::AtomicYieldOp>,
mlir::ConditionallySpeculatable::Trait<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::AlwaysSpeculatableImplTrait<mlir::memref::AtomicYieldOp>,
mlir::MemoryEffectOpInterface::Trait<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::IsTerminator<mlir::memref::AtomicYieldOp>,
mlir::RegionBranchTerminatorOpInterface::Trait<mlir::memref::AtomicYieldOp>,
mlir::OpTrait::ReturnLike<mlir::memref::AtomicYieldOp>>' requested he
re
1877 | return detail::InterfaceMap::template
get<Traits<ConcreteType>...>();
| ^
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/mlir/include\mlir/IR/OperationSupport.h(533,55):
note: in instantiation of member function
'mlir::Op<mlir::memref::AtomicYieldOp, mlir::OpTrait::ZeroRegions,
mlir::OpTrait::ZeroResults, mlir::OpTrait::ZeroSuccessors,
mlir::OpTrait::OneOperand,
mlir::OpTrait::HasParent<mlir::memref::GenericAtomicRMWOp>::Impl,
mlir::OpTrait::OpInvariants, mlir::ConditionallySpeculatable::Trait,
mlir::OpTrait::AlwaysSpeculatableImplTrait,
mlir::MemoryEffectOpInterface::Trait, mlir::OpTrait::IsTerminator,
mlir::RegionBranchTerminatorOpInterface::Trait,
mlir::OpTrait::ReturnLike>::getInterfaceMap' requested here
Sincerely,
LLVM Buildbot