[Bug c++/90423] New: Breakage with C++ and "-mlong-double-128"

2019-05-10 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90423

Bug ID: 90423
   Summary: Breakage with C++  and "-mlong-double-128"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Compiling the code snippet below with "g++ -mlong-double-128" and running the
executable prints "2" to the console on my machine, which is obviously wrong.
Without the "-mlong-double-128" flag the output is correct.

#include 
#include 

using namespace std;

int main()
  {
  long double v=2.;
  cout << double(sqrt(v)) << endl;
  }

I understand that C++ support for this kind of long doubles may not be
complete, but would it be possible to fail in a more obvious manner?

Reproduced with g++ 8 and trunk on x86_64-pc-linux-gnu.

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-17 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #12 from Martin Reinecke  ---
Created attachment 43961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43961&action=edit
perf annotate output with -march=native

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-17 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #11 from Martin Reinecke  ---
Created attachment 43960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43960&action=edit
perf annotate output without -march=native

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-17 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #9 from Martin Reinecke  ---
Sure!

martin@martin-Latitude-E7450 ~/tmp $ gcc -O3 testcase2.c -lm
martin@martin-Latitude-E7450 ~/tmp $ perf stat ./a.out

 Performance counter stats for './a.out':

   1109,985866  task-clock (msec) #0,999 CPUs utilized  
 2  context-switches  #0,002 K/sec  
 0  cpu-migrations#0,000 K/sec  
 2.000  page-faults   #0,002 M/sec  
 3.155.388.780  cycles#2,843 GHz
 6.717.336.961  instructions  #2,13  insn per cycle 
   979.526.022  branches  #  882,467 M/sec  
38.112  branch-misses #0,00% of all branches

   1,110639187 seconds time elapsed

martin@martin-Latitude-E7450 ~/tmp $ gcc -O3 testcase2.c -march=native -lm
martin@martin-Latitude-E7450 ~/tmp $ perf stat ./a.out

 Performance counter stats for './a.out':

   7724,004864  task-clock (msec) #1,000 CPUs utilized  
86  context-switches  #0,011 K/sec  
 1  cpu-migrations#0,000 K/sec  
 2.004  page-faults   #0,259 K/sec  
22.129.645.853  cycles#2,865 GHz
 6.723.657.441  instructions  #0,30  insn per cycle 
   980.761.202  branches  #  126,976 M/sec  
   171.813  branch-misses #0,02% of all branches

   7,726058359 seconds time elapsed

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-17 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #7 from Martin Reinecke  ---
Here is the output of --verbose:

martin@martin-Latitude-E7450 ~/tmp $ gcc -O3  testcase2.c --verbose -lm -S
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/codes/gccgit/configure --disable-bootstrap
--disable-multilib --prefix=/home/martin/codes/utrunk
--enable-languages=c++,fortran --enable-target=all --enable-checking=release
Thread model: posix
gcc version 8.0.1 20180411 (experimental) [trunk revision
b3ed066d3a5:895af22275d:7d24c3846c904b6e1ffea0bee0c58a9f7bcc23cb] (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-v' '-S' '-mtune=generic' '-march=x86-64'
 /home/martin/codes/utrunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/cc1 -quiet -v
-imultiarch x86_64-linux-gnu testcase2.c -quiet -dumpbase testcase2.c
-mtune=generic -march=x86-64 -auxbase testcase2 -O3 -version -o testcase2.s
GNU C17 (GCC) version 8.0.1 20180411 (experimental) [trunk revision
b3ed066d3a5:895af22275d:7d24c3846c904b6e1ffea0bee0c58a9f7bcc23cb]
(x86_64-pc-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include
 /usr/local/include
 /home/martin/codes/utrunk/include
 /home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (GCC) version 8.0.1 20180411 (experimental) [trunk revision
b3ed066d3a5:895af22275d:7d24c3846c904b6e1ffea0bee0c58a9f7bcc23cb]
(x86_64-pc-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 08c992208389b44fd477c64ce2b4d084
COMPILER_PATH=/home/martin/codes/utrunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/:/home/martin/codes/utrunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/:/home/martin/codes/utrunk/libexec/gcc/x86_64-pc-linux-gnu/:/home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/:/home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/:/home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/home/martin/codes/utrunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-O3' '-v' '-S' '-mtune=generic' '-march=x86-64'

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-17 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #6 from Martin Reinecke  ---
Created attachment 43958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43958&action=edit
assembler output with -march=native

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-17 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #5 from Martin Reinecke  ---
Created attachment 43957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43957&action=edit
assembler output without -march=native

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-17 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #4 from Martin Reinecke  ---
Created attachment 43956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43956&action=edit
reduced test case

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

2018-04-16 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

--- Comment #1 from Martin Reinecke  ---
Just re-tested on an Intel Core i5-4570; on this CPU, there is no performance
degradation.

[Bug tree-optimization/85416] New: Massive performance regression when switching on "-march=native"

2018-04-16 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85416

Bug ID: 85416
   Summary: Massive performance regression when switching on
"-march=native"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 43945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43945&action=edit
Test case

When compiling the attached test case with

g++ -O3 -std=c++14 testcase.cc

and measuring the runtime via

time ./a.out

I get a CPU time of roughly 1.3 seconds

Recompiling with

g++ -O3 -std=c++14 -march=native testcase.cc

increases run time to over 8 seconds.

CPU: Intel Core i5-5300U

This was measured on trunk (gcc version 8.0.1 20180411), but I see similar
performance degradations already in gcc 5.4.

[Bug fortran/77260] New: bogus warning with ENTRY in a function

2016-08-16 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77260

Bug ID: 77260
   Summary: bogus warning with ENTRY in a function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 39460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39460&action=edit
test case

When compiling the test case below, current trunk gfortran warns about "f2"
being unused:

martin@martin-Latitude-E7450 ~/tmp $ gfortran -std=f2008 -W -Wall entry.f90 
entry.f90:11:8:

 entry f2
1
Warning: Fortran 2008 obsolescent feature: ENTRY statement at (1)
entry.f90:9:10:

 integer f2
  1
Warning: Unused variable ‘f2’ declared at (1) [-Wunused-variable]

However, if I comment out the "integer f2" statement, gfortran produces an
error (as I would expect):
martin@martin-Latitude-E7450 ~/tmp $ gfortran -std=f2008 -W -Wall entry.f90 
entry.f90:11:8:

 entry f2
1
Warning: Fortran 2008 obsolescent feature: ENTRY statement at (1)
entry.f90:4:12:

 public f1,f2
1
Error: Contained function ‘f2’ at (1) has no IMPLICIT type
entry.f90:17:4:

 use foo
1
Fatal Error: Can't open module file ‘foo.mod’ for reading at (1): No such file
or directory
compilation terminated.

I think the warning is bogus ... the entry somehow must be given an explicit
return type.
This behaviour happens on trunk and 5.4; I haven't tested other branches so
far.

[Bug c++/71200] [7 regression] ICE (segfault) with -O3

2016-05-19 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71200

--- Comment #3 from Martin Reinecke  ---
In fact, the problem seems to have been patched away very recently.
With a fresh checkout of gcc trunk the test case compiles fine. Sorry for the
noise!

Should I close the bug as resolved/fixed?

[Bug c++/71200] [7 regression] ICE (segfault) with -O3

2016-05-19 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71200

--- Comment #2 from Martin Reinecke  ---
I'm not sure why, but on a different machine I get a more detailed error
output, which might help locating the problem:

martin@noemi-laptop ~/Downloads $ g++ -v -O3 -c testcase.ii 
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/codes/gccgit/configure --disable-bootstrap
--disable-multilib --prefix=/home/martin/codes/utrunk
--enable-languages=c++,fortran --enable-target=all --enable-checking=release
Thread model: posix
gcc version 7.0.0 20160517 (experimental) [trunk revision
28adcc2:7f958dd:77d095c0eb3dcdf4ceca108d745301e8b29fefde] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/martin/codes/utrunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus
-fpreprocessed testcase.ii -quiet -dumpbase testcase.ii -mtune=generic
-march=x86-64 -auxbase testcase -O3 -version -o /tmp/cchF6iTX.s
GNU C++14 (GCC) version 7.0.0 20160517 (experimental) [trunk revision
28adcc2:7f958dd:77d095c0eb3dcdf4ceca108d745301e8b29fefde] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.0.0 20160517 (experimental) [trunk revision
28adcc2:7f958dd:77d095c0eb3dcdf4ceca108d745301e8b29fefde] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5994b8b14bc318f7362472a1db0f260c
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc: In function ‘void
{anonymous}::prepPolyHelper(const std::vector >&, const
std::vector&, std::vector&, bool)’:
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc:275:6: internal compiler
error: Segmentation fault
0xb1972f crash_signal
/home/martin/codes/gccgit/gcc/toplev.c:333
0xc18091 find_uses_to_rename_use
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:379
0xc18311 find_uses_to_rename_use
/home/martin/codes/gccgit/gcc/gimple-expr.h:109
0xc18311 find_uses_to_rename_bb
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:451
0xc1a1d0 find_uses_to_rename
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:479
0xc1a1d0 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:642
0xb8b74e execute
/home/martin/codes/gccgit/gcc/tree-loop-distribution.c:1830
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71200] New: [7 regression] ICE (segfault) with -O3

2016-05-19 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71200

Bug ID: 71200
   Summary: [7 regression] ICE (segfault) with -O3
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 38528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38528&action=edit
test case

Current trunk crashes with a segmentation fault when compiling the attached
test case:

/afs/mpa/data/martin/lsnew/build.linux_gcc/Healpix_cxx>g++ -v -O3 -c
testcase.ii 
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /scratch/martin/gccgit/configure --disable-bootstrap
--prefix=/afs/mpa/home/martin/utrunk --enable-languages=c++,fortran
--enable-target=all --enable-checking=release
Thread model: posix
gcc version 7.0.0 20160518 (experimental) [trunk revision
918cd90:e1d3be4:ab297b31366aae41396b333bbe2d7bc9a408ba13] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /afs/mpa/home/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus
-fpreprocessed testcase.ii -quiet -dumpbase testcase.ii -mtune=generic
-march=x86-64 -auxbase testcase -O3 -version -o /tmp/ccSEE7Bb.s
GNU C++14 (GCC) version 7.0.0 20160518 (experimental) [trunk revision
918cd90:e1d3be4:ab297b31366aae41396b333bbe2d7bc9a408ba13] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.0.0 20160518 (experimental) [trunk revision
918cd90:e1d3be4:ab297b31366aae41396b333bbe2d7bc9a408ba13] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 658ce67c6356d3ab5653424abae932e8
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc: In function 'void
{anonymous}::prepPolyHelper(const std::vector >&, const
std::vector&, std::vector&, bool)':
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc:275:6: internal compiler
error: Segmentation fault
 void prepPolyHelper (const vector &vv, const vector &P,
  ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

With -O2 the code is comiled without complaint.
Also the head of the current 6.1 branch can compile the code with -O3.

I'm sorry, but I currently don't have the time to produce a minimal test case.

[Bug fortran/68241] [meta-bug] Deferred-length character

2016-03-09 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241

Martin Reinecke  changed:

   What|Removed |Added

 CC||mar...@mpa-garching.mpg.de

--- Comment #1 from Martin Reinecke  ---
Should this depend on PR70040 as well?

[Bug fortran/70040] ICE in gimplify.c with deferred-length strings

2016-03-02 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70040

--- Comment #2 from Martin Reinecke  ---
Created attachment 37842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37842&action=edit
further reduced test case

[Bug fortran/70040] ICE in gimplify.c with deferred-length strings

2016-03-02 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70040

--- Comment #1 from Martin Reinecke  ---
I am pretty sure that this used to work on trunk some time ago. Unfortunately I
don't have time for a bisection search at the moment ...

[Bug fortran/70040] New: ICE in gimplify.c with deferred-length strings

2016-03-02 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70040

Bug ID: 70040
   Summary: ICE in gimplify.c with deferred-length strings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 37841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37841&action=edit
test case

Current trunk reports an ICE with the attached test case:

gfortran -v test.f08
Driving: gfortran -v test.f08 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/scratch/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /scratch/martin/gccgit/configure --disable-bootstrap
--prefix=/scratch/martin/utrunk --enable-languages=c++,fortran
--enable-target=all --enable-checking=release
Thread model: posix
gcc version 6.0.0 20160302 (experimental) [trunk revision
dd4bd26:0fb01c5:a2cc9e8e2c74db1cdaa9269cde65d0a24f38cabe] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /scratch/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 test.f08
-quiet -dumpbase test.f08 -mtune=generic -march=x86-64 -auxbase test -version
-fintrinsic-modules-path
/scratch/martin/utrunk/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o
/tmp/ccL8StDt.s
GNU Fortran (GCC) version 6.0.0 20160302 (experimental) [trunk revision
dd4bd26:0fb01c5:a2cc9e8e2c74db1cdaa9269cde65d0a24f38cabe] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.0 20160302 (experimental) [trunk revision
dd4bd26:0fb01c5:a2cc9e8e2c74db1cdaa9269cde65d0a24f38cabe] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
test.f08:34:0:

 sourceType(j)%s = sourceType(l-1)%s

internal compiler error: in gimplify_expr, at gimplify.c:11098
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-02-16 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #4 from Martin Reinecke  ---
Any progress on this?

I fear that this might affect quite many people once strings of allocatable
length become more popular in Fortran ... and I sure hope they will!

[Bug fortran/69385] New: [6 regression] ICE on valid with -fcheck=all

2016-01-20 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385

Bug ID: 69385
   Summary: [6 regression] ICE on valid with -fcheck=all
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 37405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37405&action=edit
test case

Compiling the attached testcase using yesterday's trunk with the command line

gfortran -v -c bugrep.f90 -fcheck=all 

produces

/scratch/martin/mysvn/Crash_polish>gfortran -v -c bugrep.f90 -fcheck=all 
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: /scratch/martin/gccgit/configure --disable-bootstrap
--prefix=/scratch/martin/utrunk --enable-languages=c++,fortran
--enable-target=all --enable-checking=release
Thread model: posix
gcc version 6.0.0 20160118 (experimental) [trunk revision
6ccd18c:cc8cc97:131468370faeb6ea8a1d21081d7e6a593bf40170] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-fcheck=all' '-mtune=generic' '-march=x86-64'
 /scratch/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 bugrep.f90
-quiet -dumpbase bugrep.f90 -mtune=generic -march=x86-64 -auxbase bugrep
-version -fcheck=all -fintrinsic-modules-path
/scratch/martin/utrunk/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o
/tmp/ccvKz9Tq.s
GNU Fortran (GCC) version 6.0.0 20160118 (experimental) [trunk revision
6ccd18c:cc8cc97:131468370faeb6ea8a1d21081d7e6a593bf40170] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.0 20160118 (experimental) [trunk revision
6ccd18c:cc8cc97:131468370faeb6ea8a1d21081d7e6a593bf40170] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
bugrep.f90:18:0:

   allocate(getCmdLine(command_argument_count()))


internal compiler error: in wide_int_to_tree, at tree.c:1486
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


If "-fcheck=all" is omitted, the code is compiled without complaint.

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

2015-11-30 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68540

--- Comment #8 from Martin Reinecke  ---
I confirm that I can build again when provoding the ISL 0.15 sources withon the
gcc/ directory.

In order to save others some head-scratching, would it be possible to update
the ISL version check in the configuration machinery so that it gives a clear
error when encountering an ISL version that is too old?

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

2015-11-27 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68540

--- Comment #2 from Martin Reinecke  ---
OK, the problematic commit appears to be:

Revision 230759 - Directory Listing
Added Mon Nov 23 14:23:59 2015 UTC (3 days, 23 hours ago) by dje

Correct graphite*.c ISL header file inclusion order.
* system.h: Don't poison calloc and strdup if USES_ISL is defined.
* graphite-dependences.c: Define USES_ISL.  Include ISL header files
after GCC header files and before graphite header files.
* graphite-dependences.c: Same.
* graphite-isl-ast-to-gimple.c: Same.
* graphite-optimize-isl.c: Same.
* graphite-poly.c: Same.
* graphite-scop-detection.c: Same.
* graphite-sese-to-poly.c: Same.
* graphite.c: Same.

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

2015-11-27 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68540

--- Comment #1 from Martin Reinecke  ---
I should probably add that building the trunk was possible without any problems
on Linux Mint until about two weeks ago. Unfortunately I do not know yet how to
isolate the problematic commit ... will look into "git bisect" and post updates
if I have more information.

[Bug bootstrap/68540] New: 6.0 build process broken on Linux Mint, potential include ordering problem

2015-11-25 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68540

Bug ID: 68540
   Summary: 6.0 build process broken on Linux Mint, potential
include ordering problem
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Currently, compiling trunk on Linux Mint 17.2 fails. I'm configuring with 
--disable-multilib  --enable-gold --enable-plugins --disable-bootstrap
--prefix=$DESTDIR --enable-languages=c++,fortran --enable-target=all
--enable-checking=release, and "make" fails with

g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I/home/martin/gcc/gcc -I/home/martin/gcc/gcc/.
-I/home/martin/gcc/gcc/../include -I/home/martin/gcc/gcc/../libcpp/include 
-I/home/martin/gcc/gcc/../libdecnumber
-I/home/martin/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/martin/gcc/gcc/../libbacktrace   -o graphite.o -MT graphite.o -MMD -MP
-MF ./.deps/graphite.TPo /home/martin/gcc/gcc/graphite.c
In file included from /usr/include/c++/4.8/bits/basic_ios.h:37:0,
 from /usr/include/c++/4.8/ios:44,
 from /usr/include/c++/4.8/ostream:38,
 from /usr/include/c++/4.8/iostream:39,
 from /usr/include/isl/int.h:17,
 from /usr/include/isl/ctx.h:16,
 from /usr/include/isl/list.h:13,
 from /usr/include/isl/aff_type.h:4,
 from /usr/include/isl/local_space.h:4,
 from /usr/include/isl/constraint.h:13,
 from /home/martin/gcc/gcc/graphite.c:56:
/usr/include/c++/4.8/bits/locale_facets.h:240:53: error: macro "toupper" passed
2 arguments, but takes just 1
   toupper(char_type *__lo, const char_type* __hi) const
 ^
/usr/include/c++/4.8/bits/locale_facets.h:269:53: error: macro "tolower" passed
2 arguments, but takes just 1
   tolower(char_type* __lo, const char_type* __hi) const
 ^
/usr/include/c++/4.8/bits/locale_facets.h:812:53: error: macro "toupper" passed
2 arguments, but takes just 1
   toupper(char_type *__lo, const char_type* __hi) const
 ^
/usr/include/c++/4.8/bits/locale_facets.h:845:53: error: macro "tolower" passed
2 arguments, but takes just 1
   tolower(char_type* __lo, const char_type* __hi) const
[...]

I manage to bootstrap successfully on other (homegrown) distributions, but
since other gcc branches build OK, I suspect a problematic change on trunk
regarding the inclusion order of headers.

[Bug fortran/68243] New: QOI: no warning about unused entities in submodules

2015-11-07 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68243

Bug ID: 68243
   Summary: QOI: no warning about unused entities in submodules
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 36665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36665&action=edit
test case

When compiling the attached test case with current gfortran trunk, it emits the
warnings:

martin@marvin ~/tmp $ gfortran -W -Wall -c test.f08 
test.f08:12:17:

   integer unused1
 1

Warning: Unused PRIVATE module variable ‘unused1’ declared at (1)
[-Wunused-value]
test.f08:16:0:

   subroutine unused2


Warning: ‘unused2’ defined but not used [-Wunused-function]

But the unused entities "unused3" and "unused4" in the submodule are not
mentioned. As far as I can tell, they are invisible outside the submodule, and
should therefore be provably unused.

[Bug fortran/68237] ICE on invalid with submodules

2015-11-06 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68237

--- Comment #6 from Martin Reinecke  ---
Ah, my bad ... I still had an old m1.smod lying on disk from earlier tests!

This slightly changed test case should demonstrate the problem:

module m1

interface
module subroutine bar
end subroutine
end interface
end module m1

submodule (m1) m2

contains

module procedure foo
end procedure

end submodule

[Bug fortran/68237] ICE on invalid with submodules

2015-11-06 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68237

--- Comment #3 from Martin Reinecke  ---
Sorry, I update my sources via git... I hope this still helps.

[Bug fortran/68237] ICE on invalid with submodules

2015-11-06 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68237

--- Comment #2 from Martin Reinecke  ---
I'm using

gcc version 6.0.0 20151106 (experimental) [trunk revision
2aebc1a:abfaa95:74905ec39301718edde3609ddd97ef8e0f9eb934] (GCC)

[Bug fortran/68237] New: ICE on invalid with submodules

2015-11-06 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68237

Bug ID: 68237
   Summary: ICE on invalid with submodules
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Current trunk gfortran ICEs on the code below instead of producing an eror
message:

module m1
end module

submodule (m1) m2

contains

module procedure foo
end procedure

end submodule

gfortran bug.f08
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/68147] New: Potential incorrect code generation for string self-assignment

2015-10-29 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

Bug ID: 68147
   Summary: Potential incorrect code generation for string
self-assignment
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

Created attachment 36616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36616&action=edit
test case

Current gfortran trunk compiles the following testcase into a binary which
outputs "a.o", where I would naively expect "a.out".

martin@marvin ~ $ gfortran -v -ffree-form test.f
Driving: gfortran -v -ffree-form test.f -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/gcc/configure --disable-multilib --enable-gold
--enable-plugins --prefix=/home/martin/ugcc --enable-languages=c++,fortran
--enable-target=all --enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 test.f -quiet
-dumpbase test.f -mtune=generic -march=x86-64 -auxbase test -version
-ffree-form -fintrinsic-modules-path
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o /tmp/cco9Tqxj.s
GNU Fortran (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o /tmp/ccwxULsf.o /tmp/cco9Tqxj.s
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.24
Reading specs from
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
COMPILER_PATH=/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-ffree-form' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/collect2 -plugin
/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/liblto_plugin.so
-plugin-opt=/home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccCtMKpb.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath
-plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/crtbegin.o
-L/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0
-L/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/../../.. /tmp/ccwxULsf.o
-lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/crtend.o
/us

[Bug fortran/68076] New: f95i reports "out of memory" on simple testcase

2015-10-24 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68076

Bug ID: 68076
   Summary: f95i reports "out of memory" on simple testcase
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 36572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36572&action=edit
test case

When compiling the following module, gfortran crashes with an "out of memory"
diagnostic:

martin@marvin ~/lsnew $ gfortran -v -std=f2003 -c testcase.f03 
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/gcc/configure --disable-multilib --enable-gold
--enable-plugins --prefix=/home/martin/ugcc --enable-languages=c++,fortran
--enable-target=all --enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=f2003' '-c' '-mtune=generic' '-march=x86-64'
 /home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 testcase.f03
-quiet -dumpbase testcase.f03 -mtune=generic -march=x86-64 -auxbase testcase
-std=f2003 -version -fintrinsic-modules-path
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o /tmp/ccaNNCfs.s
GNU Fortran (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2003 (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

f951: out of memory allocating 30978549264 bytes after a total of 561152 bytes

[Bug tree-optimization/66948] New: Performance regression in bit manipulation code

2015-07-20 Thread mar...@mpa-garching.mpg.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66948

Bug ID: 66948
   Summary: Performance regression in bit manipulation code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 36017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36017&action=edit
Testcase

The attached test code requires significantly more CPU time when compiled with
current trunk, compared to gcc 4.8.4 and the gcc 5 branch.

gcc 4.8.4:
martin@marvin ~/lsnew $ gcc -std=c99 -O3 testcase.c
martin@marvin ~/lsnew $ time ./a.out

real0m4.039s
user0m4.041s
sys 0m0.000s


gcc 5 branch:
martin@marvin ~/lsnew $ gcc -std=c99 -O3 testcase.c
martin@marvin ~/lsnew $  time ./a.out

real0m3.820s
user0m3.822s
sys 0m0.000s

trunk:
martin@marvin ~/lsnew $  gcc -std=c99 -O3 testcase.c
martin@marvin ~/lsnew $ time ./a.out

real0m4.492s
user0m4.493s
sys 0m0.004s

[Bug tree-optimization/53373] New: [4.8 regression] ICE on valid code with -march-native

2012-05-16 Thread mar...@mpa-garching.mpg.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373

 Bug #: 53373
   Summary: [4.8 regression] ICE on valid code with -march-native
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@mpa-garching.mpg.de


Created attachment 27417
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27417
Preprocessed testcase

When compiling the attached testcase on an Intel Core i3-2120 with a recent
trunk version of gcc, the compiler segfaults:

/scratch/martin/mysvn/libpsht3>gcc -v -O2 -march=native -c bug.i
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-unknown-linux-gnu
Configured with: /scratch/martin/gccgit/configure --disable-graphite
--enable-gold --enable-plugins --prefix=/afs/mpa/data/martin/ugcc
--with-libelf=/afs/mpa/data/martin/numlibs64 --enable-languages=c++,fortran
--enable-target=all --enable-checking=release --enable-build-with-cxx
Thread model: posix
gcc version 4.8.0 20120516 (experimental) [trunk revision
a756f44:a2ddc2d:669c9ede91a14c0cc74b38c1ab923146ac3919b2] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O2' '-march=native' '-c'
 /afs/mpa/data/martin/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1
-fpreprocessed bug.i -march=corei7-avx -mcx16 -msahf -mno-movbe -mno-aes
-mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi
-mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm
-mno-hle --param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=3072 -mtune=corei7-avx -quiet -dumpbase bug.i -auxbase bug -O2
-version -o /tmp/ccLcgfAs.s
GNU C (GCC) version 4.8.0 20120516 (experimental) [trunk revision
a756f44:a2ddc2d:669c9ede91a14c0cc74b38c1ab923146ac3919b2]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120516 (experimental) [trunk revision
a756f44:a2ddc2d:669c9ede91a14c0cc74b38c1ab923146ac3919b2], GMP version 5.0.1,
MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.8.0 20120516 (experimental) [trunk revision
a756f44:a2ddc2d:669c9ede91a14c0cc74b38c1ab923146ac3919b2]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120516 (experimental) [trunk revision
a756f44:a2ddc2d:669c9ede91a14c0cc74b38c1ab923146ac3919b2], GMP version 5.0.1,
MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 03c904a1dcafbbea3957ffe55a6c30c7
libfftpack/fftpack.c: In function 'rfftf':
libfftpack/fftpack.c:799:3: internal compiler error: Segmentation fault
   { if(n!=1) rfftf1(n, r, wsave, wsave+n,(size_t*)(wsave+2*n)); }
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


This ICE seems to have been introduced fairly recently. I didn't encounter it a
few days ago.

[Bug tree-optimization/53366] New: wrong code generation by tree vectorizer using AVX

2012-05-15 Thread mar...@mpa-garching.mpg.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366

 Bug #: 53366
   Summary: wrong code generation by tree vectorizer using AVX
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@mpa-garching.mpg.de


Created attachment 27410
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27410
Testcase demonstrating the problem

The attached code is the reduction of a numerical library. It should print
"2.816937e+08" if executed correctly.
Using the current head of the 4.7 branch and trunk, and compiling on an
Intel Core i3-2120 using

gcc testcase.c -std=c99 -g -O3 -march=native -fno-tree-vectorize

everything works as expected.
When omitting the "-fno-tree-vectorize", random results are printed, and a
different number is generated for every run.

The testcase is the result of several hours' reduction. Currently I don't have
time to reduce it further.

[Bug fortran/49472] New: [gfortran, 4.7 regression] Compiler segfault on valid code

2011-06-20 Thread mar...@mpa-garching.mpg.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472

   Summary: [gfortran, 4.7 regression] Compiler segfault on valid
code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@mpa-garching.mpg.de


When trying to compile the code below with gfortran 4.7 and a specific set of
flags, the compiler segfaults:

/scratch/martin/tmp/planck/lsclean>gfortran -v -g -O -ffast-math -c
CAMB/modules.f90
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/afs/mpa/data/martin/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /scratch/martin/gcc/configure --disable-bootstrap
--disable-graphite --enable-gold --enable-plugins
--prefix=/afs/mpa/data/martin/ugcc --with-libelf=/afs/mpa/data/martin/numlibs64
--enable-languages=c++,fortran --enable-target=all --enable-checking=release
Thread model: posix
gcc version 4.7.0 20110620 (experimental) [trunk revision 175202] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-g' '-O' '-ffast-math' '-c' '-mtune=generic'
'-march=x86-64'
 /afs/mpa/data/martin/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951
CAMB/modules.f90 -quiet -dumpbase modules.f90 -mtune=generic -march=x86-64
-auxbase modules -g -O -version -ffast-math -fintrinsic-modules-path
/afs/mpa/data/martin/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/finclude -o
/tmp/ccHb3jKV.s
GNU Fortran (GCC) version 4.7.0 20110620 (experimental) [trunk revision 175202]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.7.0 20110620 (experimental) [trunk revision 175202]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

The code compiles without complaint with gfortran 4.5.2 and the head of the 4.6
branch.


module MassiveNu
  implicit none
private

  integer, parameter :: dl = KIND(1.d0)
  real(dl), dimension(:), allocatable ::  r1,p1,dr1,dp1,ddr1,qdn

  real(dl), parameter :: dq=1._dl
  integer, parameter :: nqmax0=15 !number of q to sample for each l

  integer nqmax

   contains

subroutine Nu_derivs(am,adotoa,rhonu,rhonudot,shearnudot,psi2,psi2dot)
real(dl) psi2(nqmax0),psi2dot(nqmax0)

real(dl) g1(nqmax0+1)
real(dl) adotoa,rhonu,rhonudot,shearnudot
real(dl) aq,q,v,d,aqdot,vdot,g0
real(dl), intent(IN) :: am
integer iq

do iq=2,(nqmax0+1)
q=(iq-1.5d0)*dq
aq=am/q
aqdot=aq*adotoa
v=1._dl/sqrt(1._dl+aq*aq)
vdot=-aq*aqdot/(1._dl+aq*aq)**1.5d0
g1(iq)=qdn(iq-1)*(psi2dot(iq-1)*v+psi2(iq-1)*vdot)
end do
call splint(g1,g0,nqmax0+1)

end subroutine Nu_derivs

  end module MassiveNu

[Bug other/47167] Performance regression in numerical code

2011-01-19 Thread mar...@mpa-garching.mpg.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167

--- Comment #9 from Martin Reinecke  2011-01-19 
17:26:31 UTC ---
(In reply to comment #8)
> Can you check if the following patch solves your problem?

Yes, this patch gets performance back to normal on the 4.5 branch and on trunk.
Great!

> The differences in GIMPLE of the patch do not explain the code-differences
> though, so it might be just bad luck that the patch regressed things for
> you.  I can see other unwanted differences though.

I would of course be happy if the code generation would be less "erratic", and
if the nice performance I'm seeing does not depend on my luck ;)
So if I can do anything to help optimizing this kind of code more consistently,
please let me know! Of course, I'm more into numerics than into compiler
writing ...

[Bug other/47167] Performance regression in numerical code

2011-01-19 Thread mar...@mpa-garching.mpg.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167

--- Comment #7 from Martin Reinecke  2011-01-19 
14:16:18 UTC ---
OK, I located the problematic commit, at least on the 4.5 branch: it's revision
number 167492 (fix for PR tree-optimization/46806).

Between revisions 167491 and 167492 the CPU time for the testcase2.c jumps from
4.7s to 5.4s.

Do you think that anything can be done about this regression?

[Bug other/47167] Performance regression in numerical code

2011-01-05 Thread mar...@mpa-garching.mpg.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167

--- Comment #1 from Martin Reinecke  2011-01-05 
14:42:20 UTC ---
Created attachment 22904
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22904
shorter test case

More compact test case; the hot spot is marked with "CRITICAL LOOP".
Compile with "gcc -O2 -fomit-frame-pointer testcase2.c -lm" and
test using "time ./a.out".

[Bug other/47167] New: Performance regression in numerical code

2011-01-04 Thread mar...@mpa-garching.mpg.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167

   Summary: Performance regression in numerical code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@mpa-garching.mpg.de


Created attachment 22897
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22897
test case

When compiling the attached testcase on a machine with a Core 2 Duo E8500 CPU
and 64bit Linux using

gcc -O2 -fomit-frame-pointer testcase.i -lm

the results with gcc 4.5.1 are

Testing map analysis accuracy.
lmax=2047, 0 iterations, spin=0

Testing ECP grid (4096 rings, 4096 pixels/ring, 16777216 pixels)

iteration 0:
wall time for alm2map: 8.811477s
wall time for map2alm: 9.204556s
component 0: rms 1.390734e-13, maxerr 1.582512e-12

However, with current trunk one obtains

Testing map analysis accuracy.
lmax=2047, 0 iterations, spin=0

Testing ECP grid (4096 rings, 4096 pixels/ring, 16777216 pixels)

iteration 0:
wall time for alm2map: 9.518667s
wall time for map2alm: 9.780509s
component 0: rms 1.390734e-13, maxerr 1.582512e-12

The numerical result is identical, but the code generated by the more recent
compiler is noticeably slower.

Reducing the test case is unfortunately not trivial; the computational hot
spots are located in pshtd_inner_loop() and Ylmgen_recalc_Ylm_sse2().

Please let me know if I can provide further information.