[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

2019-06-29 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034

--- Comment #4 from Marc Glisse  ---
Does it make a difference if you replace gmp 6.1.2 with a recent snapshot from
https://gmplib.org/download/snapshot/ ?

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-06-29 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #1 from Ian Lance Taylor  ---
As far as I know I don't have access to an S/390 system.  Anything you can do
to narrow down the problem would be helpful.  Like, for example, which function
has the undefined reference?

[Bug fortran/35276] Doc should described how to compile mixed-language programs

2019-06-29 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276

--- Comment #7 from Eric Gallager  ---
(In reply to Thomas Koenig from comment #6)
> (In reply to Eric Gallager from comment #5)
> > (In reply to Jürgen Reuter from comment #4)
> > > It seems that at least Thomas and Dominique believe that this can be 
> > > closed.
> > 
> > with which status?
> 
> We need to extend that chapter with the new status for gcc 9 after
> Paul's fixes have all gone in.
> 
> After that, I we should close this as FIXED.

Have Paul's fixes all gone in yet?

[Bug c++/71637] -Wmisleading-indentation only triggered when using integrated cpp

2019-06-29 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71637

Eric Gallager  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing other diagnostics maintainer (i.e. besides David, since he's already on
this)

[Bug middle-end/47307] Uninitialized in this function: warning for initialized, no warning for uninitialized

2019-06-29 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47307

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

2019-06-29 Thread andrewm.roberts at sky dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034

--- Comment #3 from Andrew Roberts  ---
Created attachment 46535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46535=edit
tmp-divrem_1.s file generated using m4 from divrem_1.asm in gmp/mpn

This is the gmp 6.1.2 version, from the gcc 9.1.0 build directory.

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

2019-06-29 Thread andrewm.roberts at sky dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034

--- Comment #2 from Andrew Roberts  ---
Building 9.1.0 with gmp 6.1.2 using "-v -save-temps" gives:

gcc -v -save-temps -c -DHAVE_CONFIG_H -I. -I../../../gcc-9.1.0/gmp/mpn -I..
-D__GMP_WITHIN_GMP  -I../../../gcc-9.1.0/gmp -DOPERATION_divrem_1 -DNO_ASM -O2
-g -pipe -Wa,--noexecstack tmp-divrem_1.s -o divrem_1.o
gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=gcc
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp
--with-float=hard --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I'
'../../../gcc-9.1.0/gmp/mpn' '-I' '..' '-D' '__GMP_WITHIN_GMP' '-I'
'../../../gcc-9.1.0/gmp' '-D' 'OPERATION_divrem_1' '-D' 'NO_ASM' '-O2' '-g'
'-pipe' '-o' 'divrem_1.o'  '-mfloat-abi=hard' '-mfpu=vfp' '-mtls-dialect=gnu'
'-marm' '-march=armv6+fp'
 as --gdwarf2 -v -I . -I ../../../gcc-9.1.0/gmp/mpn -I .. -I
../../../gcc-9.1.0/gmp -march=armv6 -mfloat-abi=hard -mfpu=vfp -meabi=5
--noexecstack -o divrem_1.o tmp-divrem_1.s
GNU assembler version 2.31.1 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Raspbian) 2.31.1
tmp-divrem_1.s: Assembler messages:
tmp-divrem_1.s:129: Error: selected processor does not support `mls
r1,r4,r8,r11' in ARM mode
tmp-divrem_1.s:145: Error: selected processor does not support `mls
r1,r4,r8,r11' in ARM mode
tmp-divrem_1.s:158: Error: selected processor does not support `mls
r1,r4,r8,r11' in ARM mode
tmp-divrem_1.s:175: Error: selected processor does not support `mls
r1,r4,r3,r8' in ARM mode
tmp-divrem_1.s:209: Error: selected processor does not support `mls
r11,r4,r12,r3' in ARM mode

Whereas building gmp 6.1.2 standalone (./configure ; make) using -v -save-temps
gives:

gcc -v -save-temps -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
-DOPERATION_divrem_1 -O2 -pedantic -fomit-frame-pointer -march=armv8-a
-mfloat-abi=hard -mfpu=neon -mtune=cortex-a72 -Wa,--noexecstack tmp-divrem_1.s
-fPIC -DPIC -o .libs/divrem_1.o
Using built-in specs.
COLLECT_GCC=gcc
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp
--with-float=hard --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I'
'..' '-D' '__GMP_WITHIN_GMP' '-I' '..' '-D' 'OPERATION_divrem_1' '-O2'
'-Wpedantic' '-fomit-frame-pointer'  '-mfloat-abi=hard' '-mfpu=neon'
'-mtune=cortex-a72' '-fPIC' '-D' 'PIC' '-o' '.libs/divrem_1.o'
'-mtls-dialect=gnu' '-marm' '-march=armv8-a+simd'
 as -v -I . -I .. -I .. -march=armv8-a -mfloat-abi=hard -mfpu=neon -meabi=5
--noexecstack -o .libs/divrem_1.o tmp-divrem_1.s
GNU assembler version 2.31.1 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Raspbian) 2.31.1
COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/

[Bug preprocessor/91037] New: #pragma GCC diagnostic ignored "-Wunused-macros" ignored for doubly-defined macro with g++

2019-06-29 Thread f.heckenb...@fh-soft.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91037

Bug ID: 91037
   Summary: #pragma GCC diagnostic ignored "-Wunused-macros"
ignored for doubly-defined macro with g++
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

% cat unused.cpp
#pragma GCC diagnostic ignored "-Wunused-macros"
#define YYUSE
#define YYUSE
YYUSE
% g++ -Wunused-macros unused.cpp
unused.c:2: warning: macro "YYUSE" is not used [-Wunused-macros]

Notably, this only seems to happen in C++, not in C.

It not's like the pragma doesn't work at all. In this program, it correctly
suppresses the warning:

#pragma GCC diagnostic ignored "-Wunused-macros"
#define YYUSE

It also doesn't matter if I omit the last line of the original program. AIUI,
the warning regarding the 2nd definition is correctly suppressed, but regarding
the 1st definition is not.

[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.

2019-06-29 Thread rkx1209dev at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924

--- Comment #3 from Ren Kimura  ---
Hi. Sorry for late. I've just attached more simple one.

PoC file for this bug can be created easily, just generating ELF file and edit
e_shstrndx in ELF header file to 0.

Attached one is built from simple Hello World program.

#include 
int main() {
  printf("Hello World\n");
};

gcc -o memcorrupt_nm-2.30_gcc-9.1.0_gold_simple hello_world.c

Edit e_shtrndx (offset 0x3E) to 0.

Thanks
Ren

(In reply to Martin Liška from comment #1)
> (In reply to Ren Kimura from comment #0)
> > Created attachment 46501 [details]
> > Proof of Concept ELF binary for nm command
> 
> Hello.
> 
> Is the file created with a fuzzer? I can confirm the crash, but the ELF
> container
> looks broken to me:
> 
> $ readelf -S memcorrupt_nm-2.30_gcc-9.1.0_gold 
> readelf: Warning: possibly corrupt ELF file header - it has a non-zero
> section header offset, but no section headers
> readelf: Error: Too many program headers - 0xdeff - the file is not that big
> 
> Can you provide steps how to create such a file?
> 
> Thanks
> 
> > 
> > On several major linux distributions like ubuntu, debian... binutils uses
> > ELF parser from gold linker plugin,
> > /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so instead of libbfd. 
> > I found a memory corruption bug (Heap OOB read) of gold ELF parser linked
> > from latest nm command(2.30). 
> > If input binary file has a zero value string section offset (i.e e_shstrndx
> > == 0.), gold ELF parser try to find string section by
> > simple_object_find_sections() without enough sanitization.
> > 
> > https://github.com/gcc-mirror/gcc/blob/
> > 6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/lto-plugin/lto-plugin.c#L1059
> > 
> > As a result if e_shstrndx is equal to 0, "(eor->shstrndx - 1)" at this line
> > cause integer overflow (a result becomes negative value (unsigned int)-1 ) 
> > https://github.com/gcc-mirror/gcc/blob/
> > 6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/libiberty/simple-object-elf.c#L600
> > 
> > and try to do out of bound access against heap memory, cause memory
> > corruption.
> > 
> > On Ubuntu 18.10 with GCC 9.1.0.
> > 
> > PoC file is attached to this email.
> > Execute PoC:
> > nm ./memcorrupt_nm-2.30_gcc-9.1.0_gold 
> > Segmentation fault (core dumped)
> > 
> > CrashDump:
> > nm --plugin ./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0
> > ./memcorrupt_nm-2.30_gcc-9.1.0_gold
> > Core was generated by `nm --plugin
> > ./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0 ./researc'.   
> > 
> > Program terminated with signal SIGSEGV, Segmentation fault. 
> > 
> > #0  simple_object_fetch_little_64 (buf=0x5678b4bc3640  > memory at address 0x5678b4bc3640>)
> > at ../../libiberty/simple-object-common.h:262   
> > 
> > 262   return (((ulong_type) buf[7] << 56)   
> > 
> > (gdb) bt
> > 
> > #0  simple_object_fetch_little_64 (buf=0x5678b4bc3640  > memory at address 0x5678b4bc3640>)
> > at ../../libiberty/simple-object-common.h:262   
> > 
> > #1  0x7feb2c5b7268 in simple_object_elf_find_sections
> > (sobj=0x5638b4bc3630, pfn=0x7feb2c5b0930 ,  
> > data=0x7ffd5884ca00, err=0x7ffd5884c9f4) at
> > ../../libiberty/simple-object-elf.c:601   
> > #2  0x7feb2c5b0dd5 in claim_file_handler (file=0x7ffd5884cac0,
> > claimed=0x7ffd5884cabc)
> > at ../../lto-plugin/lto-plugin.c:1025   
> > 
> > #3  0x7feb2c49796b in ?? () from
> > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so
> > 
> > #4  0x7feb2c497bef in ?? () from
> > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so
> > 
> > #5  0x7feb2c30880a in bfd_check_format_matches () from
> > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so   
> > #6  0x5638b4012cb0 in ?? ()
> > #7  0x5638b40109e6 in ?? ()
> > #8  0x7feb2c07f09b in __libc_start_main (main=0x5638b4010590, argc=4,
> > argv=0x7ffd5884ceb8, init=,
> > fini=, rtld_fini=,
> > stack_end=0x7ffd5884cea8) at ../csu/libc-start.c:308
> > #9  0x5638b4010a5a in ?? ()
> > ```
> > 
> > Thanks
> > Ren

[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.

2019-06-29 Thread rkx1209dev at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924

--- Comment #2 from Ren Kimura  ---
Created attachment 46534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46534=edit
Proof of Concept ELF binary for nm command (Purified)

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

2019-06-29 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393

Marek Polacek  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #6 from Marek Polacek  ---
*** Bug 91032 has been marked as a duplicate of this bug. ***

[Bug c++/91032] [9/10 Regression] ICE in ocp_convert, at cp/cvt.c:766

2019-06-29 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91032

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Marek Polacek  ---
Started with r260272; most likely a dup.

*** This bug has been marked as a duplicate of bug 90393 ***

[Bug c/91036] New: GCC option -mno-dspr2 blocks the use of dsp r1 instructions

2019-06-29 Thread petrcvekcz at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91036

Bug ID: 91036
   Summary: GCC option -mno-dspr2 blocks the use of dsp r1
instructions
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petrcvekcz at gmail dot com
  Target Milestone: ---

Setup:

GCC 8.3.0 crosscompiler from aarch64 debian sid to mipsel 24kec with DSP ASE

Simple testing code:

#ifdef __mips_dsp
#warning "+++ DSP r1"
#endif

#ifdef __mips_dspr2
#warning "+++ DSP r2"
#endif

#if (__mips_dsp_rev == 1)
#warning "+++ DSP revision is: 1"
#elif (__mips_dsp_rev == 2)
#warning "+++ DSP revision is: 2"
#endif

int main(void) {
asm volatile ("lwx $5,$5($20)\n");
return 0;
}

Tests:

1) No options (compiler built for arch/tune=24kec and -mdsp):
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c 
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
 #warning "+++ DSP r1"
  ^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
 #warning "+++ DSP revision is: 1"
  ^~~

2) With -mdsp option, still OK
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mdsp
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
 #warning "+++ DSP r1"
  ^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
 #warning "+++ DSP revision is: 1"
  ^~~

3) With -mdspr2 option, works OK, lwx _seems_ to be from DSPr1
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mdspr2
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
 #warning "+++ DSP r1"
  ^~~
./no_dspr2_bug.c:6:6: warning: #warning "+++ DSP r2" [-Wcpp]
 #warning "+++ DSP r2"
  ^~~
./no_dspr2_bug.c:12:6: warning: #warning "+++ DSP revision is: 2" [-Wcpp]
 #warning "+++ DSP revision is: 2"
  ^~~

4) With -mno-dspr2 option, fails as no dsp was defined at all, but still the
DSP macros are available
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mno-dspr2
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
 #warning "+++ DSP r1"
  ^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
 #warning "+++ DSP revision is: 1"
  ^~~
/tmp/cceDi2vp.s: Assembler messages:
/tmp/cceDi2vp.s:24: Error: opcode not supported on this processor: mips32r2
(mips32r2) `lwx $5,$5($20)'

5) Options -mno-dspr2 and -mdsp, IMO useful for situations, when you want only
instructions from rev1 subset and not from rev2, fails too:
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mno-dspr2 -mdsp
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
 #warning "+++ DSP r1"
  ^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
 #warning "+++ DSP revision is: 1"
  ^~~
/tmp/ccNYI1Y8.s: Assembler messages:
/tmp/ccNYI1Y8.s:24: Error: opcode not supported on this processor: mips32r2
(mips32r2) `lwx $5,$5($20)'

6) Behavior for -mdspr2 and -mno-dsp (I don't know what it should do, maybe it
should use only new instructions which was added with revision 2?):
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mno-dsp -mdspr2
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
 #warning "+++ DSP r1"
  ^~~
./no_dspr2_bug.c:6:6: warning: #warning "+++ DSP r2" [-Wcpp]
 #warning "+++ DSP r2"
  ^~~
./no_dspr2_bug.c:12:6: warning: #warning "+++ DSP revision is: 2" [-Wcpp]
 #warning "+++ DSP revision is: 2"
  ^~~

[Bug go/91035] New: [10 Regression] gotools fails to build on s390x-linux-gnu

2019-06-29 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

Bug ID: 91035
   Summary: [10 Regression] gotools fails to build on
s390x-linux-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at debian dot org
CC: cmang at google dot com
  Target Milestone: ---

seen with trunk r272790, using a binutils build from trunK:

/<>/build/./gcc/gccgo -B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/s390x-linux-gnu/bin/ -B/usr/lib/gcc-sna
pshot/s390x-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/s390x-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/s390x-linux-gnu/s
ys-include   -g -O2 -I ../s390x-linux-gnu/libgo -static-libstdc++
-static-libgcc -Wl,-z,relro -L ../s390x-linux-gnu/libgo -L ../s3
90x-linux-gnu/libgo/.libs -o buildid
../../src/gotools/../libgo/go/cmd/buildid/buildid.go
../../src/gotools/../libgo/go/cmd/buildi
d/doc.go ../s390x-linux-gnu/libgo/libgotool.a  
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined
reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:827: vet] Error 1
make[4]: *** Waiting for unfinished jobs
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined
reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:829: buildid] Error 1
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined
reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:821: go] Error 1
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined
reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:823: gofmt] Error 1
make[4]: Leaving directory '/<>/build/gotools'
make[3]: *** [Makefile:14968: all-gotools] Error 2
make[3]: Leaving directory '/<>/build'
make[2]: *** [Makefile:25314: bootstrap] Error 2
make[2]: Leaving directory '/<>/build'
T Sat, 29 Jun 2019 10:04:47 +

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

2019-06-29 Thread andrewm.roberts at sky dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034

--- Comment #1 from Andrew Roberts  ---
Configure line used for building gcc 9.1.0:

../gcc-9.1.0/configure --prefix=/usr/local/gcc-9.1.0--program-suffix=
--disa
ble-werror --enable-shared  --enable-threads=posix
--enable-checking=release
 --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style
=gnu --enable-plugin--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj   --enable-clocale=gnu
--d
isable-libstdcxx-pch--enable-install-libiberty --disable-multilib  
--disabl
e-libssp --enable-default-pie --enable-default-ssp 
--host=arm-linux-gnueabi
hf --build=arm-linux-gnueabihf --with-arch=armv6 --with-float=hard
--with-fpu=vf
p --disable-bootstrap

the -with-arch=armv6 is the same as the host compiler.

I would normally build on ArchLinux ARM (but that's not available for Pi4 yet). 
One difference is Raspbian configures its gcc using:

--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf --with-arch=armv6

Basically one gcc configuration for all raspberry pi's.

whereas ArchLinux ARM uses:

--host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf
--with-arch=armv7-a (RPI 3b 32bit)

 --host=armv6l-unknown-linux-gnueabihf --build=armv6l-unknown-linux-gnueabihf
--with-arch=armv6 (RPI Zero)

I normally copy the triplet/arch from the host compiler when building.

If I use the ArchLinx ARM triplet: armv7l-unknown-linux-gnueabihf
and "--with-arch=armv7-a" 
it still fails in the same way, so its not the --with-arch or triplet which is
breaking things.

Alternate (arch linux arm style) config which also fails:

../gcc-9.1.0/configure --prefix=/usr/local/gcc-9.1.0--program-suffix=
--disa
ble-werror --enable-shared  --enable-threads=posix
--enable-checking=release
 --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style
=gnu --enable-plugin--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj   --enable-clocale=gnu
--d
isable-libstdcxx-pch--enable-install-libiberty --disable-multilib  
--disabl
e-libssp --enable-default-pie --enable-default-ssp 
--host=armv7l-unknown-li
nux-gnueabihf --build=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a
--with-
float=hard --with-fpu=vfp --disable-bootstrap

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

2019-06-29 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030

--- Comment #20 from Thomas Koenig  ---
(In reply to David Edelsohn from comment #18)
> For GPFS, the striping unit is 16M.  The 8K buffer size chosen by GFortran
> is a huge performance sink. We have confirmed this with testing.

Could you share some benchmarks on this?  I'd really like if the
gfortran maintainers could form their own judgment on this, based
on numbers.

Here's a benchmark program:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

double walltime (void)
{
  struct timeval TV;
  double elapsed;
  gettimeofday(, NULL);
  elapsed = (double) TV.tv_sec + 1.0e-6*((double) TV.tv_usec);
  return elapsed;
}

#define NAME "out.dat"
#define N 25000

int main()
{
  int fd;
  double *p, *w;
  long i, size, blocksize, left, to_write;
  int bits;
  double t1, t2;
  struct statvfs buf;

  printf ("Test using %e doubles\n", N * 1.0);
  statvfs (".", );
  printf ("Block size of file system: %ld\n", buf.f_bsize);

  p = malloc(N * sizeof (*p));
  for (i=0; i 0)
{
  if (left >= blocksize)
to_write = blocksize;
  else
to_write = left;

  write (fd, w, blocksize * sizeof (double));
  w += to_write;
  left -= to_write;
}
  close (fd);
  t2 = walltime ();
  printf ("%.2f MiB/s\n", N / (t2-t1) / 1048576);
}
  free (p);
  unlink (NAME);

  return 0;
}

And here is some output on my home system (ext4):

Test using 2.50e+08 doubles
Block size of file system: 4096
bs =   1024, 175.81 MiB/s
bs =   2048, 244.40 MiB/s
bs =   4096, 247.27 MiB/s
bs =   8192, 227.46 MiB/s
bs =  16384, 195.55 MiB/s
bs =  32768, 223.14 MiB/s
bs =  65536, 168.95 MiB/s
bs = 131072, 240.70 MiB/s
bs = 262144, 260.39 MiB/s
bs = 524288, 265.38 MiB/s
bs =1048576, 261.67 MiB/s
bs =2097152, 259.94 MiB/s
bs =4194304, 258.71 MiB/s
bs =8388608, 262.19 MiB/s
bs =   16777216, 260.19 MiB/s
bs =   33554432, 263.37 MiB/s
bs =   67108864, 264.47 MiB/s

And here is something on gcc135 (POWER9), also ext4:

Test using 2.50e+08 doubles
Block size of file system: 4096
bs =   1024, 206.76 MiB/s
bs =   2048, 293.66 MiB/s
bs =   4096, 347.13 MiB/s
bs =   8192, 298.23 MiB/s
bs =  16384, 397.51 MiB/s
bs =  32768, 401.86 MiB/s
bs =  65536, 431.83 MiB/s
bs = 131072, 475.88 MiB/s
bs = 262144, 470.09 MiB/s
bs = 524288, 478.84 MiB/s
bs =1048576, 485.68 MiB/s
bs =2097152, 485.33 MiB/s
bs =4194304, 483.96 MiB/s
bs =8388608, 482.88 MiB/s
bs =   16777216, 485.04 MiB/s
bs =   33554432, 483.92 MiB/s
bs =   67108864, 485.55 MiB/s

So, write thoughput sort of seems to level out at ~ 131072 block size,
2**17.

For Fortran, this is only really relevant for unformatted files.

[Bug bootstrap/91034] New: In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

2019-06-29 Thread andrewm.roberts at sky dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034

Bug ID: 91034
   Summary: In tree build of gmp fails on Raspberry Pi4 (ARM
Cortex A72) with `mls r1,r4,r8,r11' not supported in
ARM mode
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewm.roberts at sky dot com
  Target Milestone: ---

When building gcc 9.1.0 (or 8.3.0) on Raspberry Pi 4 (ARM Cortex A72 in 32 bit
mode)
in tree build of gmp 6.1.2 (or 6.1.0) fails to build with:

tmp-divrem_1.s:129: Error: selected processor does not support `mls
r1,r4,r8,r11' in ARM mode

gmp 6.1.2 builds fine outside of gcc, thus its not a straight binutils issue,
but something to do with how gcc is configuring/building gmp.

The same configurations and version builds gcc-9.1.0/8.3.0 fine on Raspberry Pi
Zero and Pi 3b etc.

/proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 3 (v7l)
BogoMIPS: 108.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd08
CPU revision: 3

uname -a
Linux raspberrypi 4.19.50-v7l+ #895 SMP Thu Jun 20 16:03:42 BST 2019 armv7l
GNU/Linux

OS: Raspbian GNU/Linux 10 (buster)

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp
--with-float=hard --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1)

gcc -march=native -Q --help=target
The following options are target specific:
  -mabi=aapcs-linux
  -mabort-on-noreturn   [disabled]
  -mandroid [disabled]
  -mapcs[disabled]
  -mapcs-frame  [disabled]
  -mapcs-reentrant  [disabled]
  -mapcs-stack-check[disabled]
  -march=   armv8-a+crc+simd
  -marm [enabled]
  -masm-syntax-unified  [disabled]
  -mbe32[enabled]
  -mbe8 [disabled]
  -mbig-endian  [disabled]
  -mbionic  [disabled]
  -mbranch-cost=-1
  -mcallee-super-interworking   [disabled]
  -mcaller-super-interworking   [disabled]
  -mcmse[disabled]
  -mcpu=
  -mfix-cortex-m3-ldrd  [disabled]
  -mflip-thumb  [disabled]
  -mfloat-abi=  hard
  -mfp16-format=none
  -mfpu=vfp
  -mglibc   [enabled]
  -mhard-float
  -mlittle-endian   [enabled]
  -mlong-calls  [disabled]
  -mmusl[disabled]
  -mneon-for-64bits [disabled]
  -mpic-data-is-text-relative   [enabled]
  -mpic-register=
  -mpoke-function-name  [disabled]
  -mprint-tune-info [disabled]
  -mpure-code   [disabled]
  -mrestrict-it [disabled]
  -msched-prolog[enabled]
  -msingle-pic-base [disabled]
  -mslow-flash-data [disabled]
  -msoft-float
  -mstructure-size-boundary=8
  -mthumb   [disabled]
  -mthumb-interwork [disabled]
  -mtls-dialect=gnu
  -mtp= cp15
  -mtpcs-frame  [disabled]
  -mtpcs-leaf-frame [disabled]
  -mtune=
  -muclibc  [disabled]
  -munaligned-access 

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

2019-06-29 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030

--- Comment #19 from David Edelsohn  ---
IBM XLF provides an XLFRTEOPTS environment variable, which includes control
over buffer size.  The documentation makes it clear that XLF uses the block
size of the device by default:

buffer_size=size
Specifies the size of I/O buffers in bytes instead of using the block size of
devices. size must be either -1 or an integer value that is greater than or
equal to 4096. The default, -1, uses the block size of the device where the
file resides.
Using this option can reduce the amount of memory used for I/O buffers when an
application runs out of memory because the block size of devices is very large
and the application opens many files at the same time.

Note the following when using this runtime option:
Preconnected units remain unaffected by this option. Their buffer size is the
same as the block size of the device where they reside except when the block
size is larger than 64KB, in which case the buffer size is set to 64KB.
This runtime option does not apply to files on a tape device or logical volume.
Specifying the buffer size with the SETRTEOPTS procedure overrides any value
previously set by the XLFRTEOPTS environment variable or SETRTEOPTS procedure.
The resetting of this option does not affect units that have already been
opened.

https://www.ibm.com/support/knowledgecenter/SSAT4T_16.1.1/com.ibm.xlf1611.lelinux.doc/compiler_ref/rteopts.html

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

2019-06-29 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030

--- Comment #18 from David Edelsohn  ---
For GPFS, the striping unit is 16M.  The 8K buffer size chosen by GFortran is a
huge performance sink. We have confirmed this with testing.

The recommendation from GPFS is that one should query the filesystem with
fstat() and write in chunks of the block size.

Instead of arbitrarily choosing a uniform buffer size of 8K, GFortran would
achieve better I/O performance in general by dynamically querying the
filesystem characteristics and choosing a buffer size tuned to the filesystem.

Presumably one must find some balance of memory consumption if the application
opens a huge number of files.

Or maybe some environment variable to override the buffer size.

IBM XL FORTRAN achieves better performance, even for EXT4, by adapting I/O to
the filesystem block size.

[Bug tree-optimization/91033] New: [10 Regression] ICE in vect_analyze_loop, at tree-vect-loop.c:2416

2019-06-29 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91033

Bug ID: 91033
   Summary: [10 Regression] ICE in vect_analyze_loop, at
tree-vect-loop.c:2416
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20190623 snapshot (r272608) ICEs when compiling the following
testcase extracted from gcc/testsuite/gcc.dg/ipa/pr90555.c w/ -O1 (-O2, -O3,
-Ofast) -march=knl -fopenmp-simd -ftree-parallelize-loops=2:

#define N 1024
int a[N];

void
test_simdlen1 (void)
{
  int i;
  #pragma omp simd simdlen (4)
  for (i = 0; i < N; ++i)
a[i] = a[i] + 1;
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190623 -march=knl -O1
-fopenmp-simd -ftree-parallelize-loops=2 -c pyxioyv3.c
during GIMPLE pass: vect
In function 'test_simdlen1._loopfn.0':
cc1: internal compiler error: in vect_analyze_loop, at tree-vect-loop.c:2416
0x6fcb1a vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-loop.c:2416
0xfbb725 try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vectorizer.c:886
0xfbc3cf vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vectorizer.c:1114

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

2019-06-29 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030

--- Comment #17 from Thomas Koenig  ---
(In reply to David Edelsohn from comment #16)
> libgfortran unix.c:raw_write() will access the WRITE system call with up to
> 2GB of data, which the testcase is using for the native format.
> 
> Should libgfortran I/O buffer at least use sysconf(_SC_PAGESIZE) instead of
> hard coding 8192?

Depends.  I would try not to blow away too much cache for
such an operation.

So far, this problem appears to be limited to POWER, and more
specifically to file systems which are typically used in HPC.

Could you (generic you, people who have access to such systems)
show us some benchmarks which show performance as a function of
block write size?

[Bug c++/81787] [5/6/7/8 Regression] `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

2019-06-29 Thread phd at phd dot re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787

Piotr Henryk Dabrowski  changed:

   What|Removed |Added

 CC||phd at phd dot re

--- Comment #8 from Piotr Henryk Dabrowski  ---
Can we then have a new "#pragma GCC" for changing such options like
-fpermissive?
Or -Werror which I would like to toggle conditionally for a portion of code?

In general: can we have pragma(s) for every gcc command-line switch?
Would that be possible?
We already have diagnostic for warnings, optimize for optimization options.