[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #10 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-27 07:15:16 UTC --- The test cases from above still fail (but with a different result): print (ru,g15.2), .099d0 ! 1.0E-01 expected 0.10 print (rc,g15.1), .095d0 ! 1.E-01 expected 0.1 print (rc,g15.2), .0995d0 ! 1.0E-01 expected 0.10 print (ru,g15.3), .0999d0 ! 1.00E-01 expected 0.100 Also, G0.d tests fail in the E formatting case, the chosen format is E25.(d)E3 and not the minimal width required for G0.d: print (rc,g0.4,''), .1234d-3 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d-2 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d-1 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d0 print (rc,g0.4,''), .1234d1 print (rc,g0.4,''), .1234d2 print (rc,g0.4,''), .1234d3 print (rc,g0.4,''), .1234d4 print (rc,g0.4,''), .1234d5 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d6 ! fixed width, not G0.d format print (rc,g0.4,''), .1234d7 ! fixed width, not G0.d format
[Bug target/49184] r174284 breaks darwin bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49184 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Bernd Schmidt bernds at gcc dot gnu.org 2011-05-27 07:20:17 UTC --- Already reported. *** This bug has been marked as a duplicate of bug 49173 ***
[Bug bootstrap/49173] [4.7 Regression] No rule to make target `../../../../work/libgcc/../gcc/libgcc-std.ver', needed by `libgcc.map'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49173 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #9 from Bernd Schmidt bernds at gcc dot gnu.org 2011-05-27 07:20:17 UTC --- *** Bug 49184 has been marked as a duplicate of this bug. ***
[Bug bootstrap/49173] [4.7 Regression] No rule to make target `../../../../work/libgcc/../gcc/libgcc-std.ver', needed by `libgcc.map'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49173 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-27 07:26:30 UTC --- I am still investigating what caused the breakage reported in comment #5, likely revision 174286, but it has nothing to do with this pr that is fixed with the patch in comment #5 (successful bootstrap with it at r174284). Note that $$(libgcc_objdir)/libgcc-std.ver (or $(libgcc_objdir)/libgcc-std.ver) does not work. Don't forget s390 and sh platforms for which I cannot do any test.
[Bug c/49186] New: optimize problem with unsigned long long value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49186
Summary: optimize problem with unsigned long long value.
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: iwama...@nigauri.org
CC: kkoj...@gcc.gnu.org
Host: sh4-linux-gnu
Target: sh4-linux-gnu
Build: sh4-linux-gnu
Hi,
I found optimize problem with unsigned long long value.
I confirmed on gcc-4.4 and 4.6 on debian.
$ gcc-4.4 -v
Using built-in specs.
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--with-multiarch-defaults=sh4-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --with-multilib-list=m4,m4-nofpu --with-cpu=sh4
--enable-checking=release --build=sh4-linux-gnu --host=sh4-linux-gnu
--target=sh4-linux-gnu
Thread model: posix
gcc version 4.4.6 (Debian 4.4.6-3)
$ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=gcc-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sh4-linux-gnu/4.6.1/lto-wrapper
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-6'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=sh4-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-multilib-list=m4,m4-nofpu --with-cpu=sh4 --enable-checking=release
--build=sh4-linux-gnu --host=sh4-linux-gnu --target=sh4-linux-gnu
Thread model: posix
gcc version 4.6.1 20110428 (prerelease) (Debian 4.6.0-6)
$ cat a.c
#include stdio.h
#define Size_t size_t
#define MEM_SIZE Size_t
typedef MEM_SIZE STRLEN;
int main(void)
{
int x = 13;
unsigned long long uv = 0x11ULL;
if (x (STRLEN)( (uv) 0x80 ? 1 : (uv) 0x800 ? 2 : (uv) 0x1 ? 3 :
(uv) 0x20 ? 4 : (uv) 0x400 ? 5 : (uv) 0x8000 ? 6 : (uv)
0x10ULL ? 7 : 13 ))
return 1;
return 0;
}
$ gcc-4.4 -o a a.c
$ ./a ; echo $?
1
$ gcc-4.4 -o a a.c -O1
$ ./a ; echo $?
0
$ gcc-4.6 -o a a.c
$ ./a ; echo $?
1
$ gcc-4.6 -o a a.c -O2
$ ./a ; echo $?
0
[Bug bootstrap/49173] [4.7 Regression] No rule to make target `../../../../work/libgcc/../gcc/libgcc-std.ver', needed by `libgcc.map'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49173 --- Comment #11 from Bernd Schmidt bernds at gcc dot gnu.org 2011-05-27 07:53:53 UTC --- Author: bernds Date: Fri May 27 07:53:51 2011 New Revision: 174321 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174321 Log: PR bootstrap/49173 * config/t-slibgcc-darwin (SHLIB_MAPFILES): Look for libgcc-std.ver in the build directory. * config/s390/t-linux (SHLIB_MAPFILES): Likewise. * config/sh/t-linux (SHLIB_MAPFILES): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/s390/t-linux trunk/libgcc/config/sh/t-linux trunk/libgcc/config/t-slibgcc-darwin
[Bug c++/49176] [4.6 Regression][c++0x] valid code rejected with error: uninitialized const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49176 fabien at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | --- Comment #3 from fabien at gcc dot gnu.org 2011-05-27 07:56:43 UTC --- (In reply to comment #1) are you using 4.6.0 or a build from the 4.6 branch? (please always state the version in bug reports) it seems to be fixed in 4.7 Fabien, any ideas? I guess this is caused by my last checkin (rev 174239), which was for 4.6 only. I'll look into it this afternoon.
[Bug c++/49165] [4.3/4.4/4.5 Regression] ICE on for-loop/throw combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49165
--- Comment #11 from Vijay Rao gcc at portuosus dot com 2011-05-27 07:58:25
UTC ---
Does this fix the situation when the 2nd operand of the conditional operator is
of type int?
extern C void abort ();
int bar (bool x, int y)
{
if (y 10 (x ? 1 : throw 1))
y++;
if (y 20 || (x ? 1 : throw 2))
y++;
return y;
}
int main ()
{
if (bar (true, 0) != 2
|| bar (true, 10) != 11
|| bar (false, 30) != 31)
abort ();
try
{
bar (false, 0);
abort ();
}
catch (int i)
{
if (i != 1)
abort ();
}
try
{
bar (false, 10);
abort ();
}
catch (int i)
{
if (i != 2)
abort ();
}
}
[Bug bootstrap/49173] [4.7 Regression] No rule to make target `../../../../work/libgcc/../gcc/libgcc-std.ver', needed by `libgcc.map'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49173 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #12 from Bernd Schmidt bernds at gcc dot gnu.org 2011-05-27 08:01:42 UTC --- Fixed.
[Bug c++/49187] New: parallel mode compilation broken - unqualified lookup? (bisected)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49187
Summary: parallel mode compilation broken - unqualified lookup?
(bisected)
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@abeckmann.de
CC: ja...@gcc.gnu.org
Parallel mode compilation of the following small test fails in current trunk
(r174320):
g++ -W -Wall -D_GLIBCXX_PARALLEL -c parasort.cc
== 8 =
#include vector
#include algorithm
int main()
{
std::vectorint v;
std::sort(v.begin(), v.end());
}
== 8 =
This regression was introduced in
r173965 | jason | 2011-05-20 20:01:22 +0200 (Fri, 20 May 2011) | 33 lines
PR c++/24163
PR c++/29131
gcc/cp/
* pt.c (tsubst_copy_and_build) [CALL_EXPR]: Avoid repeating
unqualified lookup.
* semantics.c (perform_koenig_lookup): Add complain parm.
...
libstdc++-v3/
* (multiple headers): Explicitly qualify calls to
functions from dependent bases.
...
As this seems to be an intentional change, the parallel mode headers need to be
adjusted as well.
g++ -W -Wall -D_GLIBCXX_PARALLEL -c parasort.cc
In file included from
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/sort.h:44:0,
from
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/algo.h:45,
from
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/algorithm:38,
from
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/algorithm:66,
from parasort.cc:2:
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/multiway_mergesort.h:
In member function 'void __gnu_parallel::_SplitConsistentlytrue, _RAIter,
_Compare, _SortingPlacesIterator::operator()(__gnu_parallel::_ThreadIndex,
__gnu_parallel::_PMWMSSortingData_RAIter*, _Compare, typename
std::iterator_traits_II1::difference_type) const [with _RAIter =
__gnu_cxx::__normal_iteratorint*, std::vectorint , _Compare =
std::lessint, _SortingPlacesIterator = int*, __gnu_parallel::_ThreadIndex =
short unsigned int, typename std::iterator_traits_II1::difference_type = long
int]':
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/multiway_mergesort.h:347:7:
instantiated from 'void
__gnu_parallel::parallel_sort_mwms_pu(__gnu_parallel::_PMWMSSortingData_RAIter*,
_Compare) [with bool __stable = false, bool __exact = true, _RAIter =
__gnu_cxx::__normal_iteratorint*, std::vectorint , _Compare =
std::lessint]'
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/multiway_mergesort.h:462:9:
instantiated from 'void __gnu_parallel::parallel_sort_mwms(_RAIter, _RAIter,
_Compare, __gnu_parallel::_ThreadIndex) [with bool __stable = false, bool
__exact = true, _RAIter = __gnu_cxx::__normal_iteratorint*, std::vectorint
, _Compare = std::lessint, __gnu_parallel::_ThreadIndex = short unsigned
int]'
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/sort.h:103:7:
instantiated from 'void __gnu_parallel::__parallel_sort(_RAIter, _RAIter,
_Compare, __gnu_parallel::multiway_mergesort_exact_tag) [with bool __stable =
false, _RAIter = __gnu_cxx::__normal_iteratorint*, std::vectorint ,
_Compare = std::lessint]'
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/sort.h:183:7:
instantiated from 'void __gnu_parallel::__parallel_sort(_RAIter, _RAIter,
_Compare, __gnu_parallel::default_parallel_tag) [with bool __stable = false,
_RAIter = __gnu_cxx::__normal_iteratorint*, std::vectorint , _Compare =
std::lessint]'
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/algo.h:1772:11:
instantiated from 'void std::__parallel::sort(_RAIter, _RAIter, _Compare,
_Parallelism) [with _RAIter = __gnu_cxx::__normal_iteratorint*,
std::vectorint , _Compare = std::lessint, _Parallelism =
__gnu_parallel::default_parallel_tag]'
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/algo.h:1786:7:
instantiated from 'void std::__parallel::sort(_RAIter, _RAIter) [with _RAIter
= __gnu_cxx::__normal_iteratorint*, std::vectorint ]'
parasort.cc:7:30: instantiated from here
/tmp/bisect47/bisect/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/parallel/multiway_mergesort.h:153:4:
error: 'multiseq_partition' was not declared in this scope, and no declarations
were found by argument-dependent lookup at the point of instantiation
[-fpermissive]
[Bug c++/49176] [4.6 Regression][c++0x] valid code rejected with error: uninitialized const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49176 --- Comment #4 from fabien at gcc dot gnu.org 2011-05-27 08:23:35 UTC --- Is it broken in 4.6.0 before r174239 ?
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-27 08:55:14 UTC --- The scale factor is applied to F editing, but it shouldn't. See Fortran 2008: NOTE 10.20 The scale factor has no effect on output unless the magnitude of the datum to be edited is outside the range that permits effective use of F editing. print (rc,1p,g15.4e2,''), 0.1234 ! 1.2340E-01 expected 0.1234 print (rc,g15.4e2,''), 0.1234 ! 0.1234 Additionally, there is a strange digit mixup in this case: print (rc,-1p,g15.4e2,''), 0.1234 ! 1.0234 expected 0.1234
[Bug target/49186] optimize problem with unsigned long long value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49186 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |target --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 08:55:34 UTC --- Works ok on x86-64 and i?86.
[Bug c++/49176] [4.6 Regression][c++0x] valid code rejected with error: uninitialized const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49176 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-27 08:58:27 UTC --- Just tried -r174238: was already broken.
[Bug c++/49176] [4.6 Regression][c++0x] valid code rejected with error: uninitialized const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49176 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.27 09:00:47 Ever Confirmed|0 |1
[Bug middle-end/49177] [4.7 Regression] FAIL: gcc.dg/vect/fast-math-ifcvt-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49177 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.27 09:05:44 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 09:05:44 UTC --- It's because we no longer fold (float) (or 0.0) to or 0.0 ? 1.0f : 0.0f Mine.
[Bug debug/49047] DW_AT_linkage_name missing for constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49047 --- Comment #4 from dodji at seketeli dot org dodji at seketeli dot org 2011-05-27 09:09:35 UTC --- A candidate patch was posted to http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02044.html
[Bug c++/49187] parallel mode compilation broken - unqualified lookup? (bisected)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49187 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-27 09:34:45 UTC --- yes, the change was intentional but these parts must have been missed, see the thread beginning at http://gcc.gnu.org/ml/libstdc++/2011-05/msg00072.html
[Bug tree-optimization/49170] [4.7 regression] Several libstdc++ tests fail to link on Solaris 8/9: cexp missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49170 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-05-27 10:05:28 UTC --- --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-05-26 13:24:31 UTC --- Rainer, please try: [...] and let me know if it solves the problem. It does: I've bootstrapped i386-pc-solaris2.8 with the patch and both the libstdc++ failures went away, as well as several gfortran ones. Thanks. Rainer
[Bug tree-optimization/49170] [4.7 regression] Several libstdc++ tests fail to link on Solaris 8/9: cexp missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49170 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-27 10:15:37 UTC --- + /* Make sure we have either sincos or cexp. */ + if (!TARGET_HAS_SINCOS !TARGET_C99_FUNCTIONS) +break; + Could you please have a look to pr 31249?
[Bug middle-end/49177] [4.7 Regression] FAIL: gcc.dg/vect/fast-math-ifcvt-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49177 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 10:32:18 UTC --- Author: rguenth Date: Fri May 27 10:32:14 2011 New Revision: 174326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174326 Log: 2011-05-27 Richard Guenther rguent...@suse.de PR middle-end/49177 * fold-const.c (fold_unary_loc): Fold (T)(A CMP B) to A CMP B ? (T) true : (T) false for non-integral types T again. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug middle-end/49177] [4.7 Regression] FAIL: gcc.dg/vect/fast-math-ifcvt-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49177 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 10:33:19 UTC --- Fixed.
[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-27 10:35:52 UTC --- Created attachment 24366 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24366 gcc47-pr49095.patch Untested patch which solves this (for some cases) using peephole2. The reason combiner can't do this is that there are no LOG_LINKS in between the comparison and memory store, those two insns are independent and thus don't ever show up together in the same try_combine call (together with their dependencies). And we generate: movq(%rsi), %rax subq$1, %rax testq%rax, %rax movq%rax, (%rsi) je.L4 instead of movq(%rsi), %rax subq$1, %rax movq%rax, (%rsi) je.L4 because in case of multiple uses, LOG_LINKS are on the first use, and the memory store is before the test during combine (only later scheduling changes it). Thus the test has no LOG_LINKS at all and isn't being attempted to be merged together with the subtraction.
[Bug libfortran/49188] New: Mismatch between -fsign-zero documentation and formatted output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188 Summary: Mismatch between -fsign-zero documentation and formatted output Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The documentation of the -fsign-zero option mentions floating point numbers of value zero with the sign bit set: When enabled, floating point numbers of value zero with the sign bit set are written as negative number in formatted output and treated as negative in the SIGN intrinsic. fno-sign-zero does not print the negative sign of zero values and regards zero as positive number in the SIGN intrinsic for compatibility with F77. Default behavior is to show the negative sign. However the flag also affects the output of numbers with a value other than zero, which have their non-zero digits truncated due to formatting. E.g.: print (rc,f4.1), -0.04 -fsign-zero: -0.0 -fno-sign-zero: 0.0 This fno-sign-zero behaviour is not according to the Fortran standard (a minus sign if the internal value is negative) including F77 which is explicitly mentioned in the documentation. (Or is this referring to a specific, possibly non-Fortran77-compliant compiler named F77?) The only sense this would make is if this option would be restricted to actually do what it says in the documentation, regarding a zero with the sign bit set as a mathematical zero, a non-negative value. In my opinion the formatting routines for real numbers should be changed to only affect zero values. Additionally, the last sentence (Default behavior is to show the negative sign.) should be made more precise (e.g. The option is enabled by default) to reflect that the SIGN intrinsic is also affected by the default setting.
[Bug middle-end/49189] New: [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 Summary: [4.7 regression] infinite recursion in constant folder Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org CC: rguent...@suse.de The patch 2011-05-26 Richard Guenther rguent...@suse.de * fold-const.c (fold_unary_loc): Remove bogus code. has introduced an infinite recursion in the constant folder for the Ada testcase about to be attached. No change after the fix for PR middle-end/49177.
[Bug middle-end/49189] [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-27 10:56:33 UTC --- Created attachment 24367 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24367 Concatenated testcase Run gnatchop on the file. Suitable for inclusion in the gnat.dg testsuite.
[Bug fortran/48887] [OOP] SELECT TYPE: Associate name shall not be a pointer/allocatable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48887 --- Comment #2 from Daniel Kraft domob at gcc dot gnu.org 2011-05-27 10:59:01 UTC --- In match.c:select_type_set_tmp we have around line 4536: if (select_type_stack-selector-ts.type == BT_CLASS CLASS_DATA (select_type_stack-selector)-attr.allocatable) gfc_add_allocatable (tmp-n.sym-attr, NULL); else gfc_add_pointer (tmp-n.sym-attr, NULL); Simply removing those gives ICEs in some SELECT TYPE test cases. In resolve.c:resolve_select_type around line 7937 (the resolve_assoc_var call), st-n.sym shows the respective attributes which lead to the problem later on. Note that it we simply use ASSOCIATE, the attributes are not set (as is expected and should be).
[Bug c++/49187] parallel mode compilation broken - unqualified lookup? (bisected)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49187 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.27 11:03:49 CC|jason at gcc dot gnu.org| AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-27 11:03:49 UTC --- Ok, let me handle this. Note: check-parallel should be more than enough, we don't need a testcase.
[Bug middle-end/49189] [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.27 11:05:24 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 11:05:24 UTC --- Confirmed. Endlessly visiting Breakpoint 6, fold_unary_loc (loc=0, code=TRUTH_NOT_EXPR, type=0x75b7e5e8, op0=0x75b820a0) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:7555 7555 enum tree_code_class kind = TREE_CODE_CLASS (code); (gdb) call debug_generic_expr (op0) (const boolean) ((boolean) ((system__unsigned_types__short_unsigned) v-OBJECT (integer) i) 1) Breakpoint 6, fold_unary_loc (loc=0, code=NOP_EXPR, type=0x75b7e5e8, op0=0x75b83000) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:7555 7555 enum tree_code_class kind = TREE_CODE_CLASS (code); (gdb) call debug_generic_expr (op0) ((boolean) ((system__unsigned_types__short_unsigned) v-OBJECT (integer) i) 1) == 0 (gdb) call debug_generic_expr (type) const boolean Breakpoint 7, fold_binary_loc (loc=0, code=EQ_EXPR, type=0x75b7e5e8, op0=0x75b72e70, op1=0x77ee85e0) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:9280 9280 enum tree_code_class kind = TREE_CODE_CLASS (code); (gdb) call debug_generic_expr (op0) (boolean) ((system__unsigned_types__short_unsigned) v-OBJECT (integer) i) 1 (gdb) call debug_generic_expr (op1) 0 Breakpoint 6, fold_unary_loc (loc=0, code=NOP_EXPR, type=0x75b7e5e8, op0=0x75b72e70) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:7555 7555 enum tree_code_class kind = TREE_CODE_CLASS (code); (gdb) call debug_generic_expr (op0) (boolean) ((system__unsigned_types__short_unsigned) v-OBJECT (integer) i) 1 (gdb) call debug_generic_expr (type) const boolean Breakpoint 6, fold_unary_loc (loc=0, code=TRUTH_NOT_EXPR, type=0x75b7e5e8, op0=0x75b820c8) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:7555 7555 enum tree_code_class kind = TREE_CODE_CLASS (code); ...
[Bug middle-end/49189] [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 11:13:11 UTC --- fold_truth_not_expr canonicalizes !(A 1) to (A 1) == 0 but fold_binary canonicalizes bool == 0 to !bool. A recipie for recursion. fold_truth_not_expr doesn't re-fold its result but its result is fold-converted to bool through which we then end up in that latent cycle.
[Bug middle-end/49189] [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 11:21:09 UTC --- The old code did not re-fold in /* If we have (type) (a CMP b) and type is an integral type, return new expression involving the new type. */ if (COMPARISON_CLASS_P (op0) INTEGRAL_TYPE_P (type)) return fold_build2_loc (loc, TREE_CODE (op0), type, TREE_OPERAND (op0, 0), TREE_OPERAND (op0, 1)); for BOOLEAN_TYPE. It could be argued that re-folding is never necessary here because the comparison does not depend on the type of the boolean result it produces. So I'll disable re-folding here.
[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #24366|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-27 11:58:37 UTC --- Created attachment 24368 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24368 gcc47-pr49095.patch Improved patch with two new peephole2 patterns, which in addition to the earlier: reg0 = mem1; reg0 op= nonmem2; mem1 = reg0; if (reg0 != 0) optimizes also: reg0 op= mem1; mem1 = reg0; if (reg0 != 0) and variant of the first, where all the operations are in QI or HImode, except for op= which is in SImode. Again, the patch has been tested just on this testcase so far.
[Bug c++/49165] [4.3/4.4/4.5 Regression] ICE on for-loop/throw combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49165 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-27 12:30:29 UTC --- Created attachment 24369 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24369 gcc46-pr49165.patch Indeed, c_common_truthvalue_conversion needs to be aware of it too.
[Bug libfortran/49188] Mismatch between -fsign-zero documentation and formatted output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-27 12:31:21 UTC --- (In reply to comment #0) This fno-sign-zero behaviour is not according to the Fortran standard Well, -fno-sign-zero is definitely not according to the Fortran 90+ standard as one there has signed zero. Fortran 77 does not really say anything about signed zeros, thus, some programs assume that there is only one zero, which is positive. However, I think according to the Fortran 77 standard, a negative zero is also a valid implementation choice. (a minus sign if the internal value is negative) including F77 which is explicitly mentioned in the documentation. For cross-reference the quote is from 13.5.9.2.1 F_Editing at ftp://ftp.nag.co.uk/sc22wg5/ARCHIVE/Fortran77.html I think the current behavior is OK. For programs, which do not handle negative zeros, one should never print a minus - independent whether the internal value is exactly zero or only after truncation. If I run your program (w/o rc,) with g77, I get: 0.0 Ditto with ifort (w/ and w/o rc,, unless -assume minus0), pathf95 and pgf90. There are really programs - Fortran programs or post-processing programs, which rely on not printing -0.0 and on the non-conforming SIGN behavior (with regards to negative zeros). Thus, it does not really matter whether -fno-sign-zero breaks the Fortran standard or not, if programs rely on it and if gfortran conforms to the standard by default.
[Bug target/48529] [x32] Testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48529 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-05-27 12:36:21 UTC --- (In reply to comment #7) Objective C failures: FAIL: objc.dg/torture/forward-1.m -O0 -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O1 -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -flto -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -flto -flto-partition=none -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -funroll-loops -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -g -fgnu-runtime execution test FAIL: objc.dg/torture/forward-1.m -Os -fgnu-runtime execution test Those are expected to fail for x32.
[Bug bootstrap/49190] New: [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 Summary: [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: howa...@nitro.med.uc.edu, froy...@codesourcery.com Created attachment 24370 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24370 preprocessed file x86_64-apple-darwin10 fails to bootstrap at revision 174286 with: ... libtool: compile: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/bin/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/lib/ -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/include -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/sys-include -DHAVE_CONFIG_H -I. -I../../../work/libgfortran -iquote../../../work/libgfortran/io -I../../../work/libgfortran/../gcc -I../../../work/libgfortran/../gcc/config -I../../../work/libgfortran/../libquadmath -I../.././gcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT fmain.lo -MD -MP -MF .deps/fmain.Tpo -c ../../../work/libgfortran/fmain.c -fno-common -DPIC -o .libs/fmain.o In file included from ../../../work/libgfortran/libgfortran.h:53:0, from ../../../work/libgfortran/fmain.c:4: ../../../work/libgfortran/../libquadmath/quadmath_weak.h:39:1: internal compiler error: tree check: expected tree that contains 'common' structure, have 'identifier_node' in assemble_alias, at varasm.c:5789 Configured with: ../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-lto I attach the preprocessed file produced with /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ -DHAVE_CONFIG_H -I. -I../../../work/libgfortran -iquote../../../work/libgfortran/io -I../../../work/gcc -I../../../work/gcc/config -I../../../work/libquadmath -I../../gcc -c ../../../work/libgfortran/fmain.c -save-temps which yields [macbook] x86_64-apple-darwin10.7.0/libgfortran% /opt/gcc/build_w/gcc/cc1 fmain.i __sputc __inline_isinff __inline_isinfd __inline_isinf __inline_isfinitef __inline_isfinited __inline_isfinite __inline_isnanf __inline_isnand __inline_isnan __inline_signbitf __inline_signbitd __inline_signbit __inline_isnormalf __inline_isnormald __inline_isnormal _OSSwapInt16 _OSSwapInt32 _OSSwapInt64 cimagq crealq conjq In file included from ../../../work/libgfortran/libgfortran.h:53:0, from ../../../work/libgfortran/fmain.c:4: ../../../work/libquadmath/quadmath_weak.h:39:1: internal compiler error: tree check: expected tree that contains 'common' structure, have 'identifier_node' in assemble_alias, at varasm.c:5789 Revision 174285 is OK (its cc1 compiles fmain.i without any error). Note that I have bootstrapped revision 174295 with Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.7p --enable-languages=c,c++,lto,fortran --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --enable-checking=release --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-lto
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-27 13:12:32 UTC --- The following examples fail: print (rc,g10.2,''), 99.5 ! 10. expected 0.10E+03 print (rc,g10.2,''), 995. ! 1.0E+03 expected 0.10E+04 print (rc,g10.3,''), 999.5 ! 100. expected 0.100E+04 print (rc,g10.3,''), 9995. ! 1.0E+04. expected 0.100E+05
[Bug middle-end/49189] [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 13:13:50 UTC --- Fixed.
[Bug middle-end/49189] [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-27 13:13:34 UTC --- Author: rguenth Date: Fri May 27 13:13:28 2011 New Revision: 174330 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174330 Log: 2011-05-27 Richard Guenther rguent...@suse.de PR middle-end/49189 * fold-const.c (fold_unary_loc): Do not re-fold folding conversions of comparisons. * gnat.dg/bit_packed_array5.adb: New testcase. * gnat.dg/bit_packed_array5.ads: Likewise. Added: trunk/gcc/testsuite/gnat.dg/bit_packed_array5.adb trunk/gcc/testsuite/gnat.dg/bit_packed_array5.ads Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-apple-darwin10, ||sparc-sun-solaris2* Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.27 13:16:31 CC||ro at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-05-27 13:16:31 UTC --- Same problem on Solaris 11/SPARC.
[Bug tree-optimization/49170] [4.7 regression] Several libstdc++ tests fail to link on Solaris 8/9: cexp missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49170 --- Comment #6 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-05-27 13:30:01 UTC --- Author: wschmidt Date: Fri May 27 13:29:57 2011 New Revision: 174331 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174331 Log: Index: gcc/ChangeLog === --- gcc/ChangeLog(revision 174330) +++ gcc/ChangeLog(working copy) @@ -1,3 +1,9 @@ +2011-05-27 Bill Schmidt wschm...@linux.vnet.ibm.com + +PR tree-optimization/49170 +* tree-ssa-math-opts.c (execute_cse_sincos): Add checks for +sincos or cexp. + 2011-05-27 Richard Guenther rguent...@suse.de PR middle-end/49189 Index: gcc/tree-ssa-math-opts.c === --- gcc/tree-ssa-math-opts.c(revision 174330) +++ gcc/tree-ssa-math-opts.c(working copy) @@ -1093,6 +1093,10 @@ execute_cse_sincos (void) CASE_FLT_FN (BUILT_IN_COS): CASE_FLT_FN (BUILT_IN_SIN): CASE_FLT_FN (BUILT_IN_CEXPI): + /* Make sure we have either sincos or cexp. */ + if (!TARGET_HAS_SINCOS !TARGET_C99_FUNCTIONS) +break; + arg = gimple_call_arg (stmt, 0); if (TREE_CODE (arg) == SSA_NAME) cfg_changed |= execute_cse_sincos_1 (arg); Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug middle-end/49189] [4.7 regression] infinite recursion in constant folder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49189 --- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-05-27 13:30:03 UTC --- Author: wschmidt Date: Fri May 27 13:29:57 2011 New Revision: 174331 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174331 Log: Index: gcc/ChangeLog === --- gcc/ChangeLog(revision 174330) +++ gcc/ChangeLog(working copy) @@ -1,3 +1,9 @@ +2011-05-27 Bill Schmidt wschm...@linux.vnet.ibm.com + +PR tree-optimization/49170 +* tree-ssa-math-opts.c (execute_cse_sincos): Add checks for +sincos or cexp. + 2011-05-27 Richard Guenther rguent...@suse.de PR middle-end/49189 Index: gcc/tree-ssa-math-opts.c === --- gcc/tree-ssa-math-opts.c(revision 174330) +++ gcc/tree-ssa-math-opts.c(working copy) @@ -1093,6 +1093,10 @@ execute_cse_sincos (void) CASE_FLT_FN (BUILT_IN_COS): CASE_FLT_FN (BUILT_IN_SIN): CASE_FLT_FN (BUILT_IN_CEXPI): + /* Make sure we have either sincos or cexp. */ + if (!TARGET_HAS_SINCOS !TARGET_C99_FUNCTIONS) +break; + arg = gimple_call_arg (stmt, 0); if (TREE_CODE (arg) == SSA_NAME) cfg_changed |= execute_cse_sincos_1 (arg); Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug rtl-optimization/49088] Combine fails to properly handle zero-extension and signed int constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49088 --- Comment #10 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-05-27 13:38:45 UTC --- Author: hjl Date: Fri May 27 13:38:41 2011 New Revision: 174332 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174332 Log: Properly handle CONST_INT operands. 2011-05-21 H.J. Lu hongjiu...@intel.com PR rtl-optimization/49088 * combine.c (force_to_mode): If X is narrower than MODE and we want all the bits in X's mode, just use the operand when it is CONST_INT. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/combine.c
[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49114 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-05-27 13:39:28 UTC --- Author: hjl Date: Fri May 27 13:39:25 2011 New Revision: 174333 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174333 Log: Properly handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int))) 2011-05-24 H.J. Lu hongjiu...@intel.com PR rtl-optimization/49114 * reload1.c (gen_reload): Properly handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int))) Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/reload1.c
[Bug middle-end/49191] New: gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
Summary: gcc.dg/memcpy-3.c FAILs on SPARC
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org, richard.guent...@gmail.com
Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
Build: sparc-sun-solaris2.*
The new gcc.dg/memcpy-3.c test FAILs on Solaris/SPARC:
FAIL: gcc.dg/memcpy-3.c scan-tree-dump-not optimized memcpy
FAIL: gcc.dg/memcpy-3.c scan-tree-dump-times optimized MEM 1
The dump looks like this:
;; Function get_int (get_int)
get_int (const void * p)
{
int w;
int D.1980;
bb 2:
__builtin_memcpy (w, p_1(D), 4);
D.1980_2 = w;
return D.1980_2;
}
Rainer
[Bug middle-end/48464] [4.7 Regression] @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 --- Comment #6 from Jan-Benedict Glaw jbg...@lug-owl.de 2011-05-27 13:49:51 UTC --- It seems r174123 (= 59813b406b20d7b) not only fixed PR rtl-optimization/48971, but also this issue: 2011-05-13 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/48971 * ira.c (setup_pressure_classes): Don't check register move cost for classes with one registers. Don't add pressure class if there is a pressure class with the same available hard registers. Check contains_reg_of_mode. Fix a typo in collecting temp_hard_regset. Ignore hard registers not belonging to a class. Since this patch, this problem is gone. Thanks!
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
--- Comment #1 from richard.guenther at gmail dot com richard.guenther at
gmail dot com 2011-05-27 13:53:57 UTC ---
On Fri, May 27, 2011 at 3:50 PM, ro at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
Summary: gcc.dg/memcpy-3.c FAILs on SPARC
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org, richard.guent...@gmail.com
Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
Build: sparc-sun-solaris2.*
The new gcc.dg/memcpy-3.c test FAILs on Solaris/SPARC:
FAIL: gcc.dg/memcpy-3.c scan-tree-dump-not optimized memcpy
FAIL: gcc.dg/memcpy-3.c scan-tree-dump-times optimized MEM 1
The dump looks like this:
;; Function get_int (get_int)
get_int (const void * p)
{
int w;
int D.1980;
bb 2:
__builtin_memcpy (w, p_1(D), 4);
D.1980_2 = w;
return D.1980_2;
Is sparc a strict-alignment target? Then that's expected.
Hmm. Not sure we have a dg-effective-target strict-align ...
so you probably have to add some xfails.
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130 --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-05-27 13:55:45 UTC --- Those Comment 0 samples are instead from: /usr/lib/debug/usr/lib64/libwebkitgtk-1.0.so.0.5.2.debug webkitgtk-debuginfo-1.3.10-1.fc14.x86_64
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-05-27 13:59:11 UTC --- Is sparc a strict-alignment target? Then that's expected. It is. Hmm. Not sure we have a dg-effective-target strict-align ... so you probably have to add some xfails. We probably should: we currently have 28 strict-alignment targets. Rainer
[Bug middle-end/48464] [4.7 Regression] @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 Jan-Benedict Glaw jbg...@lug-owl.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Jan-Benedict Glaw jbg...@lug-owl.de 2011-05-27 14:09:30 UTC --- Since this now works for me, I'm closing the bug.
[Bug ada/49192] New: Misleading error message about unknown discriminant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49192 Summary: Misleading error message about unknown discriminant Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: yannick_duch...@yahoo.fr Created attachment 24371 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24371 Example file which produce the erroneous error message Summary: a package defines a type T with an unknown discriminant; if you instantiate an entity of that type, giving it (by inadvertence) a discriminant, then GNATMake will complain “invalid constraint: type has no discriminant”. This message is misleading and confusing for beginners, as the type actual has a discriminated view. The Ada compiler should instead complain the discriminant is unknown, and so any discriminant would fail. Why not: “type discriminant is unknown, any is invalid” ? See attached file a a short source file which reproduce this tiny bug.
[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #6 from Linus Torvalds torva...@linux-foundation.org 2011-05-27 14:15:25 UTC --- Jakub - the patch looks sane, although I don't currently have a gcc build environment to actually test it with, and there is no way I'm going to claim that I follow all the matches and understand why you have that third pattern with SWI12 (but I'm guessing it's because the op and the test are being done in the explicit cast to integer mode). One thing I wanted to check, though: I hope everybody is aware that op $x,mem is not identically the same as mov mem,reg op $x, reg mov reg,mem test reg WRT the carry flag. The test version will always clear the carry flag, while the op version will obviously set it according to the op. For the logical ops, this isn't a problem (they also clear carry), but for add and sub this transformation *will* result in a difference in the C flag. Now, carry is meaningless when talking about compare with zero, so this should all be trivially ok. But I bring it up because it is possible that gcc perhaps still uses the unsigned compare versions with zero. In particular, the thing to look out for would be code like unsigned int *a; if (--*a 0) do_something(); and if the comparison uses jg (unsigned greater than) for the comparison, it will get the wrong end result. Now, unsigned compares against zero are always expressible as ne or eq, so this is not a fundamental problem. In fact, my trivial testing with a few cases seems to imply that gcc already does that conversion to inequality, and you'd obviously have exactly the same issue with eliding the test instruction for the cases you already handle (when things are in registers). So I think everything is fine - but I wanted to mention it explicitly in case it makes you go ooh, yes, there are cases when this is an issue
[Bug c++/42056] ICE with invalid use of auto in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42056 --- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-27 14:21:39 UTC --- Author: paolo Date: Fri May 27 14:21:33 2011 New Revision: 174337 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174337 Log: /cp 2011-05-27 Paolo Carlini paolo.carl...@oracle.com PR c++/42056 * typeck2.c (build_functional_cast): Complain early for invalid uses of 'auto' and set type to error_mark_node. /testsuite 2011-05-27 Paolo Carlini paolo.carl...@oracle.com PR c++/42056 * testsuite/g++.dg/cpp0x/auto25.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/42056] ICE with invalid use of auto in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42056 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-27 14:23:15 UTC --- Fixed for 4.7.0.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-27 14:32:12 UTC --- OK, thanks for test cases, these are very helpful.
[Bug middle-end/49139] always_inline attribute inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 chrbr at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |chrbr at gcc dot gnu.org |gnu.org | --- Comment #6 from chrbr at gcc dot gnu.org 2011-05-27 14:34:05 UTC --- Created attachment 24372 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24372 always generates an error on always_inline failure The attached testcases illustrate the current diagnostics on always_inline failures - success with and without -Winline, although always_inline is not honored gcc fail_always_inline1.c -S -Winline -O0 -fpic gcc fail_always_inline1.c -S -O2 -fpic - error: sorry, unimplemented: with -Winline only gcc fail_always_inline1.c -S -Winline -O2 -fpic - error: sorry, unimplemented without -Winline gcc fail_always_inline2.c -S -fno-early-inlining -O2 or the original c++ attachment in this defect The attached patch always emits an error (and change sorry into error). In particular it fixes the case where the inlining was not honored and not detected. note that the error is emitted even if -Winline is not specified. Since this reflects a misuse of the attribute and it is close to the actual behavior Note that I stepped back on my initial proposal to emit a hint message suggesting to use the inline keyword (if not defined in a C++ class), because there are cases where even with inline the function would not be inlined. Tested with standard bootstrap and regression testing on x86 (with tests modification the diagnostic checks). I also double checked for legacy issues with a full rebuild of a linux distribution. Thanks,
[Bug middle-end/49139] always_inline attribute inconsistencies on failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #7 from chrbr at gcc dot gnu.org 2011-05-27 14:37:42 UTC --- Created attachment 24373 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24373 testcase 1
[Bug middle-end/49139] always_inline attribute inconsistencies on failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #8 from chrbr at gcc dot gnu.org 2011-05-27 14:38:13 UTC --- Created attachment 24374 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24374 testcase 2
[Bug libgcj/49193] New: __sync_xxxx builtins aren't used in sysdep/*/locks.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49193
Summary: __sync_ builtins aren't used in sysdep/*/locks.h
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
sysdep/x86-64/locks.h has
inline static bool
compare_and_swap(volatile obj_addr_t *addr,
obj_addr_t old,
obj_addr_t new_val)
{
char result;
#ifdef __x86_64__
__asm__ __volatile__(lock; cmpxchgq %2, %0; setz %1
: =m(*(addr)), =q(result)
: r (new_val), a(old), m(*addr)
: memory);
#else
__asm__ __volatile__(lock; cmpxchgl %2, %0; setz %1
: =m(*addr), =q(result)
: r (new_val), a(old), m(*addr)
: memory);
#endif
return (bool) result;
}
We can replace them with __sync_ builtins.
[Bug c++/49181] [C++0x] Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49181 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.27 14:42:49 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-27
14:47:08 UTC ---
(In reply to comment #6)
Jakub - the patch looks sane, although I don't currently have a gcc build
environment to actually test it with, and there is no way I'm going to claim
that I follow all the matches and understand why you have that third pattern
with SWI12 (but I'm guessing it's because the op and the test are being done
in
the explicit cast to integer mode).
E.g. in the testcase from the patch, in hcharplus routine peephole2 sees:
(insn 27 6 28 2 (set (reg:QI 0 ax [orig:62 D.3491 ] [62])
(mem/c:QI (reg/v/f:DI 3 bx [orig:64 x ] [64]) [0 *x_1(D)+0 S1 A8]))
pr49095.c:63 66 {*movqi_internal}
(nil))
(insn 28 27 8 2 (parallel [
(set (reg:SI 0 ax [orig:62 D.3491 ] [62])
(plus:SI (reg:SI 0 ax [orig:62 D.3491 ] [62])
(const_int 24 [0x18])))
(clobber (reg:CC 17 flags))
]) pr49095.c:63 249 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 8 28 9 2 (set (mem:QI (reg/v/f:DI 3 bx [orig:64 x ] [64]) [0 *x_1(D)+0 S1
A8])
(reg:QI 0 ax [orig:62 D.3491 ] [62])) pr49095.c:63 66 {*movqi_internal}
(nil))
(insn 9 8 10 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 0 ax [orig:62 D.3491 ] [62])
(const_int 0 [0]))) pr49095.c:63 0 {*cmpqi_ccno_1}
(expr_list:REG_DEAD (reg:QI 0 ax [orig:62 D.3491 ] [62])
(nil)))
It used to be normal QImode addition addqi_1_lea, but it got later on split
to make the code shorter:
;; Avoid redundant prefixes by splitting HImode arithmetic to SImode.
(define_split
[(set (match_operand 0 register_operand )
(match_operator 3 promotable_binary_operator
[(match_operand 1 register_operand )
(match_operand 2 aligned_operand )]))
(clobber (reg:CC FLAGS_REG))]
! TARGET_PARTIAL_REG_STALL reload_completed
((GET_MODE (operands[0]) == HImode
((optimize_function_for_speed_p (cfun) !TARGET_FAST_PREFIX)
/* ??? next two lines just !satisfies_constraint_K (...) */
|| !CONST_INT_P (operands[2])
|| satisfies_constraint_K (operands[2])))
|| (GET_MODE (operands[0]) == QImode
(TARGET_PROMOTE_QImode || optimize_function_for_size_p (cfun
[(parallel [(set (match_dup 0)
(match_op_dup 3 [(match_dup 1) (match_dup 2)]))
(clobber (reg:CC FLAGS_REG))])]
operands[0] = gen_lowpart (SImode, operands[0]);
operands[1] = gen_lowpart (SImode, operands[1]);
if (GET_CODE (operands[3]) != ASHIFT)
operands[2] = gen_lowpart (SImode, operands[2]);
PUT_MODE (operands[3], SImode);)
One thing I wanted to check, though: I hope everybody is aware that
op $x,mem
is not identically the same as
mov mem,reg
op $x, reg
mov reg,mem
test reg
WRT the carry flag. The test version will always clear the carry flag, while
the op version will obviously set it according to the op. For the logical
ops, this isn't a problem (they also clear carry), but for add and sub
this
transformation *will* result in a difference in the C flag.
Now, carry is meaningless when talking about compare with zero, so this
should all be trivially ok. But I bring it up because it is possible that gcc
perhaps still uses the unsigned compare versions with zero.
In particular, the thing to look out for would be code like
unsigned int *a;
if (--*a 0)
do_something();
and if the comparison uses jg (unsigned greater than) for the comparison,
it will get the wrong end result.
Now, unsigned compares against zero are always expressible as ne or eq, so
this is not a fundamental problem. In fact, my trivial testing with a few
cases
seems to imply that gcc already does that conversion to inequality, and you'd
obviously have exactly the same issue with eliding the test instruction for
the cases you already handle (when things are in registers).
That ought to be handled by the
ix86_match_ccmode tests in the peepholes, using CCGOCmode for PLUS/MINUS and
CCNOmode for AND/IOR/XOR. I've just copied what the actual patterns these
peepholes will turn into use. The documentation about those modes says:
Add CCNO to indicate comparisons against zero that requires
Overflow flag to be unset. Sign bit test is used instead and
thus can be used to form ab0 type of tests.
Add CCGOC to indicate comparisons against zero that allows
unspecified garbage in the Carry and Overflow flag. This
mode is used to simulate comparisons of (a-b) and (a+b)
against zero using sub/cmp/add operations.
and ix86_match_ccmode should check if the test type in which the flags register
is tested uses only the flags that will be set correctly by the operation. In
your testcase the comparison was done in
[Bug c++/48284] [C++0x] incorrect printing of decltype operand in diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48284 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/47687] [C++0x] Crash on a lambda returning a lambda (using std::function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47687 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug other/48981] bootstrap-lto -O3 produces miscompiled, broken gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48981 --- Comment #7 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-05-27 15:00:04 UTC --- (In reply to comment #6) I think there should be a space after } in vec.h: +}vec_prefix; Thanks!
[Bug middle-end/49139] always_inline attribute inconsistencies on failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49139 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-05-27 15:08:17 UTC --- You patch looks fine to me but I cannot approve it. You'll need to submit it to gcc-patches for review and approval. You'll need also a Changelog. If you don't have svn access, you should mention in your emails that you need someone to commit the patch for you. See also http://gcc.gnu.org/contribute.html#patches
[Bug c++/48078] gcc accepts-invalid: taking address of private member function from template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-27 15:11:29 UTC --- This bug is probably the reason why g++ only rejects half of the testcase for http://llvm.org/bugs/show_bug.cgi?id=8058
[Bug other/49194] New: Trivially stupid inlining decisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 Summary: Trivially stupid inlining decisions Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: torva...@linux-foundation.org So gcc inlining heuristics seem to include the rule that if it's called from a single call-site, and is static, then it should be inlined. That is actually really horrible for some cases. In particular, if you have a small function that has an uncommon case handled by a much bigger function, you absolutely do *not* want to inline the big function because it ends up creating a total monster of a stack frame - something that the small function on its own doesn't need. So for example, in the kernel we have various of these kinds of situations where we decrement a refcount or a lock, and then in the unlikely situation that something is true, we need to so much more processing as a result. An example of this would be __rcu_read_unlock(), which basically does - decrement the per-thread rcu_read_lock_nesting variable - if that variable is now zero, *and* we have a pending RCU event, we need to do some special complicated stuff. The code is basically written (we have various barriers and helper macros etc that are irrelevant to the inlining issue) as --t-rcu_read_lock_nesting; if (t-rcu_read_lock_nesting == 0 __builtin_expect(!!t-rcu_read_unlock_special, 0)) rcu_read_unlock_special(t); (where t is the thread pointer). And that's all. However, because gcc inlines the special case, the function prologue ends up looking like this (that current_task is from our inline asm, it's just us getting the thread variable): __rcu_read_unlock: pushq %rbp# movq%rsp, %rbp #, subq$48, %rsp #, movq%r13, -24(%rbp) #, movq%rbx, -40(%rbp) #, movq%r12, -32(%rbp) #, movq%r14, -16(%rbp) #, movq%r15, -8(%rbp) #, movq %gs:current_task,%r13 #, t decl256(%r13) # t_15-rcu_read_lock_nesting ... which is pretty horrid. It uses a lot of stack, and has stupid useless instructions. Now, I can just mark that rcu_read_unlock_special() function as noinline, and as a result I get this: __rcu_read_unlock: pushq %rbp# movq%rsp, %rbp #, movq %gs:current_task,%rdi #, t decl256(%rdi) # t_15-rcu_read_lock_nesting ... which is obviously much superior code for the case that actually matters. So rather than have to find all of these things manually (yes, those things do actually show up on profiles - the stack expansion in particular ends up showing up as extra costs), maybe gcc could just have a simple check: - if the call is in an unlikely section - .. and the callee is much bigger (in stack frame or whatever) than the caller - .. simply don't inline Hmm? I realize that this may sound specialized, but I've been looking at kernel profiles for the last few weeks now, and this particular issue has come up in two independent hotspots. It turns out that excessive stack use is *expensive*. It's not just the normal the kernel stack is limited, it's actually a matter of the L1 D$ is pretty small, and a big stack frame actually causes real costs. I really didn't expect register saves on the stack to show up in my profiles, but they actually do. I expect the stack to basically always be in the L1 D$ and dirty (so that an access to it should be almost free), but that is only true for a _dense_ stack. Not for leaf functions that then have extra stack frame wasting code in them. Comments?
[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #8 from Linus Torvalds torva...@linux-foundation.org 2011-05-27 15:32:21 UTC --- (In reply to comment #7) BTW, the patch bootstrapped/regtested on both x86_64-linux and i686-linux, I'm just running second set of bootstrap without the patch to be able to compare how much the patch changed code on gcc itself. I'd love to hear how well it works - I'm in the middle of a busy merge window and about to leave for a trip to Japan, otherwise I'd just try to set up a gcc build myself right now. (Actually, I have a copy of a git tree, but that one fails with /usr/bin/ld: ../libiberty/libiberty.a(argv.o): relocation R_X86_64_32S against `_sch_istable' can not be used when making a shared object; recompile with -fPIC and due to the merge window I don't really have time to try to figure it out) Thanks, Linus
[Bug other/49194] Trivially stupid inlining decisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.05.27 16:02:09
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-27
16:02:09 UTC ---
I agree if the called function is big and it is very unlikely (most probably
just in PROB_VERY_UNLIKELY cases) -finline-functions-called-once shouldn't
inline.
E.g.
void baz (void);
static void
foo (int x)
{
char buf[65536];
int a, b, c, d, e, f, g, h, i, j, k, l, m;
#define A asm volatile (nop : +r (x), =r (a), =r (b), =r (c), \
=r (d), =r (e), =r (f), =r (g), =r (h), \
=r (i), =r (j), =r (k), =r (l), =r (m) \
: r (buf));
#define B A A A A A A A A A A A
#define C B B B B B B B B B B B
C
}
int
bar (int x)
{
if (__builtin_expect (x 65, 0))
foo (x + 6);
baz ();
return x;
}
inlines foo at -O2.
[Bug other/49194] Trivially stupid inlining decisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #2 from Michael Matz matz at gcc dot gnu.org 2011-05-27 16:12:12 UTC --- For adjusting GCCs idea about what stack frame growth is acceptable also fiddle with the large-stack-frame and large-stack-frame-growth parameters.
[Bug other/49194] Trivially stupid inlining decisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 --- Comment #3 from Jan Hubicka hubicka at ucw dot cz 2011-05-27 16:15:02 UTC --- I agree if the called function is big and it is very unlikely (most probably just in PROB_VERY_UNLIKELY cases) -finline-functions-called-once shouldn't inline. -finline-functions-called-once is trottled down by the large-function-growth and large-stack-frame-growth limits. The Kernel case coupld proably be handled by the second. Does kernel bump down that limits? It still won't help in case function doesn't have any on-stack aggregates, since we optimistically assume that all gimple registers will disappear. Probably even that could be change, though estimating reload's stack frame usage so early would be iffy. I agree that both limits are bit high for this particular case. However I experimented with bumping this down some time ago with an extra parameter and did not find any practictical benefit that would justify adding yet another limit to the inliner. So testcases would be welcome. Honza
[Bug other/49194] Trivially stupid inlining decisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-27 16:19:04 UTC --- BTW mainline won't inline foo in that testcase: Deciding on functions called once: not inlinable: bar/1 - foo/0, --param large-stack-frame-growth limit reached I fixed some stack-growth estimation issues while rewriting inliner for 4.7, if 4.6 inlines, perhaps I can figure out what gets wrong there.
[Bug other/49194] Trivially stupid inlining decisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-27 16:24:45 UTC --- Oops, s/65536/128/, I've changed the testcase too late without retesting. Anyway, the point is that the limits should be adjusted somewhat if the call is PROB_VERY_UNLIKELY.
[Bug c++/49176] [4.6 Regression][c++0x] valid code rejected with error: uninitialized const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49176 fabien at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org AssignedTo|fabien at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #6 from fabien at gcc dot gnu.org 2011-05-27 16:31:42 UTC --- (In reply to comment #5) Just tried -r174238: was already broken. Thank you Paolo. I've just played a little with it, it seems that to avoid the uninitialized diagnostic from check_for_uninitialized_const_var, the constness of b have to be removed at some point. It is not removed in c++0X mode for 4.6. Let's CC Jason ...
[Bug bootstrap/49195] New: Error building libgcc for powerpc64 since r174305
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49195 Summary: Error building libgcc for powerpc64 since r174305 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: wschm...@gcc.gnu.org libgcc fails to build for powerpc64 today. This was exposed starting with the introduction of revision 174305: r174305 | rsandifo | 2011-05-26 14:16:05 -0500 (Thu, 26 May 2011) | 13 lines gcc/ PR rtl-optimization/48575 * genrecog.c (position_type): New enum. (position): New structure. (decision): Use position structure instead of a string. (root_pos, peep2_insn_pos_list): New variables. (next_position, compare_positions): New functions. (new_decision): Use position structures instead of strings. (maybe_both_true): Likewise. (change_state): Likewise. (write_tree): Likewise. (make_insn_sequence): Likewise. Here's the failure from the build log: /home/wschmidt/gcc/build/gcc-mainline-base/./gcc/xgcc -B/home/wschmidt/gcc/build/gcc-mainline-base/./gcc/ -B/home/wschmidt/gcc/install/gcc-mainline-base/powerpc64-linux/bin/ -B/home/wschmidt/gcc/install/gcc-mainline-base/powerpc64-linux/lib/ -isystem /home/wschmidt/gcc/install/gcc-mainline-base/powerpc64-linux/include -isystem /home/wschmidt/gcc/install/gcc-mainline-base/powerpc64-linux/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mno-minimal-toc -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -mlong-double-128 -I. -I. -I../.././gcc -I/home/wschmidt/gcc/gcc-mainline-base/libgcc -I/home/wschmidt/gcc/gcc-mainline-base/libgcc/. -I/home/wschmidt/gcc/gcc-mainline-base/libgcc/../gcc -I/home/wschmidt/gcc/gcc-mainline-base/libgcc/../include -I/home/wschmidt/gcc/gcc-mainline-base/libgcc/../libdecnumber/dpd -I/home/wschmidt/gcc/gcc-mainline-base/libgcc/../libdecnumber -DHAVE_CC_TLS -o _divsc3.o -MT _divsc3.o -MD -MP -MF _divsc3.dep -DL_divsc3 -c /home/wschmidt/gcc/gcc-mainline-base/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS /home/wschmidt/gcc/gcc-mainline-base/libgcc/../gcc/libgcc2.c: In function ‘__divsc3’: /home/wschmidt/gcc/gcc-mainline-base/libgcc/../gcc/libgcc2.c:1944:1: 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. make[5]: *** [_divsc3.o] Error 1 Here's a debug stack trace for the segv: (gdb) bt #0 0x121e38ec in rtx_equal_p (x=0xedafafafaf, y=0xfffb7293f80) at /home/wschmidt/gcc/gcc-mainline-base/gcc/rtl.c:512 #1 0x14439848 in recog_33 (x0=0xfffb6dc4d00, insn=0xfffb72b9dc8, pnum_clobbers=0xfffcfc8) at /home/wschmidt/gcc/gcc-mainline-base/gcc/config/rs6000/rs6000.md:15012 #2 0x1444319c in recog_36 (x0=0xfffb6dc4d00, insn=0xfffb72b9dc8, pnum_clobbers=0xfffcfc8) at /home/wschmidt/gcc/gcc-mainline-base/gcc/config/rs6000/rs6000.md:13393 #3 0x14466824 in recog_51 (x0=0xfffb6dc4d00, insn=0xfffb72b9dc8, pnum_clobbers=0xfffcfc8) at /home/wschmidt/gcc/gcc-mainline-base/gcc/config/rs6000/rs6000.md:224 #4 0x14473090 in recog (x0=0xfffb6dc4d00, insn=0xfffb72b9dc8, pnum_clobbers=0xfffcfc8) at /home/wschmidt/gcc/gcc-mainline-base/gcc/config/rs6000/altivec.md:341 #5 0x145e461c in recog_for_combine (pnewpat=0xfffd410, insn=0xfffb72b9dc8, pnotes=0xfffd458) at /home/wschmidt/gcc/gcc-mainline-base/gcc/combine.c:10648 #6 0x145c9208 in try_combine (i3=0xfffb72b9dc8, i2=0xfffb72b9c18, i1=0x0, i0=0x0, new_direct_jump_p=0xfffd8b0, last_combined_insn=0xfffb72b9dc8) at /home/wschmidt/gcc/gcc-mainline-base/gcc/combine.c:3350 #7 0x145c1e84 in combine_instructions (f=0xfffb6e93d80, nregs=399) at /home/wschmidt/gcc/gcc-mainline-base/gcc/combine.c:1223 #8 0x145eea58 in rest_of_handle_combine () at /home/wschmidt/gcc/gcc-mainline-base/gcc/combine.c:13901 #9 0x11df3f8c in execute_one_pass (pass=0x155065c8) at /home/wschmidt/gcc/gcc-mainline-base/gcc/passes.c:1556 #10 0x11df4248 in execute_pass_list (pass=0x155065c8) at /home/wschmidt/gcc/gcc-mainline-base/gcc/passes.c:1610 #11 0x11df4274 in execute_pass_list (pass=0x154feb20) at /home/wschmidt/gcc/gcc-mainline-base/gcc/passes.c:1611 #12 0x12c4821c in tree_rest_of_compilation (fndecl=0xfffb6f08b00) at /home/wschmidt/gcc/gcc-mainline-base/gcc/tree-optimize.c:417 #13 0x10a93bf4 in cgraph_expand_function (node=0xfffb6f3e740) at /home/wschmidt/gcc/gcc-mainline-base/gcc/cgraphunit.c:1630 #14
[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-27 16:33:33 UTC --- .text sizes before/after the patch (in each case on identical sources, for cc1plus I've reverted the patch afterwards and did make -j64 cc1plus in gcc/ subdir), the size changes aren't that big, but perhaps other projects use it more often and/or something is hidden due to alignment. 32-bit before32-bit after64-bit before64-bit after libstdc++.so.60x717080x716e80x67ee60x67ec6 libgcj.so.120xa3ec580xa3eb980x90cd680x90cce8 cc1plus0xe8a29c0xe8a25c0xdccf980xdccf08 In 64-bit cc1plus it only made a difference in: c-decl.o cfg.o dbxout.o ebitmap.o final.o ira-color.o jump.o regcprop.o reg-stack.o reload.o tree-ssa-dom.o tree-ssa-loop-ivopts.o Anyway, I'll post the patch now and see what Uros says about it.
[Bug libstdc++/49187] parallel mode compilation broken - unqualified lookup? (bisected)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49187 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-27 16:35:43 UTC --- Author: paolo Date: Fri May 27 16:35:36 2011 New Revision: 174342 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174342 Log: 2011-05-27 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/49187 * include/parallel/losertree.h: Add missing using declarations of _Base::_M_comp. * include/parallel/algobase.h: Include parallel/algorithmfwd.h. * include/parallel/multiway_merge.h: Include parallel/ multiseq_selection.h, forward declare __merge_advance. * include/parallel/multiseq_selection.h: Don't include parallel/ sort.h here. * include/ext/pb_ds/detail/thin_heap_/erase_fn_imps.hpp: Fix qualification of upper_bound. * testsuite/ext/pb_ds/regression/tree_no_data_map_rand_debug.cc: Use dg-require-debug-mode. * testsuite/ext/pb_ds/regression/tree_data_map_rand_debug.cc: Likewise. * testsuite/ext/pb_ds/regression/priority_queue_rand_debug.cc: Likewise. * testsuite/ext/pb_ds/regression/trie_no_data_map_rand_debug.cc: Likewise. * testsuite/ext/pb_ds/regression/trie_data_map_rand_debug.cc: Likewise. * testsuite/ext/pb_ds/regression/list_update_no_data_map_rand_debug.cc: Likewise. * testsuite/ext/pb_ds/regression/list_update_data_map_rand_debug.cc: Likewise. * testsuite/ext/pb_ds/regression/hash_no_data_map_rand_debug.cc: Likewise. * testsuite/ext/pb_ds/regression/hash_data_map_rand_debug.cc: Likewise. * include/parallel/algo.h: Minor uglification fixes. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/pb_ds/detail/thin_heap_/erase_fn_imps.hpp trunk/libstdc++-v3/include/parallel/algo.h trunk/libstdc++-v3/include/parallel/algobase.h trunk/libstdc++-v3/include/parallel/losertree.h trunk/libstdc++-v3/include/parallel/multiseq_selection.h trunk/libstdc++-v3/include/parallel/multiway_merge.h trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_data_map_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_no_data_map_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_data_map_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_no_data_map_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_data_map_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_no_data_map_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand_debug.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_no_data_map_rand_debug.cc
[Bug libstdc++/49187] parallel mode compilation broken - unqualified lookup? (bisected)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49187 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-27 16:37:30 UTC --- Fixed.
[Bug other/49194] Trivially stupid inlining decisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 --- Comment #6 from Linus Torvalds torva...@linux-foundation.org 2011-05-27 16:38:22 UTC --- (In reply to comment #3) -finline-functions-called-once is trottled down by the large-function-growth and large-stack-frame-growth limits. The Kernel case coupld proably be handled by the second. Does kernel bump down that limits? We used to play with inlining limits (gcc had some really bad decisions), but the meaning of the numbers kept changing from one gcc version to another, and the heuristics gcc used kept changing too. Which made it practically impossible to use sanely - you could tweak it for one particular architecture, and one particular version of gcc, but it would then be worse for others. Quite frankly, with that kind of history, I'm not very eager to start playing around with random gcc internal variables again. So I'd much rather have gcc have good heuristics by default, possibly helped by the kinds of obvious hints we can give (unlikely() in particular is something we can add for things like this). Obviously, we can (and do) use the force the decision with either noinline or __always_inline (which are just the kernel macros to make the gcc attribute syntax slightly more readable), but since I've been doing those other bug reports about bad gcc code generation, I thought I'd point out this one too. It still won't help in case function doesn't have any on-stack aggregates, since we optimistically assume that all gimple registers will disappear. Probably even that could be change, though estimating reload's stack frame usage so early would be iffy. Yes, early stack estimation might not work all that well. In the kernel, we do end up having a few complex functions that we basically expect to inline to almost nothing - simply because we end up depending on compile-time constant issues (sometimes very explicitly, with __builtin_constant_p() followed by a largish switch () statement). That said, this is something where the call-site really can make a big difference. Not just the fact that the call site might be marked unlikely() (again, that's just the kernel making __builtin_expect() readable), but things like none of the arguments are constants could easily be a good heuristic to use as a basis for whether to inline or not. IOW, start out with whatever 'large-stack-frame-growth' and 'large-function-growth' values, but if the call-site is in an unlikely region, cut those values in half (or whatever). And if none of the arguments are constants, cut it in half again. This is an example of why giving these limits as compiler options really doesn't work: the choice should probably be much more dynamic than just a single number. I dunno. As mentioned, we can fix this problem by just marking things noinline by hand. But I do think that there are fairly obvious cases where inlining really isn't worth it, and gcc might as well just get those cases right.
[Bug target/48529] [x32] Testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48529 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2011-05-27 16:44:42 UTC --- Therre is only one failure: FAIL: libgomp.fortran/strassen.f90 -O execution test with C, C++, Fortran and Objective C on x32 branch at revision 174333.
[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #10 from Linus Torvalds torva...@linux-foundation.org 2011-05-27 16:48:52 UTC --- (In reply to comment #9) 32-bit before32-bit after64-bit before64-bit after libstdc++.so.60x717080x716e80x67ee60x67ec6 libgcj.so.120xa3ec580xa3eb980x90cd680x90cce8 cc1plus0xe8a29c0xe8a25c0xdccf980xdccf08 Ok, that's much less noticeable than I was hoping for. That said, even for the kernel, the only reason I noticed this problem was not because I've seen a lot of them per se, but because the pattern showed up in a very hot function. In fact, it's the same __rcu_read_unlock() function that I made the otherwise unrelated bugzilla entry for inlining: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194 so it's quite possible that we don't have that many of them in the kernel either.
[Bug c++/47277] [C++0x] pseudo destructor code that cause an internal compiler error with std=gnu++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47277 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130
--- Comment #3 from Tom Tromey tromey at gcc dot gnu.org 2011-05-27 16:59:57
UTC ---
Here is another case:
templateclass K, unsigned long l
class S2
{
};
templatetypename T void f(S2T, sizeof(T*)) { }
int main()
{
S2double, sizeof(double*) s;
fdouble (s);
}
This generates:
129: Abbrev Number: 2 (DW_TAG_class_type)
2a DW_AT_name: (indirect string, offset: 0x88): S2double, 4ul
2e DW_AT_byte_size : 1
2f DW_AT_decl_file : 1
30 DW_AT_decl_line : 2
31 DW_AT_sibling : 0x45
235: Abbrev Number: 3 (DW_TAG_template_type_param)
36 DW_AT_name: K
38 DW_AT_type: 0xad
23c: Abbrev Number: 4 (DW_TAG_template_value_param)
3d DW_AT_name: l
3f DW_AT_type: 0xb4
43 DW_AT_const_value : 4
Note that both DW_AT_name and DW_TAG_template_value_param are
incorrect. The demangler gets it right:
void fdouble(S2double, sizeof (double*))
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130 --- Comment #4 from Tom Tromey tromey at gcc dot gnu.org 2011-05-27 17:03:09 UTC --- I forgot to mention -- you can construct many more such cases using the expressions feature of the mangling: http://www.codesourcery.com/public/cxx-abi/abi.html#expressions This also affects PR 41736
[Bug c++/49176] [4.6 Regression][c++0x] valid code rejected with error: uninitialized const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49176 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-05-27 17:14:06 UTC --- Seems like this was fixed by the patch for bug 48657.
[Bug c++/49196] New: GCC 4.2.1 [FreeBSD] segfaults with certain use of void typedefs with debugging symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49196
Summary: GCC 4.2.1 [FreeBSD] segfaults with certain use of void
typedefs with debugging symbols
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: darkuran...@gmail.com
Created attachment 24375
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24375
Test file showing the bug
The following makes GCC segfault:
namespace foo
{
typedef void Fvoid;
}
using foo::Fvoid;
int main()
{
return 0;
} // segfault reported on this line
Note that the code should be compiled with debugging symbols activated (I've
tested with -g or -ggdb) - without them, the bug does not get triggered.
Namespaces can be nested deeper (using foo::bar::Fvoid;) and the bug still
appears.
Merely using the type does NOT trigger a segfault:
// these do NOT segfault:
foo::Fvoid* v1;
using namespace foo;
Fvoid* v2;
Compile the test file with: g++ -g test.cpp
Error reported: test.cpp:25: internal compiler error: Segmentation fault: 11
[Bug c++/49196] GCC 4.2.1 [FreeBSD] segfaults with certain use of void typedefs with debugging symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49196 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.27 17:23:16 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-27 17:23:16 UTC --- It doesn't on Linux for the currently maintained branches. Please update your compiler - 4.2.x is very old and not maintained anymore - and report back, thanks.
[Bug c++/47687] [C++0x] Crash on a lambda returning a lambda (using std::function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47687 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||a71104 at gmail dot com --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-05-27 17:24:48 UTC --- *** Bug 47212 has been marked as a duplicate of this bug. ***
[Bug c++/47212] [C++0x] crash on lambda returning lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47212 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||DUPLICATE AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-05-27 17:24:48 UTC --- I'm looking at this issue. *** This bug has been marked as a duplicate of bug 47687 ***
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130
--- Comment #5 from dodji at seketeli dot org dodji at seketeli dot org
2011-05-27 17:27:43 UTC ---
In the example below, I could reproduce a case of difference between the
mangled name and the content of DW_AT_name.
Basically the content of the DW_AT_name property of the instanciation of
S is S2048u, and the mangled name of the member function f is
_ZN1N1SILm2048EE1fEm -- N::S2048ul::f(unsigned long). Notice how the
former S2048u and the latter S2048ul are different.
typedef long unsigned int size_t;
static const size_t KB = 1024;
static const size_t atomSize = sizeof(double);
static const size_t blockSize = 16 * KB;
namespace N {
templatesize_t size
struct S
{
void f(size_t);
};
templatesize_t size
inline void
Ssize::f(size_t)
{
size_t i = size;
}
}
int
main()
{
N::SblockSize / atomSize s1;
s1.f(10);
}
[Bug c++/47132] [C++0x] decltype can't deduce some operator return types when defining an auto function's return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47132 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/47169] [C++0x] cannot deduce base class functions from a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47169 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-05-27 17:45:30 UTC --- Fixed in 4.6.0.
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-27 17:51:07 UTC --- I have bootstrapped revision 174339 after reverting revision 174286.
[Bug middle-end/49197] New: Crash compiling arm-unknown-linux-gnueabi libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49197 Summary: Crash compiling arm-unknown-linux-gnueabi libgcc Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com CC: rsand...@gcc.gnu.org Host: x86_64-linux-gnu Target: arm-unknown-linux-gnueabi Build: x86_64-linux-gnu /home/ryan/gnu/gcc/trunk/arm-eabi/./gcc/xgcc -B/home/ryan/gnu/gcc/trunk/arm-eabi/./gcc/ -B/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/bin/ -B/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/lib/ -isystem /home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/include -isystem /home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-include -g -Os -O2 -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -DHAVE_CC_TLS -o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c ../../../libgcc/../gcc/libgcc2.c \ ../../../libgcc/../gcc/libgcc2.c: In function '__powisf2': ../../../libgcc/../gcc/libgcc2.c:1735:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_powisf2.o] Error 1 Program received signal SIGBUS, Bus error. rtx_equal_p (x=0xafafafaf0086, y=value optimized out) at ../../gcc/rtl.c:512 512 code = GET_CODE (x); (gdb) bt #0 rtx_equal_p (x=0xafafafaf0086, y=value optimized out) at ../../gcc/rtl.c:512 #1 0x00ba027b in recog_1 (x0=0x76cfcdd0, pnum_clobbers=0x7fffdbac, insn=value optimized out) at ../../gcc/config/arm/arm.md:3975 #2 recog_5 (x0=0x76cfcdd0, pnum_clobbers=0x7fffdbac, insn=value optimized out) at ../../gcc/config/arm/arm.md:3742 #3 0x00ba9bab in recog_16 (x0=0x76cfcdd0, pnum_clobbers=0x7fffdbac, insn=value optimized out) at ../../gcc/config/arm/arm.md:10029 #4 0x00c17595 in recog_for_combine (pnewpat=0x7fffdde8, insn=0x76d6d480, pnotes=0x7fffdda0) at ../../gcc/combine.c:10648 #5 0x00c28309 in try_combine (i3=0x76d6d480, i2=0x76d6d3f0, i1=0x0, i0=value optimized out, new_direct_jump_p=0x7fffde6c, last_combined_insn=value optimized out) at ../../gcc/combine.c:3350 #6 0x00c2ceb5 in combine_instructions () at ../../gcc/combine.c:1223 #7 rest_of_handle_combine () at ../../gcc/combine.c:13902 #8 0x007bd441 in execute_one_pass (pass=0x1240400) at ../../gcc/passes.c:1556 #9 0x007bd6f5 in execute_pass_list (pass=0x1240400) at ../../gcc/passes.c:1610 #10 0x007bd707 in execute_pass_list (pass=0x1237280) at ../../gcc/passes.c:1611 #11 0x008d2478 in tree_rest_of_compilation (fndecl=0x76d07300) at ../../gcc/tree-optimize.c:417 #12 0x005a4405 in cgraph_expand_function (node=0x76d13000) at ../../gcc/cgraphunit.c:1630 #13 0x005a61da in cgraph_expand_all_functions () at ../../gcc/cgraphunit.c:1689 #14 cgraph_optimize () at ../../gcc/cgraphunit.c:1952 #15 0x005a677a in cgraph_finalize_compilation_unit () at ../../gcc/cgraphunit.c:1126 #16 0x0049a418 in c_write_global_declarations () at ../../gcc/c-decl.c:9840 #17 0x00861d06 in compile_file (argc=12, argv=0x7fffe108) at ../../gcc/toplev.c:586 #18 do_compile (argc=12, argv=0x7fffe108) at ../../gcc/toplev.c:1923 #19 toplev_main (argc=12, argv=0x7fffe108) at ../../gcc/toplev.c:1995 #20 0x7718deff in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #21 0x0047e959 in _start () (gdb) The change that triggered the crash is: http://gcc.gnu.org/viewcvs?view=revisionrevision=174305
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 Nathan Froyd froydnj at gcc dot gnu.org changed: What|Removed |Added CC||froydnj at gcc dot gnu.org --- Comment #3 from Nathan Froyd froydnj at gcc dot gnu.org 2011-05-27 17:57:44 UTC --- Ugh. I do not have time to deal with this problem at the moment. But I don't understand how ASM_OUTPUT_WEAKREF isn't defined at that point. We have a perfectly fine default definition in defaults.h.
[Bug middle-end/49197] Crash compiling arm-unknown-linux-gnueabi libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49197
--- Comment #1 from Ryan Mansfield rmansfield at qnx dot com 2011-05-27
18:08:04 UTC ---
Reduced tescase:
float
__powisf2 (float x, int m)
{
unsigned int n = m 0 ? -m : m;
while (n = 1) { }
}
[Bug c++/48657] [4.6/4.7 Regression] could not convert template argument ‘VectorDimension’ to ‘unsigned int’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48657 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-05-27 18:10:52 UTC --- Author: jason Date: Fri May 27 18:10:48 2011 New Revision: 174346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174346 Log: PR c++/48657 PR c++/49176 * decl.c (cp_finish_decl): Simplify template handling. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/const5.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/49176] [4.6 Regression][c++0x] valid code rejected with error: uninitialized const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49176 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-05-27 18:10:52 UTC --- Author: jason Date: Fri May 27 18:10:48 2011 New Revision: 174346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174346 Log: PR c++/48657 PR c++/49176 * decl.c (cp_finish_decl): Simplify template handling. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/const5.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-27 18:29:53 UTC --- (In reply to comment #3) Ugh. I do not have time to deal with this problem at the moment. But I don't understand how ASM_OUTPUT_WEAKREF isn't defined at that point. We have a perfectly fine default definition in defaults.h. Perhaps because x86_64-apple-darwin has... [MacPro:gcc47-4.7.0-1000/darwin_objdir/gcc] root# grep HAVE_GAS_WEAKREF * auto-host.h:/* #undef HAVE_GAS_WEAKREF */ whereas linux has... auto-host.h:#define HAVE_GAS_WEAKREF 1
[Bug bootstrap/49195] [4.7 Regression] Error building libgcc for powerpc64 since r174305
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49195 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build, ice-on-valid-code Target Milestone|--- |4.7.0 Summary|Error building libgcc for |[4.7 Regression] Error |powerpc64 since r174305 |building libgcc for ||powerpc64 since r174305 Severity|normal |blocker
