https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118725
--- Comment #5 from Chris Packham ---
I'll add that it seems to only happen with gettext-0.23.1. If I pin the config
to use gettext-0.22.5 the build succeeds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118725
--- Comment #4 from Chris Packham ---
> How was libintl built?
> Did you build it as part of gcc or separately?
Built separately
> This could also be a bug in crosstool ng.
Yes that's certainly a possibility.
> What was the command to invo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118725
Bug ID: 118725
Summary: libcpp build failure with NLS enabled
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #11 from Chris Packham ---
After working around things by not passing --enable-target-optspace I end up
getting an ICE later in the toolchain build.
[ALL ]during RTL pass: mach
[ALL ]
/home/ctng/crosstool-ng/.build/tic6x-el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118299
Bug ID: 118299
Summary: build errors for tic6x-elf
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
As
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
Severit
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&action=edit
Remove crypt and crypt_r interceptors
Attached is the patch derived from
https://github.com/llvm/llvm-project/
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://github.com/llvm/llvm-project/commit/d7bead833631486e337e5
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
> enabled
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
/home/bagas/cross/workdir/mips64-unknown/.build/mi
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&action=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
Seve
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
' CFLAGS_FOR_BUI
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
--- Comm
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&action=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
--pre
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
Compone
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 conte
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 the
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
Compon
31 matches
Mail list logo
