[Bug d/113125] New: [D] internal compiler error: in make_import, at d/imports.cc:48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113125 Bug ID: 113125 Summary: [D] internal compiler error: in make_import, at d/imports.cc:48 Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- Debian testing, amd64, gcc version 13.2.0 (Debian 13.2.0-7) meta.d: ``` module objc.meta; struct A; ``` runtime.d: ``` module objc.runtime; public import meta : A; ``` gdc -v -c -I. runtime.d ``` $ gdc -v -c -I. runtime.d Using built-in specs. COLLECT_GCC=gdc OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-7' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=3 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (Debian 13.2.0-7) COLLECT_GCC_OPTIONS='-v' '-c' '-I' '.' '-o' 'runtime.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-linux-gnu/13/d21 runtime.d -quiet -dumpbase runtime.d -dumpbase-ext .d -mtune=generic -march=x86-64 -version -imultiarch x86_64-linux-gnu -I . -v -o /tmp/ccPyiN0m.s GNU D (Debian 13.2.0-7) version 13.2.0 (x86_64-linux-gnu) compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 binary/usr/libexec/gcc/x86_64-linux-gnu/13/d21 version v2.103.1 predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown GNU_InlineAsm D_LP64 D_PIC D_PIE assert D_PreConditions D_PostConditions D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86_64 D_HardFloat Posix linux CRuntime_Glibc CppRuntime_Gcc parse runtime importall runtime importmeta (meta.d) importobject(/usr/lib/gcc/x86_64-linux-gnu/13/include/d/object.d) importcore.attribute (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/attribute.d) importgcc.attributes (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/gcc/attributes.d) importcore.internal.hash (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/hash.d) importcore.internal.traits (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/traits.d) importcore.internal.entrypoint (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/entrypoint.d) importcore.internal.array.appending (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/appending.d) importcore.internal.array.comparison (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/comparison.d) importcore.internal.array.equality (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/equality.d) importcore.internal.array.casting (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/casting.d) importcore.internal.array.concatenation (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/concatenation.d) importcore.internal.array.construction (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/construction.d) importcore.internal.array.arrayassign (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/arrayassign.d) importcore.internal.array.capacity (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/array/capacity.d) importcore.internal.dassert (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/internal/dassert.d) importcore.atomic (/usr/lib/gcc/x86_64-linux-gnu/13/include/d/core/atomic.d) importcore.internal.attributes
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #13 from Jiu Fu Guo --- (In reply to GCC Commits from comment #9) > The master branch has been updated by Hans-Peter Nilsson : > > https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0 > > commit r14-6817-g3d03630b123411340e52d05124cb0cacfa1fc8b0 > Author: Hans-Peter Nilsson > Date: Sun Dec 24 00:10:32 2023 +0100 > > CRIS: Fix PR middle-end/113109; "throw" failing > > TL;DR: the "dse1" pass removed the eh-return-address store. The > PA also marks its EH_RETURN_HANDLER_RTX as volatile, for the same > reason, as does visum. See PR32769 - it's the same thing on PA. > > Conceptually, it's logical that stores to incoming args are > optimized out on the return path or if no loads are seen - > at least before epilogue expansion, when the subsequent load > isn't seen in the RTL, as is the case for the "dse1" pass. The stores to the argp/frame can be eliminated only if they are not used. While for this case, the store may be used by EH handler, it should not be optimized out. Thanks for catching and handling this quickly. Happy holidays.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #12 from Hans-Peter Nilsson --- Writing and doing are different things...
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #11 from Hans-Peter Nilsson --- (In reply to Jiu Fu Guo from comment #8) > I'm wondering if we need to revert r14-6674 to avoid this functionality > issue. And revisit/enhance the patch later. No need, not anymore; not because of this PR anyway. I'm closing the bug, but please don't back-port that commit (or at least, please back-port this commit as well if you do). Happy holidays.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #10 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #6) > So I did a quick audit of the EH_RETURN_HANDLER_RTX Yeah, me too. > and most are registers > rather than a memory location . And the ones which were memory locations > used either frame or stack pointer directly which seemed to not to be > removed. And those that with an address relative to hard_frame_pointer_rtx, marks the mem as volatile. > I had originally was going to record my findings but then I saw the > volatile for pa risc and deleted what I had wrote up. Ouch, "never delete what you can't undo". Sometimes you turn back another 180 degrees from your 180 turn in the middle of the analysis or bug-hunt. Was it more than a list of targets and their EH macros and patterns? The fun thing is that the dse1 pass (the culprit) works before pro/epilogue expansion, so it sees stores without the matching loads. That is, for targets that just define EH_RETURN_HANDLER_RTX (no eh_return pattern or any fancy extra) and handles EH at epilogue expansion time.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #9 from GCC Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0 commit r14-6817-g3d03630b123411340e52d05124cb0cacfa1fc8b0 Author: Hans-Peter Nilsson Date: Sun Dec 24 00:10:32 2023 +0100 CRIS: Fix PR middle-end/113109; "throw" failing TL;DR: the "dse1" pass removed the eh-return-address store. The PA also marks its EH_RETURN_HANDLER_RTX as volatile, for the same reason, as does visum. See PR32769 - it's the same thing on PA. Conceptually, it's logical that stores to incoming args are optimized out on the return path or if no loads are seen - at least before epilogue expansion, when the subsequent load isn't seen in the RTL, as is the case for the "dse1" pass. I haven't looked into why this problem, that appeared for the PA already in 2007, was seen for CRIS only recently (with r14-6674-g4759383245ac97). PR middle-end/113109 * config/cris/cris.cc (cris_eh_return_handler_rtx): New function. * config/cris/cris-protos.h (cris_eh_return_handler_rtx): Prototype. * config/cris/cris.h (EH_RETURN_HANDLER_RTX): Redefine to call cris_eh_return_handler_rtx.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #8 from Jiu Fu Guo --- (In reply to Andrew Pinski from comment #6) > So I did a quick audit of the EH_RETURN_HANDLER_RTX and most are registers > rather than a memory location . And the ones which were memory locations > used either frame or stack pointer directly which seemed to not to be > removed. I had originally was going to record my findings but then I saw the > volatile for pa risc and deleted what I had wrote up. I'm wondering if we need to revert r14-6674 to avoid this functionality issue. And revisit/enhance the patch later.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #7 from Jiu Fu Guo --- (In reply to Hans-Peter Nilsson from comment #3) > > I'm "guessing" that the problem with the patch, is that anything any port > stores through a pointer based on virtual_incoming_args_rtx before > returning, is now eliminated. Oh, yes, this is a possible place where that patch does not handle well.
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 --- Comment #5 from Desmond Gold --- when I mentioned being "inspired by," I was referring to drawing guidance from existing reference implementations like libc++, STL, and Kokkos for the implementation in libstdc++. Specifically, for how they implement the preconditions and layout_stride. I apologize for not explicitly defining what I meant by "inspiration" earlier. However, it's important to note that my work primarily adheres to the standards' definitions rather than directly replicating code. This approach ensures alignment with the intended functionality while respecting authorship, copyright, and licensing concerns. >From the link you've checked out, you'll notice the implementation is still a work in progress. It's incomplete and would greatly benefit from additional feedback to incorporate the missing elements :>
' ] ' is displayed.
/* sprintf()関数 */
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
/* if (output_len >= 80)
{
fprintf(stderr, "Output string overflowed by %d characters.\n"
"The variables x, y, z and a may have been corrupted:\n"
"x now contains %f, y %f, z %f, and a %f.\n",
output_len - 79, x, y, z, a);
} */
}
' ] ' is displayed.
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
’ ] ' is displayed.
#include
int main(void)
{
char buffer[80];
double x = 1234.5, y = 678.9, z = -753.1, a = x * y + z;
int output_len = sprintf(buffer, "For the input values %f, %f, and %f,"
"\nthe result was %f.\n", x , y, z, a);
puts(buffer);
[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661 due to reassoc not handling maybe_undefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Decembe ||r/641368.html Keywords||patch --- Comment #12 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641368.html
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 --- Comment #4 from Andrew Pinski --- When you say C structures here you mean the standard layout types (or the C++98 older definition of PODs)? Or do you mean structure types which has no member functions/constructors at all?
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #6 from Andrew Pinski --- So I did a quick audit of the EH_RETURN_HANDLER_RTX and most are registers rather than a memory location . And the ones which were memory locations used either frame or stack pointer directly which seemed to not to be removed. I had originally was going to record my findings but then I saw the volatile for pa risc and deleted what I had wrote up.
[Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109 --- Comment #5 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #4) > Hmm, see PR 32398 and PR 32769. PR 32769 is interesting because it was > caused by the merge of the df branch where the store was being removed just > like here on cris. > > Oh and reading > https://inbox.sourceware.org/gcc-patches/200707151749.l6FHnXrt010084@hiauly1. > hia.nrc.ca/ (the patch submission for those two PR's) > even mentions this exact issue it seems where dse.cc is removing > the store and such. Thanks for the bug-archive-digging! I decided on trying making the mem volatile and I see PR32769 supports that; exactly the same thing! I just wonder why it was seen with pa *then* and CRIS only *now*.
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 --- Comment #3 from Andrew Pinski --- Is this a reasonable extension maybe. But this is an extension to the language after all.
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 --- Comment #2 from Alexey Dobriyan --- this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99081 but I don't care about the warning, only about error
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 --- Comment #1 from Alexey Dobriyan --- This is getting lengthy: Please allow C99 semantics for "simple enough" stuff (read: C structs): * allow reordering * allow duplicating (possibly with warning), * allow holes in the middle of arrays (1- and multi-dimensional). because a) clang++ can do it b) there is not reason no to (for simlpe structs) c) any C to C++ converter can claim that this part of conversion is correct at the moment of gcc/g++ flip without very painful reaudit of all initialisers.
[Bug c++/113124] New: g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
Bug ID: 113124
Summary: g++ should relax designated initialiser rules for
trivial classes (read: C structures) and C arrays.
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adobriyan at gmail dot com
Target Milestone: ---
Currently, the rules do not allow reordering member initialisation:
struct S {
int a;
int b;
};
S s{.b = 1, .a = 2}; // error
or skipping array element initialisation:
int a[2] = {[1] = 1}; // error
First, clang++ allows it with warnings which can be silenced.
Second, both restrictions are major problem for converting C projects to C++
if C99 initialisers are used often.
I have bootable Linux compiled with g++ and it became obvious that some changes
are such pain points:
1) implicit casts from void* to T*,
2) "broken" C99 initializers (which Linux uses a lot),
3) pointer arithmetic ("void* + int" and "void* - void*").
(1) and (3) happen _a_lot_ but they aren't a problem, because they aren't a
flag day, casts can be added little by little to any project willing to convert
to C++.
However, (2) is a flag day with g++, suddenly lot of stuff won't compile.
Fixing this requires giving up _nice_ C99 feature which people are used to.
As you all know, reodering struct members doesn't force to change all
initialisers.
But at the moment of doing gcc => g++ flip every single structure becomes
trivial class(?) and restrictions apply.
Linux is _full_ of these misordered initialisations:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/fops.c?h=v6.7-rc6#n838
(the order is .llseek, .read_iter, ...)
Arrays can be even more painful:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/mem.c?h=v6.7-rc6#n685
Note, that the last element is undef ifdef, so less space is wasted,
so giving this array size requires constexpr variable and duplicating ifdefs.
Sometimes it is not obvious which elements are reordeded or missing:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ethtool/common.c?h=v6.7-rc6#n11
Reordered C99 initialisers create problems with maintaining patchset.
Reapplying on top of new version may create some rejects, which are painful for
a human to fix: members can be added/deleted/reorders in main code and then
patch is reordering some members too, so duplicate initializations can appear
if done wrong,
or more importantly, some initializers can be lost (which is null function
pointer dereference somewhere). I've started to redo every initialisers from
scratch just to minimise about of breakage, otherwise it is very easy to miss
stuff.
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 --- Comment #4 from Jonathan Wakely --- What does "inspired by" mean? We need to be careful of authorship, copyright ownership, and licensing.
[Bug c++/112883] FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112883 --- Comment #2 from John David Anglin --- The excess errors differ.
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 Desmond Gold changed: What|Removed |Added CC||cooky.ykooc922 at gmail dot com --- Comment #3 from Desmond Gold --- I've implemented c++23 features for in libstdc++ (hopefully) which is inspired by other reference implementations (libc++, STL, Kokkos). https://godbolt.org/z/Gc8vvjaT9 however: + no optimizations yet (this includes SBO) + no 'stronger' and complete tests yet + no documentation yet + some assertions have no messages
[Bug sanitizer/113123] New: ASAN_OPTIONS=log_to_syslog=true leads to deadlock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113123
Bug ID: 113123
Summary: ASAN_OPTIONS=log_to_syslog=true leads to deadlock
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 56928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56928=edit
The backtrace as a separate file
I filled the same also at https://github.com/google/sanitizers/issues/1714.
I compile software on Fedora 39/ gcc 13.2.1 20231205 with
export CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer -fno-common
-fsanitize=undefined -fsanitize-recover=address"
export CXXFLAGS="-g -fsanitize=address -fno-omit-frame-pointer -fno-common
-fsanitize=undefined -fsanitize-recover=address"
then I set
ASAN_OPTIONS=log_to_syslog=true:log_path=/tmp/c-asan.log:halt_on_error=false:detect_leaks=0"
UBSAN_OPTIONS=log_to_syslog=true:log_path=/tmp/c-ubsan.log:print_stacktrace=1"
LSAN_OPTIONS=verbosity=1:log_threads=1"
and run the software. The software reaches deadlock. I connect to it with gdb.
Below is the full backtrace. I do not know where the ?? at the end come from,
as I have compiled the software with debug information. I cannot write simpler
software, which reproduces the problem.
In any case the software waits forever in the syslog-Futex call.
Can you find, based on the provided backtrace, the root cause for the deadlock?
#0 0x7f16584f3d9e in __sanitizer::FutexWait (p=0x7f1658a9b2e8
<__lsan::global_mutex+8>, cmp=0) at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cpp:730
No locals.
#1 0x7f16584f676a in __sanitizer::Semaphore::Wait (this=0x7f1658a9b2e8
<__lsan::global_mutex+8>) at
../../../../libsanitizer/sanitizer_common/sanitizer_mutex.cpp:35
count =
#2 0x7f165850dc40 in __sanitizer::Mutex::Lock (this=0x7f1658a9b2e0
<__lsan::global_mutex>) at
../../../../libsanitizer/sanitizer_common/sanitizer_mutex.h:196
new_state =
locked =
spin_iters =
reset_mask =
state =
reset_mask =
state =
spin_iters =
new_state =
locked =
#3 __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock
(mu=0x7f1658a9b2e0 <__lsan::global_mutex>, this=) at
../../../../libsanitizer/sanitizer_common/sanitizer_mutex.h:383
No locals.
#4 __lsan_register_root_region (begin=0x7f1653b003d0, size=16) at
../../../../libsanitizer/lsan/lsan_common.cpp:1005
l = {mu_ = 0x7f1658a9b2e0 <__lsan::global_mutex>}
region = {begin = 1, size = 139733947553115}
#5 0x7f16584d9408 in DlsymAlloc::OnAllocate (size=,
ptr=0x7f1653b003d0) at ../../../../libsanitizer/asan/asan_malloc_linux.cpp:39
No locals.
#6 __sanitizer::DlSymAllocator::Allocate (size_in_bytes=15) at
../../../../libsanitizer/sanitizer_common/sanitizer_allocator_dlsym.h:37
ptr = 0x7f1653b003d0
ptr =
v1 =
v2 =
#7 __interceptor_malloc (size=size@entry=15) at
../../../../libsanitizer/asan/asan_malloc_linux.cpp:67
stack = {<__sanitizer::StackTrace> = {trace = 0x7ffdf06a0150, size = 1,
tag = 0, static TAG_UNKNOWN = 0, static TAG_ALLOC = 1, static TAG_DEALLOC = 2,
static TAG_CUSTOM = 100}, trace_buffer = {18446744073709551240,
139733947481999, 140728636932448, 0 , 4, 140728636934472,
140728636936224, 139733954961979, 0, 155648, 154304, 154304, 4096, 0, 1,
155648, 1597440, 1595213, 1595213, 4096, 155648, 5, 1597440, 1916928, 1914033,
1914033, 4096}, top_frame_bp = 1597440}
v1 =
v2 =
#8 0x7f16556c361f in __GI___strdup (s=s@entry=0x7f16557c03e0
"/etc/localtime") at strdup.c:42
len = 15
new =
#9 0x7f16556ec1a9 in tzset_internal (always=) at
tzset.c:402
is_initialized = 1
tz = 0x7f16557c03e0 "/etc/localtime"
#10 0x7f16556ec3bb in __tz_convert (timer=1703339934,
use_localtime=use_localtime@entry=1, tp=tp@entry=0x7ffdf06a0a60) at tzset.c:577
leap_correction = 0
leap_extra_secs = 0
#11 0x7f16556ea664 in __localtime_r (t=t@entry=0x7ffdf06a0a38,
tp=tp@entry=0x7ffdf06a0a60) at localtime.c:30
No locals.
#12 0x7f165573183b in __vsyslog_internal (pri=14, fmt=0x7f16585351a9 "%s",
ap=ap@entry=0x7ffdf06a0f20, mode_flags=mode_flags@entry=0) at syslog.c:160
pid = 0
now_tm = {tm_sec = 0, tm_min = 0, tm_hour = 0, tm_mday = 0, tm_mon = 0,
tm_year = 0, tm_wday = 0, tm_yday = 0, tm_isdst = 0, tm_gmtoff = 0, tm_zone =
0x0}
has_ts =
__clframe = {__cancel_routine = 0x7f1655731730 ,
__cancel_arg = 0x7ffdf06a0a40, __do_it = 1, __cancel_type = }
timestamp = '\000'
now = 1703339934
[Bug target/113122] New: Assembler messages: Error: operand type mismatch for `movabs' / bad expression / invalid use of register with -fprofile -mcmodel=large -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113122
Bug ID: 113122
Summary: Assembler messages: Error: operand type mismatch for
`movabs' / bad expression / invalid use of register
with -fprofile -mcmodel=large -masm=intel
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Compiler output:
$ echo 'void foo(void) {}' > testcase.c
$ x86_64-pc-linux-gnu-gcc -fprofile -mcmodel=large -masm=intel testcase.c
-save-temps
a-testcase.s: Assembler messages:
a-testcase.s:14: Error: operand type mismatch for `movabs'
a-testcase.s:15: Error: bad expression
a-testcase.s:15: Error: invalid use of register
$ cat a-testcase.s
...
1: movabsq $mcount, %r10
call*%r10
...
It seems the Intel dialect variant is missing for generation of this statement.
[Bug tree-optimization/113105] Missing optimzation: fold `div(v, a) * b + rem(v, a)` to `div(v, a) * (b - a) + v`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113105
--- Comment #5 from XChy ---
(In reply to Jakub Jelinek from comment #4)
> So, e.g. on x86_64,
> unsigned int
> f1 (unsigned val)
> {
> return val / 10 * 16 + val % 10;
> }
>
> unsigned int
> f2 (unsigned val)
> {
> return val / 10 * 6 + val;
> }
>
> unsigned int
> f3 (unsigned val, unsigned a, unsigned b)
> {
> return val / a * b + val % a;
> }
>
> unsigned int
> f4 (unsigned val, unsigned a, unsigned b)
> {
> return val / a * (b - a) + val % a;
> }
>
> unsigned int
> f5 (unsigned val)
> {
> return val / 93 * 127 + val % 93;
> }
>
> unsigned int
> f6 (unsigned val)
> {
> return val / 93 * (127 - 93) + val;
> }
>
> f2, f3 and f5 are shorter compared to f1, f4 and f6 at -O2.
> With -Os, f3 is shorter than f4, while f1/f2 and f5/f6 are the same size
> (and also same number of insns there, perhaps f1 better than f2 as it uses
> shift rather than imul).
> So, this is really something that needs to take into account the machine
> specific expansion etc., isn't a clear winner all the time.
Thanks for your explanations! It's a good fold for those targets with expensive
cost on "v % a", but not for those cheap. I'm not a GCC developer, do you think
I should report to rtl-optimization?
And it seems that f6 has smaller size than f5 at -O2 in your example:
https://godbolt.org/z/PEWKfj1je
[Bug tree-optimization/113071] `((a == c) || (a == b)) ? a : b` is sometimes not optimized to `(a == c) ? c : b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113071 XChy changed: What|Removed |Added CC||xxs_chy at outlook dot com --- Comment #1 from XChy --- May the fold below is a more general one? (a == b | other_cond) ? a : b can be other_cond ? a : b Actually a == c in this example is irrelevant and can be replaced by any other condition.
[Bug tree-optimization/113119] ICE: verify_ssa failed: definition in block 18 does not dominate use in block 4 at -O1 with _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113119 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-12-23 --- Comment #3 from Jakub Jelinek --- Created attachment 56927 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56927=edit gcc14-pr113119.patch So far lightly tested patch. Fixes both testcases.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #4 from andysem at mail dot ru --- > It's mostly OK to mix code with -frtti and -fno-rtti, but sometimes it bites > you. Note that in this case, it is the standard library that is built with -frtti and the rest of the code is built with -fno-rtti. I.e. you *always* get this sort of mix when you specify -fno-rtti.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #3 from andysem at mail dot ru --- I think, a failing dynamic_cast would not be useful as this would make std::use_facet unusable with -fno-rtti. Re. ODR violation in the latest code, while it is true that the dynamic/static_cast is not reachable for the standard facets, it is still part of the function definition and the compiler is free to generate code that takes it into account. Note that the shortcuts for the standard facets are implemented with conditional if-constexpr, which will turn into regular ifs if libstdc++ is compiled in pre-C++17 mode. Which, I think, is the default, isn't it? I think, the ODR violation is still worth fixing.
[Bug libstdc++/113121] New: failed to load pendings for ‘std::__format::__do_vformat_to’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113121 Bug ID: 113121 Summary: failed to load pendings for ‘std::__format::__do_vformat_to’ Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: saifi.khan at nishan dot io Target Milestone: --- built and working with g++ (GCC) 14.0.0 20231222 (experimental). When I attempt to compile header unit of with the following command g++ -std=c++23 -v -g3 -fmodules-ts -x c++-system-header print errors out /opt/gcc/include/c++/14.0.0/print: In constructor ‘std::basic_format_arg<_Context>::basic_format_arg() [with _Context = std::basic_format_context, char>]’: /opt/gcc/include/c++/14.0.0/print:55:56: error: recursive lazy load 55 | vprint_nonunicode(FILE* __stream, string_view __fmt, format_args __args) |^~~ /opt/gcc/include/c++/14.0.0/print:55:56: fatal error: failed to load pendings for ‘std::__format::__do_vformat_to’ With an earlier build 20231217, I did not encounter any error while trying to compile the header unit, instead when i compile test code. Please see https://gcc.gnu.org/pipermail/gcc-help/2023-December/143109.html
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759 YunQiang Su changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from YunQiang Su --- It should be fixed now, and back ported to gcc13. And we may should add some more detections: 1. hwcap 2. getauxval(AT_PLATFORM) 3. more cpuinfo parsing
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by YunQiang Su : https://gcc.gnu.org/g:63df799074351e9b3ab90f5b3031ba2691385af8 commit r13-8175-g63df799074351e9b3ab90f5b3031ba2691385af8 Author: YunQiang Su Date: Tue Dec 19 07:36:52 2023 +0800 MIPS: Put the ret to the end of args of reconcat [PR112759] The function `reconcat` cannot append string(s) to NULL, as the concat process will stop at the first NULL. Let's always put the `ret` to the end, as it may be NULL. We keep use reconcat here, due to that reconcat can make it easier if we add more hardware features detecting, for example by hwcap. gcc/ PR target/112759 * config/mips/driver-native.cc (host_detect_local_cpu): Put the ret to the end of args of reconcat.
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759 --- Comment #7 from GCC Commits --- The master branch has been updated by YunQiang Su : https://gcc.gnu.org/g:384dbb0b4e751e6eb7ba3f9993a6cce466743926 commit r14-6811-g384dbb0b4e751e6eb7ba3f9993a6cce466743926 Author: YunQiang Su Date: Tue Dec 19 07:36:52 2023 +0800 MIPS: Put the ret to the end of args of reconcat [PR112759] The function `reconcat` cannot append string(s) to NULL, as the concat process will stop at the first NULL. Let's always put the `ret` to the end, as it may be NULL. We keep use reconcat here, due to that reconcat can make it easier if we add more hardware features detecting, for example by hwcap. gcc/ PR target/112759 * config/mips/driver-native.cc (host_detect_local_cpu): Put the ret to the end of args of reconcat.
