https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855
John Paul Adrian Glaubitz changed:
What|Removed |Added
Version|9.2.1 |10.0
--- Comment #10 from Jo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855
--- Comment #11 from John Paul Adrian Glaubitz ---
I can no longer reproduce the problem with the snapshot as of 2020-03-04
(94f7d7ec6eb). So it looks like the problem was fixed between (20200222,
e99b18cf710) and (20200304, 94f7d7ec6eb).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855
John Paul Adrian Glaubitz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #8 from John Paul Adrian Glaubitz ---
(In reply to Martin Liška from comment #0)
> I can't reproduce that with a cross compiler and I noticed that one needs to
> bootstrap compiler. --disable-bootstrap seems fine. I don't have a handy
Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, schwab at gcc dot gnu.org
Target Milestone: ---
Target: m68k-*-*
Since (20200304, 94f7d7ec6eb), a bootstrap build on m68k fails with:
checking size of long long... ok
checking for d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to Jeffrey A. Law from comment #2)
> Also note I bootstrap m68k regularly, last build was:
>
> 8e6d0dba166324f4b257329bd4b4ddc2b4522359
>
> Without more relevant data, there's nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #36 from John Paul Adrian Glaubitz ---
The m68k bootstrap also recently got broken (PR/94059). Currently testing
whether this is also a result of this change
(r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059
John Paul Adrian Glaubitz changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
--- Comment #7 from John Paul Adrian Glaubitz ---
(In reply to Alan Modra from comment #6)
> Since it is very unlikely that a bugzilla entry for gcc or binutils will
> prompt anyone to write the necessary linker support or change gcc, I'm
> closi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to Max from comment #2)
> Is there anyone more familiar with GCC internals and/or the AVR backend who
> I would be able to consult or possibly work with on this?
I think Jeff Law mentio
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: martin at netbsd dot org
Target Milestone: ---
Target: vax-*-*
This is a tracker bug for the convert the
Reporter: glaubitz at physik dot fu-berlin.de
CC: bernds at gcc dot gnu.org, schwab at gcc dot gnu.org
Target Milestone: ---
Bootstrapping gcc-11 on m68k fails with:
ln -sf libgccjit.so.0 libgccjit.so
echo | /<>/build-jit/./gcc/xgcc
-B/<>/build-jit/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
--- Comment #2 from John Paul Adrian Glaubitz ---
(In reply to Richard Biener from comment #1)
> can we have a backtrace?
Working on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #2)
> (In reply to Richard Biener from comment #1)
> > can we have a backtrace?
>
> Working on it.
I'm at the point now where I can invoke the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
--- Comment #5 from John Paul Adrian Glaubitz ---
Here's what I get on qemu-m68k-system (instead of qemu-user):
root@pacman:/srv/gcc-debug/build-jit/gcc# ./xgcc -B ./ -xc++ -nostdinc
/dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #7 from John Paul Adrian Glaubitz ---
> I'd be really grateful for advice on how to test and improve this. Is there a
> test suite somewhere that I've missed? Ideally, one that works with a free
> simulator?
Probably best to ask on
=gcc-10&;
arch=sh4&ver=10.2.0-6&stamp=1598935952&raw=0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899
--- Comment #2 from John Paul Adrian Glaubitz ---
(In reply to Richard Biener from comment #1)
> Did it work with GCC 10.1?
Yes. I'm currently performing some test builds and will hopefully start
bisecting soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899
--- Comment #3 from John Paul Adrian Glaubitz ---
I managed to successfully perform a local build natively with an updated
version of QEMU.
I have updated QEMU on the build servers as well and rescheduled the gcc-10
package.
Let's see if it bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
--- Comment #2 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #1)
> > https://wiki.debian.org/M68k/QemuSystemM68k
>
> The guide is not complete yet, I will finish it throughout next week.
The code has be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
--- Comment #3 from John Paul Adrian Glaubitz ---
Forgot to mention: The task is considered completed when the necessary changes
have been merged upstream so that m68k will be part of GCC-11 and newer
releases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
--- Comment #5 from John Paul Adrian Glaubitz ---
(In reply to Tobias Burnus from comment #4)
> Bernd posted the CC0-to-MODE_CC patches for review, cf:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01028.html [0/4]
> https://gcc.gnu.org/ml/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #10 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #9)
> Unfortunately, there's no simple fix for it that I know of. You can try to
> use the new register allocator with the option -mlra on a selective basis,
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
Target Milestone: ---
Target: avr-*-*
This is a tracker bug for the convert the avr backend from CC0 to MODE_CC so it
can be
arch=m68k&ver=1%3A20191130-1&stamp=1575330554&ra
w=0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92767
--- Comment #2 from John Paul Adrian Glaubitz ---
A local native bootstrap went through without problems, so maybe it's a problem
with the Debian buildds. I'll try to track it down and if I can reproduce it
locally, I will provide the preprocesse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282
--- Comment #3 from John Paul Adrian Glaubitz ---
This problem is still present in r278870:
../../src/gcc/ubsan.c: In function 'tree_node* ubsan_type_descriptor(tree,
ubsan_print_style)':
../../src/gcc/ubsan.c:409:33: warning: unterminated quote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282
--- Comment #5 from John Paul Adrian Glaubitz ---
(In reply to Andreas Schwab from comment #4)
> Workaround: use release checking.
Stupid question: How do I do that? Is there a switch that can be passed to the
configure script?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282
--- Comment #7 from John Paul Adrian Glaubitz ---
(In reply to Martin Liška from comment #6)
> (In reply to John Paul Adrian Glaubitz from comment #5)
> > (In reply to Andreas Schwab from comment #4)
> > > Workaround: use release checking.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282
--- Comment #10 from John Paul Adrian Glaubitz ---
(In reply to Martin Liška from comment #9)
> @John: Can you please attach a pre-processed source file (-E option). I
> should be able to reproduce that then with a cross compiler.
Is the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83464
--- Comment #4 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #3)
> Is this still an issue with current trunk?
> Can you please check?
I have to try. I'll run a testbuild. Currently the package has the following
workaroun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83464
--- Comment #6 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #5)
> I'm not sure this is an acceptable solution. It disables various other
> optimizations and reduces in worse code than normally should be. When you
> reb
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de,
jrtc27 at jrtc27 dot com, oleg.e...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946
--- Comment #1 from John Paul Adrian Glaubitz ---
Michael Karcher has figured out that this might be a bug in Debian's gcc-9, in
particular the patch
https://sources.debian.org/src/gcc-9/9.2.1-21/debian/patches/gcc-search-prefixed-as-ld.diff.
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946
--- Comment #2 from John Paul Adrian Glaubitz ---
Filed as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946
John Paul Adrian Glaubitz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
Target Milestone: ---
This is a request for enhancement to add a frontend for the Rust programming
language to GCC.
Currently, there is only one official implementation of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090
--- Comment #2 from John Paul Adrian Glaubitz ---
(In reply to Jakub Jelinek from comment #1)
> The Go FE actually isn't that independent, the same gofrontend is used by
> both GCC and LLVM, the same FE written in C++ in that case has then a
> co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13515
--- Comment #4 from John Paul Adrian Glaubitz ---
(In reply to Jason Duerstock from comment #3)
> For giggles, I just tried the test case on ia64, and it compiled
> successfully with GCC 7.2.
On the other hand, the issues occurs when building cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92767
--- Comment #5 from John Paul Adrian Glaubitz ---
Recent builds have been fine:
> https://buildd.debian.org/status/fetch.php?pkg=gcc-10&arch=m68k&ver=10-20200117-2&stamp=1579373512&raw=0
I guess it's safe to close this issue.
NCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de,
jrtc27 at jrtc27 dot com, kkoj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #1 from John Paul Adrian Glaubitz ---
Log for a successful build with gcc-8:
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=sh4&ver=2.5.5-4&stamp=1564498024&raw=0
Log for a failed build with gcc-9:
https://buildd.debian.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #2)
> Yeah, that looks like data. Something makes it jump to a wrong address. No
> idea why. Can you try to get a bit bigger code snippet at that point?
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #5 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #4)
> (In reply to John Paul Adrian Glaubitz from comment #3)
> >
> > I have put the compiled source into a tarball so you can have a look
> > yourself:
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #7 from John Paul Adrian Glaubitz ---
Created attachment 47871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47871&action=edit
Source and compiler output for string.c
I have created a tarball which contains both the C source,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #9 from John Paul Adrian Glaubitz ---
(In reply to Richard Biener from comment #8)
> One may want to see whether GCC 10 is affected or not.
Yes, I can confirm it affects GCC-10 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #11 from John Paul Adrian Glaubitz ---
Created attachment 47878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47878&action=edit
Source and compiler output for string.c with stack-protector disabled
(In reply to Oleg Endo from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #12 from John Paul Adrian Glaubitz ---
Building with -O1 fixes the problem for me. Now I need to compare the flags for
-O1 and -O2 and check which one breaks the build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #13 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> Building with -O1 fixes the problem for me. Now I need to compare the flags
> for -O1 and -O2 and check which one breaks the build.
It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
--- Comment #9 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #8)
> It's the same error message, but the actual cause is different. Please open
> a new PR for this and attach the pre-processed source file that fails to
>
c
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: gcc-bugzilla at mkarcher dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
--- Comment #1 from John Paul Adrian Glaubitz ---
Command line is:
/usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore
-DBUILDING_WITH_CMAKE=1 -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1
-DJSC_COMPILATION -DJSC_GLIB_API_ENABLED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
--- Comment #2 from John Paul Adrian Glaubitz ---
Created attachment 47885
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47885&action=edit
Source and preprocessed source plus assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
--- Comment #3 from John Paul Adrian Glaubitz ---
The problem does not affect gcc-8. It affects gcc-9 and gcc-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
--- Comment #5 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #4)
> the error message is
>
> unable to find a register to spill in class 'R0_REGS'
>
> please try to re-build with -mlra
Yes, that helps and I just reali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
--- Comment #7 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #6)
> If -mlra helps with this case, then let's close this one as 'WON'T FIX', ok?
Yes, I'll open a new issue for the actual bug I wanted to report. I can
repr
oduct: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, kkojima
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #1 from John Paul Adrian Glaubitz ---
Created attachment 47886
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47886&action=edit
Source and preprocessed source plus assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #2 from John Paul Adrian Glaubitz ---
This bug does not affect gcc-8. It affects gcc-9 and gcc-10. Using -mlra does
not help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #3 from John Paul Adrian Glaubitz ---
Building with -O1 instead of -O2 helps. I can try to bisect the optimization
flag which causes this problem later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #4 from John Paul Adrian Glaubitz ---
Passing -fno-move-loop-invariants to the command line fixes the problem for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #5 from John Paul Adrian Glaubitz ---
Hmm, there is one other source code file within webkit2gtk where
-fno-move-loop-invariants does not help. I can only get that particular source
file to be compiled if I disable all optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #118 from John Paul Adrian Glaubitz ---
Is there anything that currently speaks against switching to LRA by default
now?
I think, it would be a good idea for gcc-11 or even gcc-10 if possible. I will
report all issues I'm running int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #120 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #119)
> Last time this issue came up, I asked you to re-build all debian with -mlra
> enabled
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00977.html
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #7 from John Paul Adrian Glaubitz ---
Created attachment 47907
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47907&action=edit
Source and preprocessed source plus assembly, second case
Here are the saved temps for the second c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #8 from John Paul Adrian Glaubitz ---
The second case compiles fine with gcc-8 as well, but fails with g++-9 and
g++-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #122 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #121)
> (In reply to John Paul Adrian Glaubitz from comment #120)
> >
> > That's a huge task which is why I prefer fixing issues on the fly.
>
> I thought t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #123 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #121)
> (In reply to John Paul Adrian Glaubitz from comment #120)
> >
> > That's a huge task which is why I prefer fixing issues on the fly.
>
> I thought t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #124 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #123)
> I will just do that for the default kernel now. But I won't trigger a full
> archive rebuild. Just report issues once I see them.
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #25 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #24)
> Adrian, have you had a chance to apply the test patch in comment #22 and
> re-run it?
I hadn't seen this patch, sorry. I will try that tonight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #13 from John Paul Adrian Glaubitz ---
Indeed, this seems to be related to LRA.
I just tried to build gcc-9 with LRA enabled by default and the build fails
when trying to build gnat with:
checking for shl_load in -ldld... s-gearop.a
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: glaubitz at physik dot fu-berlin.de
CC: cmang at google dot com, ian at airs dot com, jrtc27 at
jrtc27 dot com,
kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #28 from John Paul Adrian Glaubitz ---
Just built two weeks ago, natively:
root@atlantis:~> gcc-8 -v
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnuspe/8/lto-wrapper
Target: powerpc-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #30 from John Paul Adrian Glaubitz ---
(In reply to Jakub Jelinek from comment #29)
> The rs6000 backend had since the split around 290 commits that didn't touch
> the powerpcspe backend, if we just assume that only 20% of those are
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #32 from John Paul Adrian Glaubitz ---
(In reply to Segher Boessenkool from comment #31)
> It would have been announced in gcc-7/changes.html (linked from the
> announcement on gcc-announce@, I do hope you read that?), but instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #36 from John Paul Adrian Glaubitz ---
(In reply to Jakub Jelinek from comment #33)
> Yes, but the port split was done in May last year, and nothing substantial
> happened since then. Port maintainance is not about promises, but abou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #38 from John Paul Adrian Glaubitz ---
(In reply to Eric Botcazou from comment #35)
> Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-)
I thought Jakub works for RedHat?
> The SPE port has already been mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #39 from John Paul Adrian Glaubitz ---
(In reply to Jakub Jelinek from comment #37)
> Not sure about IBM, I as a GCC developer and RM have major problem with the
> amount of dead code in the port, because anyone who makes changes to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #40 from John Paul Adrian Glaubitz ---
Is there documentation like this for gcc?
> https://llvm.org/docs/WritingAnLLVMBackend.html
Would be very useful for people wanting to help with the old backends.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #44 from John Paul Adrian Glaubitz ---
(In reply to David Edelsohn from comment #41)
> SPE mostly is a separate architecture that happens to share many of the
> basic mnemonics with PowerPC. Maintaining the SPE port was a burden to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #45 from John Paul Adrian Glaubitz ---
(In reply to Jakub Jelinek from comment #42)
> See e.g. https://gcc.gnu.org/onlinedocs/gccint/
> https://gcc.gnu.org/onlinedocs/gccint/#toc-RTL-Representation
> https://gcc.gnu.org/onlinedocs/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #48 from John Paul Adrian Glaubitz ---
(In reply to Segher Boessenkool from comment #47)
> Believe it or not, but the rs6000 port maintainers *care* about older
> systems.
Then why is something that is still working and being used by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #49 from John Paul Adrian Glaubitz ---
Hi Andrew!
(In reply to Andrew Jenner from comment #21)
> I'm still actively working on it. The patch is close to ready for commit
> now, I think - I'm going to try to get it committed by the en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #51 from John Paul Adrian Glaubitz ---
(In reply to Andrew Jenner from comment #50),
>
> Thanks for the offer of help. I already have hardware, but I need to get my
> test scripts in order.
Ok, great!
> I'm attaching my current pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #53 from John Paul Adrian Glaubitz ---
(In reply to Andrew Jenner from comment #52)
> (In reply to John Paul Adrian Glaubitz from comment #51)
> > Absolutely. Where should I test the patch? Natively on powerpcspe? On
> > x86_64? Or an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #54 from John Paul Adrian Glaubitz ---
Just tried a native build with gcc from trunk plus the patch, fails due to an
apparent syntax error:
powerpc-linux-gnuspe-g++ -std=gnu++98 -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #55 from John Paul Adrian Glaubitz ---
This seems to help:
diff --git a/gcc/config/powerpcspe/powerpcspe.md
b/gcc/config/powerpcspe/powerpcspe.md
index 746f2bd1ee3..2e08bcea2b5 100644
--- a/gcc/config/powerpcspe/powerpcspe.md
+++ b/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #56 from John Paul Adrian Glaubitz ---
Another issue:
In file included from ../.././gcc/config/powerpcspe/powerpcspe.h:1865:0,
from ./tm.h:25,
from ../.././gcc/genopinit.c:24:
../.././gcc/config/powe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #57 from John Paul Adrian Glaubitz ---
Andrew, could you refresh your patch for the current trunk branch?
It doesn't fully apply for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #59 from John Paul Adrian Glaubitz ---
(In reply to Andrew Jenner from comment #58)
> Acknowledged. I will try to get to that later this week.
Any news on this?
News from Debian's side is that we have upgraded build capacity for pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #60 from John Paul Adrian Glaubitz ---
Ping?
/status/fetch.php?pkg=openjdk
-11&arch=ia64&ver=11%7E19-1&stamp=1529924927&raw=0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gl
?pkg=gmp&arc
h=sparc64&ver=2%3A6.1.2%2Bdfsg-4&stamp=1565898628&raw=
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
John Paul Adrian Glaubitz changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472
--- Comment #3 from John Paul Adrian Glaubitz ---
It can reproduced by simply cloning the gmp repo, building it and running the
testsuite:
$ hg clone https://gmplib.org/repo/gmp
$ cd gmp
$ ./.bootstrap && ./configure --enable-cxx --enable-fat --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
--- Comment #5 from John Paul Adrian Glaubitz ---
I can confirm that disabling LTO on sparc64 makes gcc build fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
--- Comment #7 from John Paul Adrian Glaubitz ---
(In reply to Martin Liška from comment #6)
> Can you please debug the internal compiler error?
> I'm interested in how 'hist' struct looks like?
The gcc compile farm has a fast sparc64 porterbox
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: burnus at gcc dot gnu.org, jason.duerstock at gmail dot com,
jrtc27 at jrtc27 dot com, law at redhat
1 - 100 of 655 matches
Mail list logo
