Re: gcc behavior on memory exhaustion

2017-08-11 Thread Andreas Schwab
On Aug 11 2017, Andrew Roberts  wrote:

> Meanwhile, I'm testing memory usage and compile times with my code on gcc
> 5.4.0, 6.4.0, 7.2.0 and 8.0.0, across x64, arm and aarch64.

Make sure you compile them all with the same checking options.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


How to support 64-bit PowerPC -mcmodel=medium?

2017-08-11 Thread Sebastian Huber

Hello,

it seems that the -mcmodel=small was not the right default for RTEMS 
applications, since I get


relocation truncated to fit: R_PPC64_TOC16_DS against `.got'+118

errors quite quickly.

So, I try to add the -mcmodel option. However, some piece is missing:

/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc 
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc 
-B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/me6500/m64/newlib/ 
-isystem 
/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/me6500/m64/newlib/targ-include 
-isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include 
-B/opt/rtems-4.12/powerpc-rtems4.12/bin/ 
-B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem 
/opt/rtems-4.12/powerpc-rtems4.12/include -isystem 
/opt/rtems-4.12/powerpc-rtems4.12/sys-include  -mcpu=e6500 -m64 -g -O2 
-O2 -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall 
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include -I. -I. 
-I../../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc 
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/. 
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc 
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include   -g0 
-finhibit-size-directive -fno-inline -fno-exceptions 
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize 
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. 
-I../../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc 
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/. 
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc 
-I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include  -o crtbeginS.o 
-MT crtbeginS.o -MD -MP -MF crtbeginS.dep -msdata=none -O2 -c 
/home/EB/sebastian_h/archive/gcc-git/libgcc/crtstuff.c -DCRT_BEGIN 
-DCRTSTUFFS_O -fPIC -mcmodel=medium -save-temps

crtstuff.s: Assembler messages:
crtstuff.s:44: Error: can't resolve `.tm_clone_table' {.tm_clone_table 
section} - `.LCTOC1' {.toc1 section}
crtstuff.s:45: Error: can't resolve `__TMC_END__' {*UND* section} - 
`.LCTOC1' {.toc1 section}
crtstuff.s:82: Error: can't resolve `.tm_clone_table' {.tm_clone_table 
section} - `.LCTOC1' {.toc1 section}
crtstuff.s:83: Error: can't resolve `__TMC_END__' {*UND* section} - 
`.LCTOC1' {.toc1 section}
crtstuff.s:131: Error: can't resolve `.bss' {.bss section} - `.LCTOC1' 
{.toc1 section}
crtstuff.s:143: Error: can't resolve `__dso_handle' {.sdata section} - 
`.LCTOC1' {.toc1 section}
crtstuff.s:149: Error: can't resolve `__DTOR_END__' {*UND* section} - 
`.LCTOC1' {.toc1 section}
crtstuff.s:150: Error: can't resolve `.dtors' {.dtors section} - 
`.LCTOC1' {.toc1 section}
crtstuff.s:153: Error: can't resolve `.bss' {.bss section} - `.LCTOC1' 
{.toc1 section}
crtstuff.s:157: Error: can't resolve `.dtors' {.dtors section} - 
`.LCTOC1' {.toc1 section}
crtstuff.s:162: Error: can't resolve `.bss' {.bss section} - `.LCTOC1' 
{.toc1 section}
crtstuff.s:185: Error: can't resolve `.eh_frame' {.eh_frame section} - 
`.LCTOC1' {.toc1 section}
crtstuff.s:192: Error: can't resolve `.bss' {.bss section} - `.LCTOC1' 
{.toc1 section}
crtstuff.s:226: Error: can't resolve `.bss' {.bss section} - `.LCTOC1' 
{.toc1 section}
crtstuff.s:227: Error: can't resolve `.eh_frame' {.eh_frame section} - 
`.LCTOC1' {.toc1 section}


The code generation works with -mcmodel=small and -mcmodel=large.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

>From 7d2b18f303cc7cf62d29328b362e645027884270 Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Fri, 11 Aug 2017 11:26:19 +0200
Subject: [PATCH] PowerPC/RTEMS: Enable -mcmodel option

---
 gcc/config.gcc|  2 +-
 gcc/config/rs6000/rtems.h | 47 +++
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index a9196cd26d9..593631849bb 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2416,7 +2416,7 @@ powerpc-*-eabi*)
 	;;
 powerpc-*-rtems*)
 	tm_file="rs6000/biarch64.h ${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h rs6000/sysv4.h rs6000/e500.h rs6000/rtems.h rtems.h"
-	extra_options="${extra_options} rs6000/sysv4.opt"
+	extra_options="${extra_options} rs6000/sysv4.opt rs6000/linux64.opt"
 	tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems rs6000/t-ppccomm"
 	;;
 powerpc*-*-linux*)
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 8a62fdcbaf3..40940c1dfe6 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -37,6 +37,11 @@
 #undef	TARGET_AIX
 #define	TARGET_AIX TARGET_64BIT
 
+/* Copy and paste from linux64.h and freebsd64.h */
+#undef TARGET_CMODEL
+#define TARGET_CMODEL r

Re: gcc behavior on memory exhaustion

2017-08-11 Thread Andrew Roberts

On 10/08/17 10:22, Richard Earnshaw (lists) wrote:

If you think gcc is using an unreasonable amount of memory for a
particular bit of code then please file a bug report, with pre-processed
source code (don't assume that because the sources are part of gcc we
can reproduce your setup).  You should also set the keyword "memory-hog"
on the report.  If you have statistics for older versions of the
compiler, or for other targets that will add evidence for us to look at.

R.

I've submitted bug number 81818 [aarch64 uses 2-3x memory and 2x time of 
arm at -Os, -O2, -O3 (memory-hog) ]for this issue.


All gcc versions from 5.4.0 to 8.0.0 seem to be affected on aarch64.

Andrew



Where Are Release Signatures Located?

2017-08-11 Thread R0b0t1
I have checked a few of the mirrors listed on
https://gcc.gnu.org/mirrors.html. That page lists a few keys that
releases might be signed by, but on all of the mirrors I checked I do
not actually see any signed files. What am I missing?

Thanks in advance,
 R0b0t1.


Re: How to support 64-bit PowerPC -mcmodel=medium?

2017-08-11 Thread Segher Boessenkool
On Fri, Aug 11, 2017 at 11:33:08AM +0200, Sebastian Huber wrote:
> crtstuff.s: Assembler messages:
> crtstuff.s:44: Error: can't resolve `.tm_clone_table' {.tm_clone_table 
> section} - `.LCTOC1' {.toc1 section}
> crtstuff.s:45: Error: can't resolve `__TMC_END__' {*UND* section} - 
> `.LCTOC1' {.toc1 section}

Maybe you want to
#define USE_TM_CLONE_REGISTRY 0
for your subtarget?

I don't see what is the real problem causing your issues, but that
should allow you to get further at least.


Segher