[Bug fortran/31483] New: ICE on fortran Code

[M dot Froehlich at science-computing dot de]

I get an ICE with gfortran on the following code:

$ cat ice.F
  SUBROUTINE PHLOAD (READER,*)
  IMPLICIT NONE
  EXTERNAL READER
  CALL READER (*1)
 1RETURN 1
  END

$ gfortran -S ice.F
ice.F: In function 'phload':
ice.F:1: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2401
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

$ gfortran -v  
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/scr/kuma/froehl/gcc-prefix
--with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib64
--with-mpfr-include=/usr/local/include --with-mpfr-lib=/usr/local/lib64
Thread model: posix
gcc version 4.3.0 20070404 (experimental)

That happens with gfortran from the gcc-4.1.{1,2} as well as with 20070404 svn
trunk version.


-- 
   Summary: ICE on fortran Code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: M dot Froehlich at science-computing dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483

[Bug fortran/31483] ICE on fortran Code

[M dot Froehlich at science-computing dot de]

--- Comment #2 from M dot Froehlich at science-computing dot de  2007-04-05 
10:56 ---
Great!
Thank you very much!
... open source projects have the fastest response times!

The patch does not apply with 'patch' to gcc-4.1.2, but I could well hand patch
that. Do you expect problems when I apply that small patch to a gcc-4.1.2
release?

Or even better is there any chance to get that backported to the release
branches?

Greetings
   Mathias


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483

[Bug libstdc++/37455] New: Code bloat for ostream.widen('\n')

[M dot Froehlich at science-computing dot de]

Using
gcc (GCC) 4.4.0 20080909 (experimental)
with optimization level -O3 to compile the attached c++ or .ii file, I get a
huge amount of assembly code.
See the attached source, precompiled source and assembly files.

If compiled with -Os or -O2 code size is way less.

The inlined code that appears to produce that sse instruction storm appears to
originates from ctype::_M_widen_init in bits/locale_facets.h around line
1169.

I am not sure if this is a compiler/optimizer/inliner problem or if libstdc++
is just unlucky implementing the iostream/locale stuff. Since g++ compiles much
better overall optimized code with 4.4 compared to oprevious versions, I hope
that this can be fixed in libstdc++. Just my 2 cent ...

Thanks!

Mathias Fröhlich


-- 
   Summary: Code bloat for ostream.widen('\n')
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: M dot Froehlich at science-computing dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455

[Bug libstdc++/37455] Code bloat for ostream.widen('\n')

[M dot Froehlich at science-computing dot de]

--- Comment #1 from M dot Froehlich at science-computing dot de  2008-09-10 
06:55 ---
Created an attachment (id=16277)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16277&action=view)
Original c++ code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455

[Bug libstdc++/37455] Code bloat for ostream.widen('\n')

[M dot Froehlich at science-computing dot de]

--- Comment #2 from M dot Froehlich at science-computing dot de  2008-09-10 
06:56 ---
Created an attachment (id=16278)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16278&action=view)
Preprocessed code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455

[Bug libstdc++/37455] Code bloat for ostream.widen('\n')

[M dot Froehlich at science-computing dot de]

--- Comment #3 from M dot Froehlich at science-computing dot de  2008-09-10 
06:56 ---
Created an attachment (id=16279)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16279&action=view)
Generated assembly file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455

[Bug libstdc++/37455] Code bloat for ostream.widen('\n')

[M dot Froehlich at science-computing dot de]

--- Comment #4 from M dot Froehlich at science-computing dot de  2008-09-10 
07:06 ---
Note that the code path in question is called with every

outputstream << std::endl;

Thanks


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455

[Bug libstdc++/37455] Code bloat for ostream.widen('\n')

[M dot Froehlich at science-computing dot de]

--- Comment #6 from M dot Froehlich at science-computing dot de  2008-09-10 
15:38 ---
(In reply to comment #5)
> Yes, but frankly it's unlikely that in 4.4.0 timeframe, also given the ABI
> constraints, we can change the libstdc++ implementation, which admittedly has
> too much code inline in this area, enough to solve this problem. We are just
> unlucky that 4.3.x was less aggressive at -O3, nothing changed lately (and 
> also
> less recently) on the library side...

Ok, one idea I have while reading your comment:
Gcc has that per function optimization attributes - may be an
__attribute__((optimize ('Os'))) or something similar helps for some selected
functions in this area?

Greetings

Mathias


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455

[Bug libstdc++/37455] Code bloat for ostream.widen('\n')

[M dot Froehlich at science-computing dot de]

--- Comment #8 from M dot Froehlich at science-computing dot de  2008-09-10 
16:13 ---
Fine!
Thanks!

Mathias


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455