https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #23 from Richard Biener ---
Just to summarize we are talking about the six commits
r14-496-g580cda3c2799b1
r14-497-ge487fcc0f7466e
r14-498-gc0ce29bc1ce329
r14-499-g27fcf994c5515e
r14-500-g703417a030b3d8
r14-501-g0a85544e1aaeca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #22 from Sam James ---
Thanks for your help.
We've had this in production since 26th May and no complaints (but a lot of
happy customers who couldn't build 12 or earlier 13 versions):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #21 from rguenther at suse dot de ---
On Thu, 25 May 2023, sjames at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
>
> --- Comment #20 from Sam James ---
> When I looked at it, I think I got it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #20 from Sam James ---
When I looked at it, I think I got it to apply to 13 with no hassle and it
seemed to work okay, but I didn't test it that hard.
It's a considerable win so even if not backported upstream, if you think it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #19 from rguenther at suse dot de ---
On Wed, 24 May 2023, userm57 at yahoo dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
>
> --- Comment #18 from Stan Johnson ---
> $ git clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #18 from Stan Johnson ---
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout master
I'm testing a manual bootstrap of "gcc version 14.0.0 20230524 (experimental)
(GCC)" now, accessed via git as shown above.
It will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #17 from Andreas Schwab ---
The linker just uses TEXT_START_ADDR=0x8000, but mmap can use any address.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #16 from Richard Biener ---
(In reply to Andreas Schwab from comment #15)
> TASK_SIZE is 0xF000UL on m68k.
That would mean ~3.75GB virtual address space is available. The cited
/proc/maps though looks like the lower half isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #15 from Andreas Schwab ---
TASK_SIZE is 0xF000UL on m68k.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #14 from Stan Johnson ---
I can try to capture the offending "cc1plus" and "as" processes just before the
compilation of gimple-match.cc fails in stage2; the output will look something
like this (for a different cc1plus process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #13 from rguenther at suse dot de ---
> Am 23.05.2023 um 19:44 schrieb userm57 at yahoo dot com
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
>
> --- Comment #12 from Stan Johnson ---
>> That’s indeed unhelpful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #11 from rguenther at suse dot de ---
> Am 23.05.2023 um 19:28 schrieb userm57 at yahoo dot com
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
>
> --- Comment #10 from Stan Johnson ---
>> The question is how much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #10 from Stan Johnson ---
> The question is how much virtual memory is exposed to a user
> process, that is - how large is the address space?
I'm not sure, but I see this:
$ prlimit
RESOURCE DESCRIPTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #9 from rguenther at suse dot de ---
On Tue, 23 May 2023, userm57 at yahoo dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
>
> --- Comment #8 from Stan Johnson ---
> > How much virtual memory does the m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #8 from Stan Johnson ---
> How much virtual memory does the m68k host have?
Swap space in the m68k virt VM is configurable; I'm using 1 GiB in two 512 MiB
partitions. I noticed that compilation goes further with two 512 MiB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Richard Biener changed:
What|Removed |Added
CC||schwab at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #6 from Stan Johnson ---
Thanks, let me know if you need me to check anything here.
The problem has existed since at least gcc-12. Initially I thought the QEMU
q800 VM had run out of memory, but switching to a virt VM with ~3 GB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #4 from Stan Johnson ---
Adding more swap space doesn't help.
The latest Gentoo update attempted to merge gcc-13.1.1_p20230520, and it failed
while compiling gimple-match.cc in stage2.
The error message is "virtual memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Richard Biener changed:
What|Removed |Added
Target||m68k
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Component|bootstrap
22 matches
Mail list logo
