[Bug d/88462] All D execution tests FAIL on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #10 from Johannes Pfau --- I guess the proper fix to the alignment problem is using 'https://dlang.org/phobos/std_traits.html#classInstanceAlignment' (or rather the druntime equivalent) instead of Mutex.alignof + the rounding / slice assignment fixes? Regarding the ModuleInfo problem: Although ModuleInfo does have a variable size, _flags ist the first field in the struct. So the whole struct instance has to be misaligned for some reason? Is the minfo section aligned properly?
[Bug testsuite/88041] gdc.test tests should include that prefix in test names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #5 from Johannes Pfau --- For reference, this makes running the testsuite on windows/msys2 hosts somewhat more complicated: On these systems, ln -s is implemented by copying SRC to DST instead of creating proper links [1]. (I'm not sure whether the TCL file link command actually calls ln on MSYS2, but it seems to do so, as the observed effect is just this: a copy of the directory). It is possible to configure MSYS2 to use proper NTFS symlinks instead [2], but then running the testuite will always require administrator privileges on older windows versions. On newer windows versions, mklink can now be used as normal user iff the windows developer mode is enabled [3]. However, the ln shipped with MSYS2 does not yet make use of this feature[4]. Not sure if this really is a problem or if there's a better solution. For now, configuring ln to use windows symlinks and building gcc as admin should work. An alternative is to just manually create that one symlink. The best solution is probably to just use a cross-compiler for testing and build on linux ;-) [1] https://sourceforge.net/p/msys2/tickets/41/ [2] https://www.joshkel.com/2018/01/18/symlinks-in-windows/ [3] https://www.wintellect.com/non-admin-users-can-now-create-symlinks-windows-10/ [4] https://github.com/Alexpux/MSYS2-packages/issues/1219
[Bug d/88150] Use sections_elf_shared.d on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150 Johannes Pfau changed: What|Removed |Added CC||code at dawg dot eu, ||johannespfau at gmail dot com --- Comment #8 from Johannes Pfau --- Regarding the _d_dso_registry issue: Yes, as far as I can see it is a bug that handleForName dlcloses the handle here. I think what happened is this: handleForName is used in one place with the comment // get handle without loading the library so it is supposed to unload the library there. But it is also called from handleForAddr which is used to get the DSO handle to be stored using setDSOForHandle. I think here, it's not really valid to store the closed handle. Let's ping the expert here though, I've added Martin Nowak to CC.
[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #7 from Johannes Pfau --- > The Minfo_Bracketing assert in sections_elf_shared.d fails now, of > course, but the file is usable even without linker-provided > bracketing. Should this go completely? I think the assert should go, it doesn't belong there anyway. Minfo_Bracketing is unused then, AFAICS, so it should be fine to also remove it from gcc/config.d. Other changes look fine.
[Bug d/88127] Many gdc.dg testsuite failures due to undefined reference to qsort_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88127 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #1 from Johannes Pfau --- Upstream PR: https://github.com/dlang/druntime/pull/2480
[Bug d/88040] gdc silently ignores -ffile-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88040 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #2 from Johannes Pfau --- I don't think -fmodule-file= can be used for this: AFAICS it only applies to single files, so it's inconvenient when a complete directory needs to be remapped. There's also a conceptual difference: -fmodule-file= is used to tell the compiler where to find a file, if the normal module=>filename algorithm can't find the file in the -I paths. -ffile-prefix-map is used if files can be found just fine using the normal module=>filename algorithm in the -I path, but you want the paths recorded in debug info, __FILE_FULL_PATH__ and so on to be different.
[Bug d/89177] unaligned memory access in libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #2 from Johannes Pfau --- Thanks for the bug report & patch. It seems upstream phobos has already fixed this in a different way: https://github.com/dlang/phobos/commit/d5f710c57e717ef470d093c1739156dcb2f2d469#diff-2f532fcf37a0e29f7683a930ad9915ae Could you please try whether simply replacing the murmurhash.d file with this latest upstream version works? https://raw.githubusercontent.com/dlang/phobos/master/std/digest/murmurhash.d It looks like there have been no compiler-dependent changes to murmurhash.d, so this latest version likely works. Otherwise we could use the first version including the bugfix (https://github.com/dlang/phobos/blob/d5f710c57e717ef470d093c1739156dcb2f2d469/std/digest/murmurhash.d) or backport the bugfix.
[Bug d/89177] unaligned memory access in libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177 --- Comment #5 from Johannes Pfau --- OK, thanks for testing. I'll post a patch to the ML this evening.
[Bug d/89177] unaligned memory access in libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177 --- Comment #6 from Johannes Pfau --- Patch posted here: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01897.html
[Bug d/87824] x86_64-linux multilib issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #5 from Johannes Pfau --- Iain, is there a specific reason why we don't have i686 on the GDC/buildkite CI? We could simply run a QEMU/KVM VM on a x86_64 host for this. And when running the testsuite on multilib, is it now running all tests (test suite and druntime, phobos) for all multilib variants? I think last time I checked, multilib testing tested only the main variant for some reason.
[Bug d/87824] x86_64-linux multilib issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824 --- Comment #8 from Johannes Pfau --- Thanks to both of you for the advice. So we should probably enable 32bit multilib testing on semaphore or buildkite then. Back to this bug report: - FAIL: libphobos.shared/loadDR.c -ldl -pthread -g execution test - This is fortunately only a test-setup problem: - set libphobos_run_args "$objdir/../src/.libs/libgphobos.so" - https://github.com/D-Programming-GDC/GDC/blob/stable/libphobos/testsuite/libphobos.shared/shared.exp#L97 This references the wrong library ([...]/objdir/x86_64-pc-linux-gnu/libphobos/testsuite/../src/.libs/libgphobos.so) for multilib builds. I guess there should be some variable which properly considers the multilib setup?
[Bug d/87824] x86_64-linux multilib issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824 --- Comment #9 from Johannes Pfau --- Fix for the loadDR failure: https://github.com/D-Programming-GDC/GDC/pull/767
[Bug middle-end/60214] New: Variables with same DECL_ASSEMBLER_NAME are treated as different variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60214
Bug ID: 60214
Summary: Variables with same DECL_ASSEMBLER_NAME are treated as
different variables
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: johannespfau at gmail dot com
This bug was first found in GDC, the D frontend for GCC, but it's also
reproducable with GCC. Consider the following test case:
int test9_1 asm ("test_эльфийские_письмена_9") = 0;
extern int test9_1_e asm ("test_эльфийские_письмена_9");
int main()
{
test9_1 = 42;
return test9_1_e == 42;
}
compile on ARM with 'gcc -O2 test.c' and run the test program. It returns '0',
indicating test9_1_e is not 42. It works on ARM without optimization and on
x86_64 with or without optimization. I'm not sure if this is ARM specific or
only specific to architectures with section anchors. 'gcc -O2 test.c
-fno-section-anchors' works as expected.
What happens is that the first store to test9_1 is moved after the read from
test9_1_e.
I guess it's suspicious that test9_1_e is read directly from
test_эльфийские_письмена_9 but the store to test9_1 evolves a section anchor.
Here's the relevant generated ASM:
ldrr2, .L2
ldrr3, .L2+4
ldrr0, [r2]
movr2, #42
subsr1, r0, r2
rsbsr0, r1, #0
adcsr0, r0, r1
strr2, [r3]
bxlr
[...]
.wordtest_эльфийские_письмена_9
.word.LANCHOR0
[...]
.LANCHOR0 = . + 0
.typetest_эльфийские_письмена_9, %object
.sizetest_эльфийские_письмена_9, 4
test_эльфийские_письмена_9:
.space4
In case the C code is invalid / unspecified please advise how we could get the
desired behaviour for the GDC frontend. Currently we emit the VAR_DECLS in the
same way as without the 'asm ("test_эльфийские_письмена_9")' part except we set
DECL_ASSEMBLER_NAME accordingly.
[Bug middle-end/60214] Variables with same DECL_ASSEMBLER_NAME are treated as different variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60214 --- Comment #1 from Johannes Pfau --- Sorry, I forgot to add that this only happens if the test9_1 variable has got an initializer. However this is almost always the case for GDC/D as we have default initialization.
[Bug other/60240] New: libbacktrace problems with nested functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60240
Bug ID: 60240
Summary: libbacktrace problems with nested functions
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: johannespfau at gmail dot com
Created attachment 32152
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32152&action=edit
test case to reproduce the bug
Compile the test case with "-lbacktrace -g".
Actual output:
test.c:17 (null)
Expected output: The backtrace should contain the function name ('a') instead
of null.
AFAICS the problem is in read_function_entry. There's a "abbrev->has_children"
check that assumes all children of a function are inlined instances of the same
function. This is not true, children can also be nested functions. libbacktrace
should check the "DW_AT_inline" tag here.
[Bug rtl-optimization/49054] useless cmp+jmp generated for switch when "default:" is unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #5 from Johannes Pfau --- This would also be useful for the GDC frontend. There's a `final switch` statement which forces the developer to handle all possible cases. Would be nice if we could get rid of the `cmp` check for these `final switch` statements.
