https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #12 from Jonathan Wakely ---
I can build fine using these steps:
export TARGET=arm-linux-gnueabihf
export PREFIX=/tmp/rpi-toolchain
wget https://ftp.gnu.org/gnu/binutils/binutils-2.31.tar.gz
tar xf binutils-2.31.tar.gz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #11 from Jonathan Wakely ---
(In reply to maths soso from comment #6)
> Created attachment 58771 [details]
> compilation of gcc 14.1.0
configure: error: source directory already configured; run "make distclean"
there first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #10 from Jonathan Wakely ---
Oh I see you already said you're using contrib/download_prerequisites so that's
all you need.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #9 from Jonathan Wakely ---
(In reply to maths soso from comment #7)
> I added to path of libgmp, libmpc, and libmpfr to LD_LIBRARY_PATH, and still.
Don't do that, just add the gmp, mpfr and mpc sources to the gcc tree and let
them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:6a55ff29578e8afbe795547468a78494b3b52831
commit r15-2368-g6a55ff29578e8afbe795547468a78494b3b52831
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #7 from maths soso ---
I added to path of libgmp, libmpc, and libmpfr to LD_LIBRARY_PATH, and still.
make[1]: *** [Makefile:5149: configure-gmp] Error 1
make[1]: *** Waiting for unfinished jobs
checking whether to install
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #6 from maths soso ---
Created attachment 58771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58771=edit
compilation of gcc 14.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #5 from maths soso ---
I did install both gcc and binutils for $TARGET in $PREFIX
export WORKSPACE_ROOT=~/rpi0/toolchain
export PREFIX=${WORKSPACE_ROOT}/toolchain
export TARGET=arm-linux-gnueabihf
export
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
--- Comment #4 from Jonathan Wakely ---
(In reply to maths soso from comment #0)
> /home/sofiane/rpi0/toolchain/build/gcc2/./gcc/as: 106: exec: -march=armv8-a:
> not found
If you look at /home/sofiane/rpi0/toolchain/build/gcc2/./gcc/as you'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
maths soso changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116119
Bug ID: 116119
Summary: Error building gcc 8.3.0
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
Richard Biener changed:
What|Removed |Added
Target Milestone|12.4|12.5
--- Comment #15 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
On Thu, Mar 07, 2024 at 12:53:31PM +0100, Thomas Schwinge wrote:
> >From 6a6520e01f7e7118b556683c2934f2c64c6dbc81 Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge
> Date: Thu, 7 Mar 2024 12:31:52 +0100
> Subject: [PATCH] GCN, nvptx: Fatal error for missing symbols in
> 'libhsa-runtime64.so.1',
Hi!
On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote:
> [...] If the nvptx libgomp plugin is installed, but libcuda.so.1
> can't be found, then the plugin behaves as if there are no PTX devices
> available. [...]
ACK.
> --- libgomp/plugin/plugin-nvptx.c.jj 2017-01-13 12:07:56.0 +0100
On Sat, Feb 10, 2024 at 07:35:22PM +0100, Marc Glisse wrote:
> On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
>
> > So, how does one biulding all parts of gcc with "-O -g"?
> >
> > In my shell script, I have
> >
> > CFLAGS="-O -g"
> > export CFLAGS
> >
> > CXXFLAGS="-O -g"
> > export CXXFLAGS
On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure --prefix=$HOME/work
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure --prefix=$HOME/work --enable-languages=c,c++,fortran \
--enable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #7 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:5c3ba60024fedc6b3d374ebb071bcf5b3e27cd62
commit r14-8840-g5c3ba60024fedc6b3d374ebb071bcf5b3e27cd62
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Tamar Christina changed:
What|Removed |Added
Assignee|gaius at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
|building|building
|gcc/m2/gm2-libs/NumberIO.mo |gcc/m2/gm2-libs/NumberIO.mo
|d |d since
||r14-8769-g64b0130bb6702c
Assignee|unassigned at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #4 from Iain Sandoe ---
Created attachment 57318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57318=edit
gimple for 179t.vect
now there's a mem at the start of bb3 with the label following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #3 from Iain Sandoe ---
Created attachment 57317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57317=edit
gimple for 179t.ifcvt
the label seems OK here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #1 from Iain Sandoe ---
..
(gdb) p debug_tree(current_function_decl)
>
SI
size
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf5b5d008
arg-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Bug ID: 113750
Summary: [14 Regression] ICE in vect building
gcc/m2/gm2-libs/NumberIO.mod
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112352
Rustam Abdullaev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112352
--- Comment #1 from Richard Biener ---
cd gcc-12.3.0
./configure --enable-languages=c,c++,ada,lto --disable-multilib
make -j$(nproc)
do not configure in source dir, use a separate directory:
cd gcc-12.3.0
mkdir obj
cd obj
./configure
gcc/ChangeLog:
* gcc/config/loongarch/t-loongarch: include loongarch-def.h,
loongarch-tune.h and loongarch-driver.h in OPTIONS_H_EXTRA.
Co-authored-by: Lulu Cheng
---
gcc/config/loongarch/t-loongarch | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Trying to build default target in 13.1.0 source, and am hitting a
Pthreads are required error.
I have the .h and lib on my system, so not sure why hitting this error.
I goog'd the error and see nothing recent about why I'd get the error.
Any suggestions?
Please include me in response, as I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
Richard Biener changed:
What|Removed |Added
Target Milestone|12.3|12.4
--- Comment #14 from Richard
023, 23:03 Chris Johns, >> <mailto:ch...@contemporary.net.au>> wrote:
>>>
>>> Hi,
>>>
>>> I am sorting out some issues building RTEMS on MacOS including the
>>> M
>>> processors.
>>> Th
sorting out some issues building RTEMS on MacOS including the M
processors.
The building gcc-12.2.1 for the few architectures I tested fail with
sig
faults
in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
result I
wo
am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with
> sig
> faults
> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As
> a
>
On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, wrote:
>
>
> On Fri, 24 Mar 2023, 23:03 Chris Johns, wrote:
>
>> Hi,
>>
>> I am sorting out some issues building RTEMS on MacOS including the M
>> processors.
>> The building gcc-12.2.1 for the few arch
On Fri, 24 Mar 2023, 23:03 Chris Johns, wrote:
> Hi,
>
> I am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with sig
> faults
> in xgcc when building the runtime. I tried a
Hi,
I am sorting out some issues building RTEMS on MacOS including the M processors.
The building gcc-12.2.1 for the few architectures I tested fail with sig faults
in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a result I
wondered about bootstrapping gcc and using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #13 from H.J. Lu ---
Created attachment 54389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54389=edit
A patch for GCC 12 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #12 from Brecht Sanders ---
I couldn't apply that patch. Is that for 12.2.0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #11 from H.J. Lu ---
Created attachment 54288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54288=edit
An updated patch
Try this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #10 from Brecht Sanders ---
I can confirm GCC 12.2.0 builds fine with that patch and without CFLAG
-D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #9 from H.J. Lu ---
Created attachment 54284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54284=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100945
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
Thomas Petazzoni changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #6 from Richard Earnshaw ---
Nobody has proposed any patches yet, but I imagine we'd end up treating
-mcpu=iwmmxt[2] in the same way as -mcpu=xscale. Similarly for
-march=iwmmxt[2].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #5 from Thomas Petazzoni ---
ACK, but what we're using in this configuration is --with-cpu=iwmmxt. I'm a bit
confused between it being a CPU type, and it being just a vector extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #4 from Richard Earnshaw ---
I don't think we're talking about removing support for the CPU, just support
for the iwmmxt extension. That is, you can still use it as an Arm cpu, but
without the vector engine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #3 from Andrew Pinski ---
(In reply to Thomas Petazzoni from comment #2)
> Thanks for the quick feedback! I am not super familiar with iwmmxt, but as I
> understand it is used in Marvell PXA270 and above. While these are fairly
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #2 from Thomas Petazzoni ---
Thanks for the quick feedback! I am not super familiar with iwmmxt, but as I
understand it is used in Marvell PXA270 and above. While these are fairly old
indeed, their support is still maintained in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
Bug ID: 106972
Summary: internal compiler error: in extract_insn, at
recog.c:2770 on ARMeb when building gcc itself
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
In my opinion, the advantage of autotools is that it can generate a
configure script that can be shipped with the source tarball, then any
one with the source can run the configure script when the system has a
POSIX shell and tools. If using CMake, meson, xmake, etc. the user will
first need
> On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote:
>
>> Hi,
>>
>> I want to get the opinions of GCC developers regarding adding CMake as a
>> build system for GCC. Is it something you would like, something you are
>> neutral about, or something you are strongly against?
>>
>> Thanks for
On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote:
> Hi,
>
> I want to get the opinions of GCC developers regarding adding CMake as a
> build system for GCC. Is it something you would like, something you are
> neutral about, or something you are strongly against?
>
> Thanks for your valuable
在 2022-09-11 22:29, Junk Trash via Gcc 写道:
Hi,
I want to get the opinions of GCC developers regarding adding CMake as a build
system for GCC. Is it something you would like, something you are neutral
about, or something you are strongly against?
Thanks for your valuable feedback!
Hi,
I want to get the opinions of GCC developers regarding adding CMake as a build
system for GCC. Is it something you would like, something you are neutral
about, or something you are strongly against?
Thanks for your valuable feedback!
Regards,
JT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741
--- Comment #3 from jbeulich at suse dot com ---
If I'm reading the log right, it's stages 2 and 3 where the warnings appear,
while stage 1 (using gcc10) don't expose such a warning. Interestingly the
warnings do appear (once) when doing cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741
--- Comment #2 from Andrew Pinski ---
/* If we haven't already defined a front-end-specific diagnostics
style, use the generic one. */
#ifdef GCC_DIAG_STYLE
#define GCC_PPDIAG_STYLE GCC_DIAG_STYLE
#else
#define GCC_PPDIAG_STYLE __gcc_diag__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741
Bug ID: 106741
Summary: suspicious %qE related warning when building gcc
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
er.com/dir/uiRZKGsU
(Direct link to tar-file.)
https://1fichier.com/?qe2en1n9bh6ixl6669pi
Inside the tar-file the
./demobuild/autogenerated_tmp/GCC_v_11_2_0/gcc
includes all files as they were/are right after the failed build.
Actually the use case that I described here for custo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #7 from Andrew Pinski ---
(In reply to Martin Vahi from comment #5)
> Created attachment 53385 [details]
This is a failure while "make clean".
And your patch does not even touch anything related to libgcc and "make clean".
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #6 from Martin Vahi ---
Created attachment 53386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53386=edit
List of changes that allow temporary use of an alternative Bash binary.
Too old Bash version:
GNU bash, version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #5 from Martin Vahi ---
Created attachment 53385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53385=edit
Console Output of the Bash Version Related GCC Build Failure
...
gmake[1]: Entering directory
its "#!/bin/bash -eu" did not break anything.
This is not luck. That script is not used when building GCC. Most of them
aren't used when building GCC, as Andrew said.
> The version of Bash that turned out to be too old
> for building the GCC v.11.2.0 was
>
> 4.3.48(1)-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #3 from Andrew Pinski ---
Also almost all of the GCC build scripts depend on just POSIX sh rather than
bash. It might be the case you need to set CONFIG_SHELL instead as defined as
part of the autoconf .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #2 from Andrew Pinski ---
GCC 11.2.0 had the same as what I found on the trunk `git grep "/bin/bash"
releases/gcc-11.2.0`):
releases/gcc-11.2.0:contrib/bench-stringop:#!/bin/bash
releases/gcc-11.2.0:contrib/compare-all-tests:#!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
Bug ID: 106429
Summary: Building GCC is Inhibited on old Linux Distributions
due to the use of "#!/bin/bash"
Product: gcc
Version: 11.2.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106387
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3c4af0f0549a07799d76e9e48d3d3bd85197b92a
commit r13-1793-g3c4af0f0549a07799d76e9e48d3d3bd85197b92a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106387
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106387
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106387
Bug ID: 106387
Summary: [13 regression] ICE when building gcc after
r13-1764-g5f59d0f2d9fa92
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #23 from Chris Clayton ---
On 18/07/2022 19:13, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
>
> Aldy Hernandez changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #22 from Andrew Pinski ---
(In reply to Aldy Hernandez from comment #21)
> Confirmed on x86-64 with: ./configure --enable-languages=c,c++
> --enable-checking=no.
>
> Interestingly, --enable-checking=release works.
well some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #20 from Chris Clayton ---
On 08/07/2022 15:02, Chris Clayton wrote:
> Hi
>
> On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
>>
>> Andrew Pinski changed:
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #19 from Chris Clayton ---
Hi
On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
>
> Andrew Pinski changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #18 from Chris Clayton ---
Created attachment 53256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53256=edit
git bisect log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #17 from Chris Clayton ---
I've cloned git://gcc.gnu.org/git/gcc.git and bisected between 13-20220626
(ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd) and 13-20220619
(4390e7bfbc641a52c6192b448768dafdf4565527) as bad and good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #16 from Chris Clayton ---
I've tried two further build of gcc-13 using gcc-12-20220702.
The gcc-13-20220703 snapshot fails with the same ICEs but the 20220619 snapshot
builds successfully.
So we have 13-20220626 and 13-20220703
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #15 from Chris Clayton ---
On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
>
> Andrew Pinski changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-Krisux-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #12 from Chris Clayton ---
I've just run the build again with gcc-11-20220701 and get the same set of
ICEs. I've kept the files of diagnostics output by gcc and can provide them id
they will be helpful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #11 from Chris Clayton ---
On 03/07/2022 12:00, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
>
> --- Comment #10 from Andreas Schwab ---
> How did you build the bootstrap compiler?
>
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #10 from Andreas Schwab ---
How did you build the bootstrap compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #9 from Chris Clayton ---
Created attachment 53255
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53255=edit
Error messages output to terminal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #8 from Chris Clayton ---
Created attachment 53254
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53254=edit
GCC diagnostics file 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #7 from Chris Clayton ---
Created attachment 53253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53253=edit
GCC diagnostics file 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #6 from Chris Clayton ---
Created attachment 53252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53252=edit
GCC diagnostics file 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #5 from Chris Clayton ---
Created attachment 53251
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53251=edit
GCC diagnostics file 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #4 from Chris Clayton ---
Created attachment 53250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53250=edit
GCC diagnostics file 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #3 from Chris Clayton ---
Created attachment 53249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53249=edit
GCC diagnostics file 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #2 from Chris Clayton ---
Created attachment 53248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53248=edit
GCC diagnostics file 3
1 - 100 of 918 matches
Mail list logo