https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111322
--- Comment #2 from Chris Packham ---
I don't disagree but it appears to have been that way for some time. There are
other instances of the __GLIBC__ && !__UCLIBC__ in other corners
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111322
Bug ID: 111322
Summary: non-canonical reference to canonical protected
function `__pthread_key_create'
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057
--- Comment #5 from Chris Packham ---
Created attachment 55751
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55751=edit
Remove crypt and crypt_r interceptors
Attached is the patch derived from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057
--- Comment #4 from Chris Packham ---
(In reply to Andrew Pinski from comment #1)
> What version of glibc is being built with here?
glibc-2.38
> Most likely could backport:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057
Bug ID: 111057
Summary: build error:
libsanitizer/sanitizer_common/sanitizer_platform_limit
s_posix.cpp:180:10: fatal error: crypt.h: No such file
or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #13 from Chris Packham ---
(In reply to Xi Ruoyao from comment #12)
> Please provide info about how libsanitizer end up building with GCC 11.3 and
> MIPS64 (such a combination is not supported and libsanitizer should not be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607
--- Comment #10 from Chris Packham ---
I don't know if it helps at all but it looks like we actually noticed the
difference between GCC 10 and GCC 11. The workaround we have in ct-ng was GCC
11 specific.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #8 from Chris Packham ---
In terms of my proposed change which fixes the problem for GCC 11.3.0 it
actually triggers the same assert on GCC 12.1.0.
[ALL ]In file included from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #5 from Chris Packham ---
Upstream issue raised https://github.com/llvm/llvm-project/issues/55499 I still
think there's some work on the GCC side required as even without this specific
issue things have diverged.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #3 from Chris Packham ---
It looks like upstream has moved to FIRST_32_SECOND_64(160, 216) somewhere
along the line. According to my reading of the linux source code this is wrong
for both bitnesses now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #2 from Chris Packham ---
Created attachment 52984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52984=edit
Set struct_kernel_stat_sz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
Bug ID: 105614
Summary: mips64: sanitizer_platform_limits_linux.cpp:75:38:
error: static assertion failed
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607
--- Comment #9 from Chris Packham ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Chris Packham from comment #7)
> > There's also
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=081c9dfb67a0d2e7425ddb5420ada588026f92ca
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607
--- Comment #7 from Chris Packham ---
There's also
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=081c9dfb67a0d2e7425ddb5420ada588026f92ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607
--- Comment #6 from Chris Packham ---
Here's the relevant snippet from the log.
CC_FOR_BUILD='x86_64-build_pc-linux-gnu-gcc' CFLAGS='-O2 -g
-I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/include
'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607
--- Comment #3 from Chris Packham ---
Just blindly comparing log files between a good and a bad build the `-mb -m1`
combination appears to be new and is the one causing problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607
--- Comment #2 from Chris Packham ---
binutils is the same but I did update the kernel headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607
Bug ID: 105607
Summary: sh-unknown-elf: Error: opcode not valid for this cpu
variant
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104090
Chris Packham changed:
What|Removed |Added
CC||judge.packham at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104673
Chris Packham changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104673
--- Comment #3 from Chris Packham ---
Created attachment 52511
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52511=edit
Attempt to trigger problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104673
--- Comment #2 from Chris Packham ---
GCC configure line is
$ /home/ctng/crosstool-ng/.build/powerpc-unknown-linux-gnu/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=powerpc-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104673
Bug ID: 104673
Summary: powerpc e500mc Error: unrecognized opcode: `isel'
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101115
--- Comment #3 from Chris Packham ---
An update[1]. It seems that --disable-tm-clone-registry is the option that
results in crtbegin.o having a zero sized .init_array. I can't really follow
crcstuff.c but I see USE_TM_CLONE_REGISTRY in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101115
--- Comment #2 from Chris Packham ---
(In reply to Andrew Pinski from comment #1)
> Try adding --enable-initfini-array to gcc config
>
> Most likely GCC config is not detecting .init_array/.fini_array support
> which is now always turned on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101115
Bug ID: 101115
Summary: ld.bfd: warning: .init_array section has zero size
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
26 matches
Mail list logo
