https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #32 from Piotr Kubaj ---
(In reply to Iain Sandoe from comment #31)
> what is the current situation with this
> - what input are we waiting for?
> - is the problem now cleared for powerpc64-freebsd?
Probably not, but FreeBSD now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #31 from Iain Sandoe ---
what is the current situation with this
- what input are we waiting for?
- is the problem now cleared for powerpc64-freebsd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #30 from Piotr Kubaj ---
With default flags:
during RTL pass: cprop_hardreg
In file included from
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libgcc/unwind-c.c:32:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #29 from Iain Sandoe ---
(In reply to Piotr Kubaj from comment #28)
> I just tried on FreeBSD 12.2-RELEASE on powerpc64 with base gcc 4.2.1:
> gmake[4]: Entering directory
> '/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/gcc'
> c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Piotr Kubaj changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #26 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:489c62beef150f870d1755d3772bd2d0ce7344b4
commit r9-8878-g489c62beef150f870d1755d3772bd2d0ce7344b4
Author: Gustavo Romero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Piotr Kubaj changed:
What|Removed |Added
Version|9.3.0 |10.0
--- Comment #25 from Piotr Kubaj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:42e20fd25d3651349d892d8af864dc576c09019c
commit r10-7749-g42e20fd25d3651349d892d8af864dc576c09019c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #23 from Jakub Jelinek ---
Eventually yes, but I'd like to test & submit the above patch too and let it be
tested on the trunk for a while before backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #22 from Piotr Kubaj ---
(In reply to CVS Commits from comment #21)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:c00568f376078129196740d83946d54dc5437401
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c00568f376078129196740d83946d54dc5437401
commit r10-7736-gc00568f376078129196740d83946d54dc5437401
Author: Gustavo Romero
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #20 from Jakub Jelinek ---
So, we are running into PR33916 here, not very much reduced test:
class function_arg_info
{
public:
function_arg_info ()
: type (0), mode (0), named (false), pass_by_reference (false)
{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #19 from Jakub Jelinek ---
Since Richard's change, assign_parm_data_one has the arg member with
function_arg_info type, and that class has a user-provided default constructor.
Perhaps for old GCC we could instead of
*data =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #18 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #17)
> So, what exactly happens? Does GCC 4.2 e.g. fail to initialize all members
> to zeros in the
> - memset (data, 0, sizeof (*data));
> + *data =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #16 from Piotr Kubaj ---
634afa05a8cbff010480088811fe1f39eca70c1d is the first bad commit
commit 634afa05a8cbff010480088811fe1f39eca70c1d
Author: Richard Sandiford
Date: Tue Aug 20 08:53:52 2019 +
Make function.c use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Piotr Kubaj changed:
What|Removed |Added
CC||richard.sandiford at arm dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #14 from Piotr Kubaj ---
Exact error for 10.0:
In file included from
/usr/ports/lang/gcc10-devel/work/gcc-10-20190825/libgcc/libgcc2.c:56:
/usr/ports/lang/gcc10-devel/work/gcc-10-20190825/libgcc/libgcc2.c: In function
'__multi3':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #13 from Piotr Kubaj ---
Breakage in GCC 10 was caused after 201900818 snapshot, but before 201900825
(201900825 is the first broken).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #12 from Piotr Kubaj ---
This issue can be fixed with the following patches:
--- gcc/dumpfile.c.orig 2020-04-07 14:09:14 UTC
+++ gcc/dumpfile.c
@@ -2055,7 +2055,7 @@ temp_dump_context::temp_dump_context (bool forcibly_en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #11 from Piotr Kubaj ---
Hm, sorry, I copied the Entering directive from a line before.
Nevertheless, setting -O1 helps with GCC 7 and 8.
But building GCC 9 still fails (I'm testing the newest snapshot). I tried both
-O0 and -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #10 from Jonathan Wakely ---
(In reply to Piotr Kubaj from comment #7)
> But the failing command is run strictly with -O2. If I just cd to
> '/usr/local/poudriere/ports/default/lang/gcc7/work/.build/libiberty' and run
> it manually,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #9 from Jonathan Wakely ---
Or the configure option --enable-cxx-flags="-O0 -g"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #8 from Jonathan Wakely ---
The crash is while compiling C+ code, and your CXXFLAGS still contains -O2:
"CXXFLAGS=-g -O2 -pipe -DLIBICONV_PLUG"
Try setting CXXFLAGS_FOR_TARGET.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #7 from Piotr Kubaj ---
It still crashes (test was done with 7.4.0), but we're getting somewhere.
It crashes at:
libtool: compile:
/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/xgcc
-shared-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #6 from Piotr Kubaj ---
(In reply to Richard Biener from comment #5)
> So it looks like stage1 gcc is miscompiled somehow. I wonder if you can
> avoid
> setting CFLAGS et al?
I just added CFLAGS+=-O0 and CXXFLAGS+=-O0. For now, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Richard Biener changed:
What|Removed |Added
Keywords||build
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #4 from Piotr Kubaj ---
Sorry, that was for a build with GCC 6. A build with GCC 4.2.1 is done with the
following.
Configure:
/usr/bin/env CC="cc" CPP="cpp" CXX="c++" CFLAGS="-O2 -pipe -DLIBICONV_PLUG
-fno-strict-aliasing "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #3 from Piotr Kubaj ---
Make is executed with:
/usr/bin/env PERL_USE_UNSAFE_INC=1
XDG_DATA_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work
XDG_CONFIG_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #2 from Piotr Kubaj ---
I compile from FreeBSD ports tree (just change the port's Makefile not to use
external (newer) GCC, but the in-base 4.2.1), so it adds some environment
variables.
/usr/bin/env CC="g
cc6" CPP="cpp6" CXX="g++6"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
33 matches
Mail list logo
