[Bug fortran/58007] New: ICE -- free_pi_tree(): Unresolved fixup, depends on order of module inclusion

[shapero at uw dot edu]

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

Bug ID: 58007
   Summary: ICE -- free_pi_tree(): Unresolved fixup, depends on
order of module inclusion
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shapero at uw dot edu

I have a moderate-size code I've been developing in Fortran 2003. I've tried to
reproduce it with small test cases to no avail -- perhaps I can give a link to
my git repository with instructions?


The following should work just fine:

git clone https://github.com/danshapero/fempack.git
git checkout e7547abe131b5c0e137fb0327069a75fcfed5d90
make libs


However, make the following change to src/linalg/linalg.f90:

-use bsr
 use ellpack
 use csr
+use bsr

and the following error results:

Internal Error at (1):
free_pi_tree(): Unresolved fixup
make: *** [src/linalg/linalg.o] Error 1

If it makes a difference, I'm using polymorphism somewhat extensively.


I've seen the following bug reports with similar behavior before: 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015
In 47546, it's suggested that the error can be fixed by using implicit instead
of explicit shape arrays; all my arrays are implicit shape, so it's not that.
I'm compiling with just the -J flag; in 53015 it was suggested that using both
-I and -J can contribute to the problem.

While I might be able to make my code compile by cramming a bunch of modules
all together, it would make everything less, well, modular. Not desirable.

Hope the instructions were helpful and thanks for the help!

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #19 from Rich Felker  ---
We are not presently experiencing this issue in musl libc, probably because the
current C memcpy code is sufficiently overcomplicated to avoid getting detected
by the optimizer as memcpy. However, I'm trying to switch to a new simpler
implementation that's much faster when compiled with GCC 4.7.1 (on ARM), but
hit this bug when testing on another system using GCC 4.6.1 (ARM). On the
latter, even -fno-tree-loop-distribute-patterns does not make any difference.
Unless there's a reliable workaround for this bug or at least a known blacklist
of bad GCC versions where this bug can't be worked around, I'm afraid we're
going to have to resort to generating the asm for each supported arch using a
known-good GCC and including that asm in the distribution.

This is EXTREMELY frustrating.

[Bug libstdc++/57914] Memory leak in __cxa_thread_atexit when using thread_local

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

--- Comment #4 from Jason Merrill  ---
And 4.8.2.

[Bug tree-optimization/57993] [4.9 Regression] ICE: verify_ssa failed (definition in block n does not dominate use in block m)

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
More complete fix submitted as
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01326.html.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-27
Summary|internal compiler error: in |[4.9 Regression] ICE: in
   |varpool_get_node, at|varpool_get_node, at
   |cgraph.h:840|cgraph.h:840
 Ever confirmed|0   |1

[Bug tree-optimization/58006] [4.8/4.9 Regression] ICE compiling VegaStrike with -ffast-math -ftree-parallelize-loops=2

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|ICE regression compiling|[4.8/4.9 Regression] ICE
   |VegaStrike on f19 with  |compiling VegaStrike with
   |-ffast-math and |-ffast-math
   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2

--- Comment #4 from Marc Glisse  ---
Confirmed with just -Ofast -ftree-parallelize-loops=2.

#0  __strlen_sse2_pminub () at
../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38
#1  0x00cf064b in get_identifier (text=0x0) at
/data/repos/gcc/trunk/gcc/stringpool.c:111
#2  0x00d96f46 in make_temp_ssa_name (type=0x75fb12a0, stmt=0x0,
name=0x0)
at /data/repos/gcc/trunk/gcc/tree-flow-inline.h:1222
#3  0x00d97ee1 in take_address_of (obj=0x71449f50,
type=0x75fb12a0, entry=0x70ddad58, decl_address=..., 
gsi=0x7fffd4b0) at /data/repos/gcc/trunk/gcc/tree-parloops.c:499
#4  0x00d9841e in eliminate_local_variables_1 (tp=0x71840450,
walk_subtrees=0x7fffd2b8, data=0x7fffd3e0)
at /data/repos/gcc/trunk/gcc/tree-parloops.c:613
#5  0x00f6f75e in walk_tree_1 (tp=0x71840450, func=0xd982f3
, 
data=0x7fffd3e0, pset=0x0, lh=0x0) at
/data/repos/gcc/trunk/gcc/tree.c:10916
#6  0x00a9b35d in walk_gimple_op (stmt=0x71840410,
callback_op=0xd982f3 , 
wi=0x7fffd3e0) at /data/repos/gcc/trunk/gcc/gimple.c:1428
#7  0x00d98727 in eliminate_local_variables_stmt (entry=0x70ddad58,
gsi=0x7fffd4b0, decl_address=...)
at /data/repos/gcc/trunk/gcc/tree-parloops.c:700
#8  0x00d98881 in eliminate_local_variables (entry=0x70ddad58,
exit=0x71b40a80)
at /data/repos/gcc/trunk/gcc/tree-parloops.c:743
#9  0x00d9c358 in gen_parallel_loop (loop=0x70d4bea0,
reduction_list=..., n_threads=2, niter=0x7fffd5f0)
at /data/repos/gcc/trunk/gcc/tree-parloops.c:1864
#10 0x00d9d393 in parallelize_loops () at
/data/repos/gcc/trunk/gcc/tree-parloops.c:2218

[Bug tree-optimization/58006] ICE regression compiling VegaStrike on f19 with -ffast-math and -ftree-parallelize-loops=2

[ermo.gcc.gnu.org at spammesenseless dot net]

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

--- Comment #3 from ermo.gcc.gnu.org at spammesenseless dot net ---
@Paolo:

*sigh* -- I suspected that it wasn't ever going to be as simple as describing
what I did to trigger the ICE.  Sorry for polluting bugzilla with an incomplete
bug-report.

I'll see what I can do about educating myself on the ways of proper gcc
bug-reporting -- you never know if it might come in handy one day. =)

[Bug tree-optimization/58005] missed optimization printf constant string

[dushistov at mail dot ru]

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

--- Comment #4 from Evgeniy Dushistov  ---
>Such an optimization can increase code size
>if the same format string is used with 
>many different arguments,

may be then two fputs calls?

fputs(__PRETTY_FUNCTION__, stdout);
fputs("%s: test1\n" + 2/*skip format*/, stdout);

yeah, still we have two calls vs one(bad for -Os),
but we not introduce new string constants,
so it is suitable optimization for -Ofast.

In such test:
   for (int i = 0; i < 10; ++i) {
#ifdef OPTIMIZATION
fputs(__PRETTY_FUNCTION__, stdout);
fputs("%s: test1\n" + 2, stdout);
#else
printf("%s: test1\n", __PRETTY_FUNCTION__);
#endif
}

fputs win with 
real0m0.005s
user0m0.000s
sys 0m0.000s

vs printf
real0m0.011s
user0m0.010s
sys 0m0.000s

[Bug c++/58006] ICE regression compiling VegaStrike on f19 with -ffast-math and -ftree-parallelize-loops=2

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-07-27
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Per the bug reporting instructions, please attach a preprocessed reproducer. If
at all possible, please do your best to reduce it to a manageable size:
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

[Bug c++/58006] ICE regression compiling VegaStrike on f19 with -ffast-math and -ftree-parallelize-loops=2

[ermo.gcc.gnu.org at spammesenseless dot net]

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

--- Comment #2 from ermo.gcc.gnu.org at spammesenseless dot net ---
Created attachment 30564
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30564&action=edit
preprocessed source

[Bug rtl-optimization/57921] Alias change causes perl from SPEC 2006 to abort on MIPS

[dgilmore at mips dot com]

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

Doug Gilmore  changed:

   What|Removed |Added

 CC||dgilmore at mips dot com

--- Comment #6 from Doug Gilmore  ---
I wonder if this should be marked as a duplicate of bug 33383?

[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Chris Gilbreth from comment #0)
> (Is this valid Fortran?)

First, it is definitely a bug - internal compiler errors are always a bug.

Regarding the validity: The number z'0F00F0008001' = 1081127795507068929 is
too large for a (signed) 32-bit integer. Hence, the compiler complains. The
Fortran standard does not provide a real answer to what value is should have
and the code is, hence, invalid

However, with -fno-range-check the compiler is requested to ignore the overflow
and, for a given platform, the is an expected value, given how overflows are
handled.

* * *

The code fails at the assert:

convert_mpz_to_unsigned (mpz_t x, int bitsize)
...
  if (mpz_sgn (x) < 0)
...
  else
{
  /* Confirm that no bits above the signed range are set.  */
  gcc_assert (mpz_scan1 (x, bitsize-1) == ULONG_MAX);
}

Namely, the possibility that the input value is - on purpose - overflowing is
not handled.

[Bug c++/58006] New: ICE regression compiling VegaStrike on f19 with -ffast-math and -ftree-parallelize-loops=2

[ermo.gcc.gnu.org at spammesenseless dot net]

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

Bug ID: 58006
   Summary: ICE regression compiling VegaStrike on f19 with
-ffast-math and -ftree-parallelize-loops=2
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ermo.gcc.gnu.org at spammesenseless dot net

When trying to compile rev. 13636 of VegaStrike (using the CMake build method)
with gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1), g++ ICEs on the following
compilation target on both a C2D E7500 and an AMD Athlon II 240e running
fedora19 x86_64:

[ermo@sheila build]$ make
/usr/bin/cmake -H/home/ermo/VegaStrike/trunk/vegastrike
-B/home/ermo/VegaStrike/trunk/vegastrike/build --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/ermo/VegaStrike/trunk/vegastrike/build/CMakeFiles
/home/ermo/VegaStrike/trunk/vegastrike/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
make -f CMakeFiles/OPcollide.dir/build.make CMakeFiles/OPcollide.dir/depend
make[2]: Entering directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
cd /home/ermo/VegaStrike/trunk/vegastrike/build && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /home/ermo/VegaStrike/trunk/vegastrike
/home/ermo/VegaStrike/trunk/vegastrike
/home/ermo/VegaStrike/trunk/vegastrike/build
/home/ermo/VegaStrike/trunk/vegastrike/build
/home/ermo/VegaStrike/trunk/vegastrike/build/CMakeFiles/OPcollide.dir/DependInfo.cmake
--color=
make[2]: Leaving directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
make -f CMakeFiles/OPcollide.dir/build.make CMakeFiles/OPcollide.dir/build
make[2]: Entering directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
make[2]: Nothing to be done for `CMakeFiles/OPcollide.dir/build'.
make[2]: Leaving directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
/usr/bin/cmake -E cmake_progress_report
/home/ermo/VegaStrike/trunk/vegastrike/build/CMakeFiles  1 2 3 4 5 6 7 8
[  8%] Built target OPcollide
make -f CMakeFiles/engine_com.dir/build.make CMakeFiles/engine_com.dir/depend
make[2]: Entering directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
cd /home/ermo/VegaStrike/trunk/vegastrike/build && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /home/ermo/VegaStrike/trunk/vegastrike
/home/ermo/VegaStrike/trunk/vegastrike
/home/ermo/VegaStrike/trunk/vegastrike/build
/home/ermo/VegaStrike/trunk/vegastrike/build
/home/ermo/VegaStrike/trunk/vegastrike/build/CMakeFiles/engine_com.dir/DependInfo.cmake
--color=
make[2]: Leaving directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
make -f CMakeFiles/engine_com.dir/build.make CMakeFiles/engine_com.dir/build
make[2]: Entering directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
/usr/bin/cmake -E cmake_progress_report
/home/ermo/VegaStrike/trunk/vegastrike/build/CMakeFiles 
[  8%] Building CXX object
CMakeFiles/engine_com.dir/src/gfx/cockpit_generic.cpp.o
/usr/bin/c++-O2  -mtune=native -march=native -mfpmath=sse -msse3 -mmmx
-ftree-vectorize -ffast-math -fassociative-math -funsafe-math-optimizations
-funroll-loops  -ftree-parallelize-loops=2  -DNV_CUBE_MAP
-DBOOST_PYTHON_NO_PY_SIGNATURES -include config.h -pipe -Wall
-fvisibility=hidden -I/home/ermo/VegaStrike/trunk/vegastrike/src
-I/home/ermo/VegaStrike/trunk/vegastrike/src/cmd
-I/home/ermo/VegaStrike/trunk/vegastrike/build -I/usr/include/python2.7
-I/home/ermo/VegaStrike/trunk/vegastrike/boost/1_53 -I/usr/include/AL
-I/usr/include/SDL -I/usr/include/vorbis -I/usr/include/ogg-o
CMakeFiles/engine_com.dir/src/gfx/cockpit_generic.cpp.o -c
/home/ermo/VegaStrike/trunk/vegastrike/src/gfx/cockpit_generic.cpp
/home/ermo/VegaStrike/trunk/vegastrike/src/gfx/cockpit_generic.cpp: In member
function ‘bool Cockpit::Update()’:
/home/ermo/VegaStrike/trunk/vegastrike/src/gfx/cockpit_generic.cpp:494:6:
internal compiler error: Segmentation fault
 bool Cockpit::Update()
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccnOEb2C.out file, please attach this to
your bugreport.
make[2]: *** [CMakeFiles/engine_com.dir/src/gfx/cockpit_generic.cpp.o] Error 1
make[2]: Leaving directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
make[1]: *** [CMakeFiles/engine_com.dir/all] Error 2
make[1]: Leaving directory `/home/ermo/VegaStrike/trunk/vegastrike/build'
make: *** [all] Error 2
[ermo@sheila build]$ 

It turns out that the minimal repro case is adding just -mtune=native
-march=native -ffast-math -ftree-parallelize-loops=2 to that particular
compilation target.

Note that on fedora18, which uses gcc-4.7.2, the exact same configuration does
not result in an ICE.

Vega Strike build instructions can be found here:

http://wiki.vega-strike.

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  ---
About testing, it would be just matter of extending/updating what Kaveh Ghazi
set up when mpfr/mpc came in.

[Bug tree-optimization/57994] Constant folding of infinity

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
(In reply to jos...@codesourcery.com from comment #7)
> An example of MPC not following all the Annex G special cases is that 
> catanh (1 + i0) is specified in Annex G to return Inf + i0 with 
> divide-by-zero exception, but at least with my MPC installation it returns 
> Inf + iNaN.  I haven't tried to check how MPFR handles special cases; the 
> issue with MPC is simply something I noticed incidentally while fixing 
> glibc libm handling of various  functions.

Thanks (I assume you reported it to MPC, so that will be one fewer issue in a
few years :-). I believe there are far fewer special cases (and thus risks)
with MPFR, but that would indeed require a suitable testsuite for all functions
for which we enable it (at least if MPFR doesn't already have such a testsuite,
and maybe even then, to make sure we call it properly).

> > I was wondering about that last point. Couldn't we replace:
> > 
> > x=sin(Inf);
> > 
> > with:
> > 
> > x=NaN;
> > errno=EDOM; // only if flag_math_errno
> 
> errno is typically a macro

That's why I was mentioning front-end help... There should be ways to set errno
to EDOM faster than calling sin(Inf).

> > volatile double f=NaN+NaN; // if flag_trapping_math, something to raise 
> > invalid
> > (make sure we don't recursively try to propagate the constant there, so 
> > maybe
> > the NaN argument should be volatile)
> 
> I think you mean 0.0 / 0.0 or Inf - Inf or similar; NaN+NaN doesn't raise 
> an exception if the NaNs are quiet NaNs.

Yeah, any of those. I was inspired by glibc, which has for instance:

double
__fdim (double x, double y)
{
  int clsx = fpclassify (x);
  int clsy = fpclassify (y);

  if (clsx == FP_NAN || clsy == FP_NAN
  || (y < 0 && clsx == FP_INFINITE && clsy == FP_INFINITE))
/* Raise invalid flag.  */
return x - y;

which looks like it expects QNaN-QNaN to set the invalid flag.

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
About sin(Inf): I checked that with / without the real_isfinite the expression
evaluated in every case the same, -nan, if I remember correctly. I don't have
more details at the moment. My general point, again, is that the mpfr testsuite
appears to include test which check that +-inf are correctly handled as
arguments to the mathematical functions. Which, hey, doesn't seem a miracle,
after all ;) Remember, I'm thinking as a start, no-nan, no-complex.

[Bug tree-optimization/58005] missed optimization printf constant string

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Such an optimization can increase code size (well, the total size of 
string constants in the program) if the same format string is used with 
many different arguments, so it may not always be a good idea (at least 
with -Os).

[Bug tree-optimization/57994] Constant folding of infinity

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Paolo Carlini from comment #5)
> Today I was thinking that given that, per docs and testsuite (double checked
> yesterday) the mpfr functions are able to cope with +-Inf arguments to the
> mathematical functions and evaluate correctly, gating the various do_mpfr_*
> with !real_isnan instead of real_isfinite doesn't look like taking a big
> risk, now that we are in Stage 1. Alone that would help a lot of code (in
> particular, in the C++ library, which is the original motivating example).
> Note, I'm not thinking replacing real_isfinite in various other places, in
> particular not in do_mpc_* and its helpers (something for the future).
> Comments?

I haven't looked at that code closely enough to say if there is much that needs
changing. Earlier you said that removing the real_isfinite test replaced
sin(Inf) with NaN. Was that with -ffast-math? Without it, the change shouldn't
happen (not without inserting a few extra statements). I am hoping that there
is already code in place that checks if the mpfr calls set errno and calls
mpfr_overflow_p (and family) for possible exceptions, though I somehow doubt
that we test mpfr_inexflag_p or very little propagation would take place.

[Bug tree-optimization/57994] Constant folding of infinity

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
An example of MPC not following all the Annex G special cases is that 
catanh (1 + i0) is specified in Annex G to return Inf + i0 with 
divide-by-zero exception, but at least with my MPC installation it returns 
Inf + iNaN.  I haven't tried to check how MPFR handles special cases; the 
issue with MPC is simply something I noticed incidentally while fixing 
glibc libm handling of various  functions.

> I was wondering about that last point. Couldn't we replace:
> 
> x=sin(Inf);
> 
> with:
> 
> x=NaN;
> errno=EDOM; // only if flag_math_errno

errno is typically a macro

> volatile double f=NaN+NaN; // if flag_trapping_math, something to raise 
> invalid
> (make sure we don't recursively try to propagate the constant there, so maybe
> the NaN argument should be volatile)

I think you mean 0.0 / 0.0 or Inf - Inf or similar; NaN+NaN doesn't raise 
an exception if the NaNs are quiet NaNs.

[Bug tree-optimization/58005] missed optimization printf constant string

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-27
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Confirmed also happens in C (s/cstdio/stdio.h/).

[Bug tree-optimization/58005] missed optimization printf constant string

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #1 from Paolo Carlini  ---
Something for Jakub, I think.

[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-27
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.0, 4.9.0

--- Comment #1 from Tobias Burnus  ---
Confirmed

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Today I was thinking that given that, per docs and testsuite (double checked
yesterday) the mpfr functions are able to cope with +-Inf arguments to the
mathematical functions and evaluate correctly, gating the various do_mpfr_*
with !real_isnan instead of real_isfinite doesn't look like taking a big risk,
now that we are in Stage 1. Alone that would help a lot of code (in particular,
in the C++ library, which is the original motivating example). Note, I'm not
thinking replacing real_isfinite in various other places, in particular not in
do_mpc_* and its helpers (something for the future). Comments?

[Bug c++/58005] New: missed optimization printf constant string

[dushistov at mail dot ru]

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

Bug ID: 58005
   Summary: missed optimization printf constant string
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru

Simple code:

#include 

int main()
{
printf("%s: test1\n", __PRETTY_FUNCTION__);//1
printf("test2\n");//2
return 0;
}

compiled to:

callq  4005a0 <__printf_chk@plt> (1)
and to
callq  400590  for (2)

I think that, because of __PRETTY_FUNCTION__ is known during compile time, it
is also possible converting (1) to "puts" call.

This optimization can help speedup loging functionality.

[Bug c++/58004] Internal compiler error in unify_one_argument, at cp/pt.c:15445

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Paolo Carlini  ---
Same issue, really.

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

[Bug c++/52844] ICE

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||lin90162 at gmail dot com

--- Comment #8 from Paolo Carlini  ---
*** Bug 58004 has been marked as a duplicate of this bug. ***

[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

[olegendo at gcc dot gnu.org]

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

--- Comment #62 from Oleg Endo  ---
(In reply to Laurent Aflonsi from comment #61)
> 
> More generally, I'm surprised to see that optimization at mapping level,
> isn't this a generic problematic that should be handled at rtl dead code
> elimination stage on the T bit register ?

Actually, it is a kind of generic case.  Dead code elimination would not do
these kind of logic folding.  Usually this kind of stuff handled by the combine
pass which can figure out some redundant operations or operations that cancel
each other out.  However, combine's logic is also limited and it the overall T
bit handling is a bit shaky.  That's why I introduced the additional
elimination handling that is done in the split pass after the combine pass on
insns that combine didn't catch.  I didn't want to introduce another rtl pass
just for this and touching the combine pass also didn't seem attractive since
all the other backends depend on its behavior.

Maybe it would be better to switch T_REG from SImode to BImode, which reflects
reality.  This should be relatively straight forward to do.

Another idea would be to try out using CCmode.  There some additional
optimizations done on CCmode.  However, this is a bigger change.

[Bug c++/58004] New: Internal compiler error in unify_one_argument, at cp/pt.c:15445

[lin90162 at gmail dot com]

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

Bug ID: 58004
   Summary: Internal compiler error in unify_one_argument, at
cp/pt.c:15445
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lin90162 at gmail dot com

Code:

// hoge.cpp
template< class T, T... V >
struct L{};

template< class T, class U = L >
struct X;

template< char... V >
struct X< char, L > {};


int main()
{
typename X::type a; // instantiate specialized template class
return 0;
}
// end of hoge.cpp

Error message:
hoge.cpp: In function 'int main()':
hoge.cpp:13:21: internal compiler error: in unify_one_argument, at
cp/pt.c:15445
 typename X::type a; // specialized template instantiation
 ^

hoge.cpp:13:21: internal compiler error: Abort trap: 6
g++-4.8: internal compiler error: Abort trap: 6 (program cc1plus)
[1]37562 abort  g++-4.8 -std=c++11 -Wall -Wextra -O2 hoge.cpp


GCC should occur 'invalid template type argument' error because first template
argument of L should be a type but first template argument of L is a
value.
This internal compiler error seems to occur only in template specialization.

I tested this code in gcc 4.7.3, 4.8.1 and 4.9.0 20130726 and all of them fail.

[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

[vincenzo.innocente at cern dot ch]

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

--- Comment #5 from vincenzo Innocente  ---
confirmed that the patch fixes the issue
c++ -O2 -march=corei7-avx polyAVX.cpp
time ./a.out
10358474048
2.965u 0.001s 0:02.97 99.6%0+0k 0+0io 146pf+0w

[Bug middle-end/54961] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|SUSPENDED   |WAITING

--- Comment #9 from Dominique d'Humieres  ---
This PR disappeared from my tests between revisions 192878 and 193318. Was it
fixed or hidden?

[Bug fortran/58003] New: internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165

[cngilbreth at gmail dot com]

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

Bug ID: 58003
   Summary: internal compiler error: in convert_mpz_to_unsigned,
at fortran/simplify.c:165
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cngilbreth at gmail dot com

The following program triggers an internal compiler error when compiled with
-fno-range-check:

program test
  use iso_fortran_env
  implicit none

  integer, parameter :: wt = int32

  write (*,'(a)') "Testing popcnt ..."
  if (bit_size(1_wt) >= 64) then
 write (*,*) popcnt(int(z'0F00F0008001',wt)) == 10
  end if
  if (bit_size(1_wt) >= 32) then
 write (*,*) popcnt(int(z'800F0001',wt)) == 6
  end if

end program test


(Is this valid Fortran?)


$ gfortran -fno-range-check test.f90
f951: internal compiler error: in convert_mpz_to_unsigned, at
fortran/simplify.c:165

f951: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Abort trap: 6


$ gfortran --version
GNU Fortran (GCC) 4.8.0
Copyright (C) 2013 Free Software Foundation, Inc.

[Bug fortran/54633] ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due to lacking compile-time simplification

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-27
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
The compilers are missing in comment #1:

Program gfortranifort  g95 ftn95 lf95 
minloc1.f90 REJECTED REJECTED REJECTED  REJECTED REJECTED 
minloc2.f90  ICE1  ICE 5389762891 
minval1.f90 REJECTED REJECTED REJECTED  REJECTED REJECTED 
minval2.f90  ICE   ACCVIO  ICE 11 
minval3.f90  17.0, 4 REJECTED REJECTED  REJECTED REJECTED 
minval4.f902   ACCVIO  ICE 11

[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop

[dushistov at mail dot ru]

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

--- Comment #27 from Evgeniy Dushistov  ---
Created attachment 30563
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30563&action=edit
icc -c -Ofast -march=native objdump

[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop

[dushistov at mail dot ru]

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

--- Comment #26 from Evgeniy Dushistov  ---
I try such simple C++ function, compiled in separate object file(-march=native
-Ofast): 

void mult(const double * const __restrict__ A, const double * const
__restrict__ B, double * const __restrict__ C, const size_t N)
{
for (size_t j = 0; j < N; ++j)
for (size_t i = 0; i < N; ++i)
for (size_t k = 0; k < N; ++k)
C[i * N + j] += A[i * N + k] + B[k * N + j];
}

$ time ./test_gcc 
204.80

real0m9.628s
user0m9.620s
sys 0m0.000s

$ time ./test_icc 
204.80

real0m0.637s
user0m0.630s
sys 0m0.000s


Difference 15.2 times

Looks like the difference here:
GCC:
Analyzing loop at mult.cpp:5
Analyzing loop at mult.cpp:6
Analyzing loop at mult.cpp:7

mult.cpp:3: note: vectorized 0 loops in function.

ICC:
mult.cpp(5): (col. 2) remark: PERMUTED LOOP WAS VECTORIZED.
mult.cpp(5): (col. 2) remark: PERMUTED LOOP WAS VECTORIZED.
mult.cpp(5): (col. 2) remark: PERMUTED LOOP WAS VECTORIZED.

[Bug fortran/58000] Accept OPEN( ... NAME=) with -std=legacy

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> For indenting the source code, gfortran warns only with -std=f* or with
> -Wtab.

Please, check the archive.  At one time gfortran would issue a warning
if a tab was used in a nonconforming context.  Too many people were
upset about this, so the -W[no-]tab option, which has a convoluted history,
was the compromise.

> However, for format strings, it always warns - and with -std=f* it even
> turns the warning into an error! (see io.c's next_char_not_space)
> 
> Example:
> 
> 1894  format(   '123')
>   end
> 
> (The tab is before '123'. A tab in the string itself is not warned for.)
> 
> Maybe the best would be to disable this warning with -std=legacy - and refer
> to -std=legacy in the -std=gnu warning?

Tab is not and never has been a member of the Fortran character set.
The above line of code is nonconforming.  Gfortran, IMNSHO, should
always issue an error, but I lost that battle years ago.

[Bug fortran/57991] Enhance "Same actual argument associated" warning (-Waliasing)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Tobias Burnus  ---
FIXED on the trunk (4.9).

[Bug fortran/57991] Enhance "Same actual argument associated" warning (-Waliasing)

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Author: burnus
Date: Sat Jul 27 14:17:01 2013
New Revision: 201286

URL: http://gcc.gnu.org/viewcvs?rev=201286&root=gcc&view=rev
Log:
2013-07-27  Tobias Burnus  

PR fortran/57991
* interface.c (check_some_aliasing): Also warn for intent
* OUT/OUT.

2013-07-27  Tobias Burnus  

PR fortran/57991
* gfortran.dg/warn_alias.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_alias.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57285] [OOP] ICE on invalid: "gfc_array_dimen_size(): Bad dimension" due to SIZE intrinsic with invalid dim on CLASS dummy

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #6 from Mikael Morin  ---
(In reply to janus from comment #4)
> (In reply to janus from comment #3)
> > Why the hell do we disable the dimension check for CLASS variables?
> 
> Seems to be some sort of artifact from the early class-array implementation:
> 
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=182210
> 
Maybe there are other "sort of artifact" to remove?

[Bug fortran/57285] [OOP] ICE on invalid: "gfc_array_dimen_size(): Bad dimension" due to SIZE intrinsic with invalid dim on CLASS dummy

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from janus at gcc dot gnu.org ---
Fixed with the commit below. Closing. Thanks for the report!


Author: janus
Date: Sat Jul 27 12:55:59 2013
New Revision: 201284

URL: http://gcc.gnu.org/viewcvs?rev=201284&root=gcc&view=rev
Log:
2013-07-27  Janus Weil  

PR fortran/57285
* check.c (dim_rank_check): Re-enable this check for CLASS arrays.

2013-07-27  Janus Weil  

PR fortran/57285
* gfortran.dg/class_array_19.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_array_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
(In reply to Thomas Koenig from comment #6)
> Working on it a little bit.

I believe that the middle end prefers the use of ARRAY_RANGE_REF to the use of
memcpy. The reason is that with ARRAY_RANGE_REF it knows what type it has while
memcpy transfers everything into a pointer - and it cannot then simply recover
the value.

For a range-ref example, see class_array_data_assign - or Ada.


For instance, 
b = a(1:12)
can be represented as

  lhs = gfc_get_descriptor_dimension (lhs_desc);
  rhs = gfc_get_descriptor_dimension (rhs_desc);

  lhs = build4_loc (input_location, ARRAY_RANGE_REF, type, lhs,
lhs_offset, NULL_TREE, NULL_TREE);
  rhs = build4_loc (input_location, ARRAY_RANGE_REF, type, rhs,
rhs_offset, NULL_TREE, NULL_TREE);
followed by
  gfc_add_modify (block, lhs, rhs);

Note that the number of elements is contained in the "type". In the example
above, one can use:
  type = TREE_TYPE (lhs)   (add before before the build4_loc call)
as "lhs" is a full array with a known size.

If one doesn't have a full array (or an allocatable array), one has to build
the type oneself - for instance by using:

  type = 
build_array_type (type, build_range_type (gfc_array_index_type,
  gfc_index_zero_node,
  number_of_elements));

where type is either gfc_typenode_for_spec (&expr2->ts) or, e.g.,
  gfc_get_element_type (TREE_TYPE (lhs)).


Disclaimer: The example above should be correct. However, I have not fully
understood how RANGE_REF works, i.e. what the last two arguments (here:
NULL_TREE) do.

[Bug target/12081] Gcc can't be compiled with -mregparm=3

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #25 from Oleg Endo  ---
I've proposed a simpler patch which doesn't require fixing up backend code etc.

http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01315.html

[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #6 from Thomas Koenig  ---
Working on it a little bit.

[Bug fortran/58002] New: [IR tracking] Pointer function results in non pointer context: Shall use a temporary

[burnus at gcc dot gnu.org]

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

Bug ID: 58002
   Summary: [IR tracking] Pointer function results in non pointer
context: Shall use a temporary
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

If "fx()" is a pointer returning function, "fx()" is an expression. Hence, for
   call foo(fx())
the argument should be not the pointer address of fx() but a temporary with the
value of the function result.

Everything becomes messier with Fortran 2008 as calls to pointer-returning
functions count as variables.

gfortran currently does not create a temporary in line with Fortran 2008 (!),
but it should to conform to Fortran 90/95/2003.

See Interpretation Request F08/0089 at
http://www.j3-fortran.org/doc/year/13/13-006Ar1.txt - but also at the
discussion at http://mailman.j3-fortran.org/pipermail/j3/2013-July/006578.html

[Bug fortran/58001] New: Make it possible to silence "Extension: Tab character in format" warning

[burnus at gcc dot gnu.org]

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

Bug ID: 58001
   Summary: Make it possible to silence "Extension: Tab character
in format" warning
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

For indenting the source code, gfortran warns only with -std=f* or with -Wtab.

However, for format strings, it always warns - and with -std=f* it even turns
the warning into an error! (see io.c's next_char_not_space)

Example:

1894  format(   '123')
  end

(The tab is before '123'. A tab in the string itself is not warned for.)

Maybe the best would be to disable this warning with -std=legacy - and refer to
-std=legacy in the -std=gnu warning?

[Bug fortran/58000] New: Accept OPEN( ... NAME=) with -std=legacy

[burnus at gcc dot gnu.org]

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

Bug ID: 58000
   Summary: Accept OPEN( ... NAME=) with -std=legacy
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

Some Fortran compilers supported:
   OPEN(99, NAME='filename')
while the Fortran standard only permits
   OPEN(99, FILE='filename')

I think it would be useful to also permit 'NAME=' with -std=legacy. And to
print a nice error message with -std=f*/gnu, which tells the user that the
proper specifier is "FILE=".

NAME is accepted by default by Absoft, Intel and PGI. (Intel warns with -stand
f95/f03 but still accepts it.) Sun/Oracle have "WARNING: NAME= will be ignored,
because -f77=input/output option is absent" - and accept it silently with
either suboption.

Note: It should be still rejected with -std=gnu as that's only part of legacy
code and given that many compiler do not support it. For instance: g95,
pathf95, gfortran, NAG f95 and crayftn don't.

[Bug fortran/57285] [OOP] ICE on invalid: "gfc_array_dimen_size(): Bad dimension" due to SIZE intrinsic with invalid dim on CLASS dummy

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Why the hell do we disable the dimension check for CLASS variables?

Seems to be some sort of artifact from the early class-array implementation:

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=182210


> Index: gcc/fortran/check.c
> ===
> --- gcc/fortran/check.c   (revision 201253)
> +++ gcc/fortran/check.c   (working copy)
> @@ -608,9 +608,6 @@ dim_rank_check (gfc_expr *dim, gfc_expr *array, in
>if (dim->expr_type != EXPR_CONSTANT)
>  return true;
>  
> -  if (array->ts.type == BT_CLASS)
> -return true;
> -
>if (array->expr_type == EXPR_FUNCTION && array->value.function.isym
>&& array->value.function.isym->id == GFC_ISYM_SPREAD)
>  rank = array->rank + 1;

In any case, this patch regtests cleanly. Will commit as obvious ...

[Bug fortran/57285] [OOP] ICE on invalid: "gfc_array_dimen_size(): Bad dimension" due to SIZE intrinsic with invalid dim on CLASS dummy

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Why the hell do we disable the dimension check for CLASS variables?


Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c(revision 201253)
+++ gcc/fortran/check.c(working copy)
@@ -608,9 +608,6 @@ dim_rank_check (gfc_expr *dim, gfc_expr *array, in
   if (dim->expr_type != EXPR_CONSTANT)
 return true;

-  if (array->ts.type == BT_CLASS)
-return true;
-
   if (array->expr_type == EXPR_FUNCTION && array->value.function.isym
   && array->value.function.isym->id == GFC_ISYM_SPREAD)
 rank = array->rank + 1;

[Bug tree-optimization/57999] New: Missed constant propagation into trampolines

[alexey.tourbin at gmail dot com]

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

Bug ID: 57999
   Summary: Missed constant propagation into trampolines
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexey.tourbin at gmail dot com

Created attachment 30562
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30562&action=edit
mergesort.c

The attached source file is a simplistic mergesort implementation (which
actually works, except for the deliberate assertion failure).  Its basic
structure is as follows.

static inline void msort(void *b, size_t n, const size_t s,
int (*cmp)(), void *t)
{
auto void msort_rec(char *b, size_t n);
void msort_rec(char *b, size_t n)
{  
/* Copying will be inlined */
assert(__builtin_constant_p(s));
...
/* Recursively sort a1 and a2 */
msort_rec(b1, n1);
msort_rec(b2, n2);
...
/* Merge */
...
if (cmp(b1, b2) <= 0) {
n1--;
memcpy(tmp, b1, s);
b1 += s;
...
}
msort_rec(b, n);
}

When the size of the element (size_t s) is a compile-time constant, the
resulting code would benefit greatly from inlining per-element memcpy() calls.
However, gcc fails to propagate the constant size into the trampoline - the
assertion actually fails, and otherwise the resulting code is roughly 2 times
slower.

[Bug tree-optimization/57994] Constant folding of infinity

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
The MPFR documentation does claim that it strictly conforms to annex F (with an
explanation on how to emulate subnormals), though it isn't clear if that claim
only concerns +-*/sqrt or everything.

(In reply to jos...@codesourcery.com from comment #2)
> There are no errno issues - this is an exact zero result, not underflow.  
> But I'm not confident that MPFR follows all the Annex F special cases for 
> infinities and NaNs (and even less confident in MPC following Annex G), 
> and in cases that are errors and should produce exceptions / errno (e.g. 
> sin (Inf)) you do of course need to avoid folding.

I was wondering about that last point. Couldn't we replace:

x=sin(Inf);

with:

x=NaN;
errno=EDOM; // only if flag_math_errno
volatile double f=NaN+NaN; // if flag_trapping_math, something to raise invalid
(make sure we don't recursively try to propagate the constant there, so maybe
the NaN argument should be volatile)

Ok, NaN may not be the most interesting case to propagate, but infinities are
interesting, even when they would give EDOM / FE_OVERFLOW. Though the compiler
might need help from the front-end finding the variable errno and the values
EDOM and FE_OVERFLOW if it needs them explicitly.

Of course, doing the infinity propagation only in the !flag_math_errno &&
!flag_trapping_math (and I guess !flag_rounding_math) case is a natural first
step.