[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #14 from Ira Rosen irar at il dot ibm.com 2011-09-20 06:23:54 UTC --- The basic block that got vectorized on these platforms is in main(). I am going to remove it and leave only shift(), since the main purpose of the test is to check that shift () doesn't get vectorized. Thanks, Ira
[Bug bootstrap/50461] New: mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 Bug #: 50461 Summary: mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@denis-excoffier.org Hi, I bootstrap gcc-4.6.1 by installing the gmp/, mpfr/ and mpc/ folders directly in the GCC source tree as suggested in the installation notes. Yesterday, they created a new mpfr-3.1.0-rc1 as a replacement for mpfc-3.0.1 we used to have before. Now, with this new mpfr, the bootstrap fails at the step: Configuring mpc at stage 1. Solution: Compared to mpfr-3.0.1, the new mpfr-3.1.0-rc1 has an additional src folder. Therefore, the ./configure of GCC has to be modified, eg by replacing (sed syntax): s|$$s/mpfr|/src|g (1 occurrence) and s|$$r/$(HOST_SUBDIR)/mpfr|/src|g (2 occurrences) With this modification, everything works fine. I don't think that the MPFR people will remove the src folder in the next future. I suppose this is for all platforms, in any case at least Linux Ubuntu and Darwin Leopard. Regards, Denis Excoffier.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #6 from Ira Rosen irar at il dot ibm.com 2011-09-20 08:27:08 UTC --- Thanks for working on this! It looks like the problem is with the way the stmts are marked. We don't insert pattern stmts now, so the things are more tricky. I'll try to fix this.
[Bug testsuite/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49443
--- Comment #6 from jye2 at gcc dot gnu.org 2011-09-20 09:01:06 UTC ---
Author: jye2
Date: Tue Sep 20 09:00:58 2011
New Revision: 179003
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179003
Log:
2011-09-20 Jiangning Liu jiangning@arm.com
Backport r175246 from mainline
2011-06-21 Ira Rosen ira.ro...@linaro.org
PR testsuite/49443
* gcc.dg/vect/vect-peel-3.c: Expect to fail on vect_no_align
targets.
* gcc.dg/vect/vect-peel-4.c: Likewise.
2011-09-20 Jiangning Liu jiangning@arm.com
Backport r175009 from mainline
2011-06-14 Ira Rosen ira.ro...@linaro.org
* gcc.dg/vect/vect-16.c: Rename to...
* gcc.dg/vect/no-fast-math-vect16.c: ...this.
* gcc.dg/vect/vect-peel-3.c: Adjust misalignment values
for double-word vectors.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/bb-slp-10.c: Replace vect_hw_misalign with
vect_element_align.
* gcc.dg/vect/vect.exp: Run no-fast-math-* tests with
-fno-fast-math.
Added:
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/no-fast-math-vect16.c
(props changed)
- copied unchanged from r178998,
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-16.c
Removed:
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-16.c
Modified:
branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-peel-3.c
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-peel-4.c
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/vect.exp
Propchange:
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/vect/no-fast-math-vect16.c
('svn:mergeinfo' added)
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.0 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-20 09:59:49 UTC --- Seems to be caused by PR48571, we throw away the important info (that the access was through a.buf1 rather than a), which is essential for -D_FORTIFY_SOURCE=2. The change happens already during gimplification: - strcpy (a.buf1[4], D.2732); + strcpy (MEM[(void *)a + 4B], D.2732); while in *.original it was strcpy ((char *) a.buf1 + 4, str1 + 5); Not reconstrucing the array ref is fine, but before *.objsz pass we really shouldn't throw away the buf1 from it, so it should be tmp = a.buf1 + 4; -D_FORTIFY_SOURCE=2 cares whether the user wrote strcpy ((char *) a + 4, ...); (in which case it allows to overwrite the whole object) or strcpy ((char *) a.buf1 + 4, ...); (in which case it is allowed to overwrite just the buf1 field). Richard, can you please have a look at this?
[Bug c++/50462] New: Particularly painful error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
Bug #: 50462
Summary: Particularly painful error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ch...@bubblescope.net
The following code (note that the call to 'size' is missing () ) produces a
particulaly painful error message:
#include iostream
struct V
{
int size() {};
int size() const {};
};
void print(V v)
{ std::cout v.size; }
Error message:
t.cc: In function ‘void print(V)’:
t.cc:10:18: error: no match for ‘operator’ in ‘std::cout v.V::size’
t.cc:10:18: note: candidates are:
/usr/include/c++/4.6/ostream:110:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::basic_ostream_CharT, _Traits::__ostream_type
(*)(std::basic_ostream_CharT, _Traits::__ostream_type)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:110:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to
‘std::basic_ostreamchar::__ostream_type
(*)(std::basic_ostreamchar::__ostream_type)’
/usr/include/c++/4.6/ostream:119:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::basic_ostream_CharT, _Traits::__ios_type
(*)(std::basic_ostream_CharT, _Traits::__ios_type)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar, std::basic_ostream_CharT,
_Traits::__ios_type = std::basic_ioschar]
/usr/include/c++/4.6/ostream:119:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to
‘std::basic_ostreamchar::__ios_type
(*)(std::basic_ostreamchar::__ios_type)’
/usr/include/c++/4.6/ostream:129:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::ios_base (*)(std::ios_base)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:129:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘std::ios_base
(*)(std::ios_base)’
/usr/include/c++/4.6/ostream:167:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(long
int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:167:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘long int’
/usr/include/c++/4.6/ostream:171:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(long
unsigned int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:171:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘long unsigned int’
/usr/include/c++/4.6/ostream:175:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(bool)
[with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:175:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘bool’
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: std::basic_ostream_CharT,
_Traits std::basic_ostream_CharT, _Traits::operator(short int) [with
_CharT = char, _Traits = std::char_traitschar]
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: no known conversion for
argument 1 from ‘unresolved overloaded function type’ to ‘short int’
/usr/include/c++/4.6/ostream:182:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(short
unsigned int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:182:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘short unsigned int’
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: std::basic_ostream_CharT,
_Traits std::basic_ostream_CharT, _Traits::operator(int) [with _CharT =
char, _Traits = std::char_traitschar]
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: no known conversion for
argument 1 from ‘unresolved overloaded function type’ to ‘int’
/usr/include/c++/4.6/ostream:193:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(unsigned int) [with _CharT = char, _Traits =
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-09-20 10:49:02 UTC --- Do you have some date before when trunk managed bootstraps successfully ? Ramana
[Bug fortran/47023] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 florian.rathgeber at gmail dot com changed: What|Removed |Added CC||florian.rathgeber at gmail ||dot com --- Comment #2 from florian.rathgeber at gmail dot com 2011-09-20 10:55:48 UTC --- I'm seeing this bug even for an explicitly interoperable type (hence I'm not sure if this is really the same bug - I'm happy to file a new one if someone tells me to): print *, c_sizeof(0.0_c_double) 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable data entity GNU Fortran (Ubuntu 4.6.0-1ubuntu1~ppa2) 4.6.1 20110326 (prerelease)
[Bug c++/50454] Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-20 11:41:44 UTC --- On it.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #7 from Ira Rosen irar at il dot ibm.com 2011-09-20 11:45:53 UTC --- Created attachment 25322 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25322 fix Here is the fix (it's a diff relative to your patch).
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #8 from Ira Rosen irar at il dot ibm.com 2011-09-20 11:47:00 UTC --- Created attachment 25323 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25323 complete patch including my fix
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
--- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch
2011-09-20 12:05:01 UTC ---
does not compile to me
../.././gcc/tree-vect-loop.c: In function 'vect_is_simple_reduction_1':
../.././gcc/tree-vect-loop.c:2237:35: warning: suggest parentheses around ''
within '||' [-Wparentheses]
../.././gcc/tree-vect-loop.c:2238:5: error: expected ')' before '{' token
../.././gcc/tree-vect-loop.c:2402:1: error: expected expression before '}'
token
../.././gcc/tree-vect-loop.c:2021:33: warning: unused variable 'def2'
[-Wunused-variable]
../.././gcc/tree-vect-loop.c: At top level:
../.././gcc/tree-vect-loop.c:1798:1: warning: 'vect_is_slp_reduction' defined
but not used [-Wunused-function]
../.././gcc/tree-vect-loop.c: In function 'vect_is_simple_reduction_1':
../.././gcc/tree-vect-loop.c:2402:1: warning: control reaches end of non-void
function [-Wreturn-type]
make[3]: *** [tree-vect-loop.o] Error 1
looks like some parentheses is missing in the if statement
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Attachment #25322|0 |1 is obsolete|| --- Comment #10 from Ira Rosen irar at il dot ibm.com 2011-09-20 12:17:46 UTC --- Created attachment 25324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25324 sorry, fixed it now
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Attachment #25323|0 |1 is obsolete|| --- Comment #11 from Ira Rosen irar at il dot ibm.com 2011-09-20 12:18:50 UTC --- Created attachment 25325 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25325 complete patch
[Bug fortran/50463] New: -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 Bug #: 50463 Summary: -ftree-dse leeds to wrong code with gfortran Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@intes.de compiling the attached code with gfortran -O a.f b.f c.f leeds to wrong code. If compileing with gfortran -O -fno-tree-dse a.f b.f c.f the code produce correct results.
[Bug fortran/50463] -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 --- Comment #1 from manz at intes dot de 2011-09-20 12:29:47 UTC --- Created attachment 25326 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25326 Fortran testcase code a.f, b.f and c.f
[Bug c++/47011] ICE when using attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47011 --- Comment #2 from Mat Hostetter mat at lcs dot mit.edu 2011-09-20 12:31:56 UTC --- Created attachment 25327 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25327 bug showing ICE with -O, incorrect code without optimization
[Bug c++/47011] ICE when using attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47011 --- Comment #3 from Mat Hostetter mat at lcs dot mit.edu 2011-09-20 12:32:47 UTC --- I am seeing the same crash with gcc 4.4.[3456], on x86_64. It works on 4.6.1. I encountered this crash when simply upgrading to the latest boost (1.47.0), which uses attribute optimize, so this is likely to affect other people. But the bug is more surprising and subtle than just the crash. It can silently generate incorrect code, which took me longer to track down. If you compile my attached code optimized you get the internal compiler error. If you compile it unoptimized, g++ silently changes the calling convention for vector::begin from by-value to by-reference -- but only if a completely unrelated empty function is marked with attribute optimize! In the full example this meant g++ miscompiled std::vector::begin to use the wrong calling convention, which when linked into other objects expecting the proper calling convention would cause a crash.
[Bug fortran/50463] [4.6/4.7 Regression] -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-20 CC||bur...@net-b.de, jh at suse ||dot cz, rguenther at suse ||dot de Summary|-ftree-dse leeds to wrong |[4.6/4.7 Regression] |code with gfortran |-ftree-dse leeds to wrong ||code with gfortran Ever Confirmed|0 |1 Severity|critical|normal --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-20 13:14:08 UTC --- I confirm the problem on 4.6.1 and trunk, but the code seems to work as expected with 4.5.3 and 4.4.6. It also works if I merge the three files in one, or if I use -flto. Assuming that the test is coming from a bigger project, could you try -flto on it?
[Bug fortran/50463] [4.6/4.7 Regression] -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-20 13:18:35 UTC --- r165415 is OK r165758 gives a wrong code.
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-09-20 13:34:15 UTC --- It is caused by revision 178312: http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg01330.html
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #12 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-09-20 13:46:16 UTC --- I'm getting these errors ../.././gcc/optabs.c: In function 'optab_d* optab_for_tree_code(tree_code, const_tree, optab_subtype)': ../.././gcc/optabs.c:470:9: error: cannot convert 'convert_optab_d*' to 'optab' in return ../.././gcc/optabs.c:474:9: error: cannot convert 'convert_optab_d*' to 'optab' in return ../.././gcc/optabs.c:478:9: error: cannot convert 'convert_optab_d*' to 'optab' in return ../.././gcc/optabs.c:482:9: error: cannot convert 'convert_optab_d*' to 'optab' in return any idea what could be wrong?
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386 --- Comment #3 from dave.anglin at bell dot net 2011-09-20 13:46:04 UTC --- On 9/20/2011 6:49 AM, ramana at gcc dot gnu.org wrote: Do you have some date before when trunk managed bootstraps successfully ? This is my last successful build: http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg00879.html Dave
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-20
13:59:47 UTC ---
Clang does only marginally better because of its selective typedef unwrapping
and avoiding printing back expressions, but then it goes and prints all
candidates:
/tmp/webcompile/_7569_0.cc:10:13: error: invalid operands to binary expression
('ostream' (aka 'basic_ostreamchar') and 'overloaded function type')
{ std::cout v.size; }
~ ^ ~~
In file included from /tmp/webcompile/_7569_0.cc:1:
In file included from /usr/include/c++/4.3/iostream:44:
/usr/include/c++/4.3/ostream:111:7: note: candidate function not viable: no
overload of 'size' matching '__ostream_type (*)(__ostream_type )' for 1st
argument
operator(__ostream_type (*__pf)(__ostream_type))
^
/usr/include/c++/4.3/ostream:120:7: note: candidate function not viable: no
overload of 'size' matching '__ios_type (*)(__ios_type )' for 1st argument
operator(__ios_type (*__pf)(__ios_type))
^
/usr/include/c++/4.3/ostream:130:7: note: candidate function not viable: no
overload of 'size' matching 'std::ios_base (*)(std::ios_base )' for 1st
argument
operator(ios_base (*__pf) (ios_base))
^
/usr/include/c++/4.3/ostream:168:7: note: candidate function not viable: no
overload of 'size' matching 'long' for 1st argument
operator(long __n)
^
/usr/include/c++/4.3/ostream:172:7: note: candidate function not viable: no
overload of 'size' matching 'unsigned long' for 1st argument
operator(unsigned long __n)
^
/usr/include/c++/4.3/ostream:176:7: note: candidate function not viable: no
overload of 'size' matching 'bool' for 1st argument
operator(bool __n)
^
/usr/include/c++/4.3/ostream:180:7: note: candidate function not viable: no
overload of 'size' matching 'short' for 1st argument
operator(short __n);
^
/usr/include/c++/4.3/ostream:183:7: note: candidate function not viable: no
overload of 'size' matching 'unsigned short' for 1st argument
operator(unsigned short __n)
^
/usr/include/c++/4.3/ostream:191:7: note: candidate function not viable: no
overload of 'size' matching 'int' for 1st argument
operator(int __n);
^
/usr/include/c++/4.3/ostream:194:7: note: candidate function not viable: no
overload of 'size' matching 'unsigned int' for 1st argument
operator(unsigned int __n)
^
/usr/include/c++/4.3/ostream:203:7: note: candidate function not viable: no
overload of 'size' matching 'long long' for 1st argument
operator(long long __n)
^
/usr/include/c++/4.3/ostream:207:7: note: candidate function not viable: no
overload of 'size' matching 'unsigned long long' for 1st argument
operator(unsigned long long __n)
^
/usr/include/c++/4.3/ostream:212:7: note: candidate function not viable: no
overload of 'size' matching 'double' for 1st argument
operator(double __f)
^
/usr/include/c++/4.3/ostream:216:7: note: candidate function not viable: no
overload of 'size' matching 'float' for 1st argument
operator(float __f)
^
/usr/include/c++/4.3/ostream:224:7: note: candidate function not viable: no
overload of 'size' matching 'long double' for 1st argument
operator(long double __f)
^
/usr/include/c++/4.3/ostream:228:7: note: candidate function not viable: no
overload of 'size' matching 'const void *' for 1st argument
operator(const void* __p)
^
/usr/include/c++/4.3/ostream:253:7: note: candidate function not viable: no
overload of 'size' matching '__streambuf_type *' (aka 'basic_streambufchar,
std::char_traitschar *') for 1st argument
operator(__streambuf_type* __sb);
^
/usr/include/c++/4.3/ostream:449:5: note: candidate function [with _CharT =
char, _Traits = std::char_traitschar] not viable: no overload of 'size'
matching 'char' for 2nd argument
operator(basic_ostream_CharT, _Traits __out, _CharT __c)
^
/usr/include/c++/4.3/ostream:454:5: note: candidate function [with _CharT =
char, _Traits = std::char_traitschar] not viable: no overload of 'size'
matching 'char' for 2nd argument
operator(basic_ostream_CharT, _Traits __out, char __c)
^
/usr/include/c++/4.3/ostream:460:5: note: candidate function [with _Traits =
std::char_traitschar] not viable: no overload of 'size' matching 'char' for
2nd argument
operator(basic_ostreamchar, _Traits __out, char __c)
^
/usr/include/c++/4.3/ostream:466:5: note: candidate function [with _Traits =
std::char_traitschar] not viable: no overload of 'size' matching 'signed
char' for 2nd argument
operator(basic_ostreamchar, _Traits __out, signed char __c)
^
/usr/include/c++/4.3/ostream:471:5: note: candidate function [with _Traits =
std::char_traitschar] not viable: no overload of 'size' matching 'unsigned
char' for 2nd argument
operator(basic_ostreamchar, _Traits __out, unsigned char __c)
^
/usr/include/c++/4.3/ostream:491:5: note: candidate function [with _CharT =
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-20 14:01:55 UTC --- Ira, thanks for your help, I'll continue working on this now. To vincenzo, this patch isn't finished, so it is premature to test it.
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Known to work||4.5.4 Summary|C_Sizeof: Rejects valid |[4.6/4.7 regression] |code|C_Sizeof: Rejects valid ||code Known to fail||4.6.2, 4.7.0 --- Comment #3 from kargl at gcc dot gnu.org 2011-09-20 14:51:25 UTC --- (In reply to comment #2) I'm seeing this bug even for an explicitly interoperable type (hence I'm not sure if this is really the same bug - I'm happy to file a new one if someone tells me to): print *, c_sizeof(0.0_c_double) 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable data entity GNU Fortran (Ubuntu 4.6.0-1ubuntu1~ppa2) 4.6.1 20110326 (prerelease) This is now a regression. troutmask:sgk[208] gfc45 -o z foo.f90 troutmask:sgk[209] ./z 8 troutmask:sgk[210] gfc46 -o z foo.f90 foo.f90:3.25: print '(I0)', c_sizeof(0.0_c_double) 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable data entity troutmask:sgk[211] cat foo.f90 program foo use iso_c_binding print '(I0)', c_sizeof(0.0_c_double) end program foo
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #4 from kargl at gcc dot gnu.org 2011-09-20 14:57:00 UTC --- (In reply to comment #3) (In reply to comment #2) I'm seeing this bug even for an explicitly interoperable type (hence I'm not sure if this is really the same bug - I'm happy to file a new one if someone tells me to): print *, c_sizeof(0.0_c_double) 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable data entity GNU Fortran (Ubuntu 4.6.0-1ubuntu1~ppa2) 4.6.1 20110326 (prerelease) This is now a regression. troutmask:sgk[208] gfc45 -o z foo.f90 troutmask:sgk[209] ./z 8 troutmask:sgk[210] gfc46 -o z foo.f90 foo.f90:3.25: print '(I0)', c_sizeof(0.0_c_double) 1 Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable data entity troutmask:sgk[211] cat foo.f90 program foo use iso_c_binding print '(I0)', c_sizeof(0.0_c_double) end program foo This seems to be a bug only when the actual argument is parameter. program foo use iso_c_binding real(c_double) x print *, c_sizeof(x) end program foo works as expected.
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-20 15:35:00 UTC --- r158253 is OK r162456 gives the error.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #16 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-20 15:39:41 UTC --- (In reply to comment #15) BTW since the exception seems to be thrown from libuno_cppuhelpergcc3.so.3 that sounds like there is some sort of gcc specific magic that has good chance to break with LTO, I would suggest to try to compile that dso w/o linktime (you only need to add -fno-use-linker-plugin -fno-lto) and hopefully we get past this issue? Unfortunately it's not that simple. It looks like several libraries in solver/unxlngx6.pro/lib are broken when they are build with LTO. What I've done is to copy working libraries from a non LTO build into solver/unxlngx6.pro/lib, until soffice.bin no longer crashes. But even cp /lib_working/*gcc* solver/unxlngx6.pro/lib isn't enough. You have to look at the back-traces to get an idea about what to copy next. And after copying many libs soffice.bin will no longer crash... I haven't found out exactly what libs are affected yet, because I've copied them in large chunks.
[Bug c++/50464] New: Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50464
Bug #: 50464
Summary: Using -Ofast -march=bdver1 results in internal
compiler error: in extract_insn, at recog.c:2109
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com
Compiling following reduced test case gets the compiler error:
DataspaceIdentifier.cpp: In function 'void createDataspaceIdentifier()':
DataspaceIdentifier.cpp:172:1: error: unrecognizable insn:
(insn 88 87 89 11 (set:V2DI (reg:V2DI 144)
(if_then_else:V2DI (reg:V2DI 146)
(const_vector:V2DI [
(const_int -1 [0x])
(const_int -1 [0x])
])
(reg:V2DI 122 [ vect_var_.44 ]))) DataspaceIdentifier.cpp:155 -1
(nil))
DataspaceIdentifier.cpp:172:1: internal compiler error: in extract_insn, at
recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ g++ --version
g++ (GCC) 4.6.1 20110627 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat DataspaceIdentifier.cpp
typedef long unsigned int size_t;
typedef unsigned long ulong_t;
typedef signed long slong_t;
extern C++ {
void* operator new(size_t);
}
templatetypename _Iterator
struct iterator_traits
{
typedef typename _Iterator::reference reference;
};
templatetypename _Tp
struct iterator_traits_Tp*
{
typedef _Tp reference;
};
templatetypename _Iterator, typename _Container
class __normal_iterator
{
protected:
_Iterator _M_current;
typedef iterator_traits_Iterator __traits_type;
public:
typedef typename __traits_type::reference reference;
explicit
__normal_iterator(const _Iterator __i) : _M_current(__i) { }
reference
operator*() const
{ return *_M_current; }
__normal_iterator
operator++()
{
++_M_current;
return *this;
}
const _Iterator
base() const
{ return _M_current; }
};
templatetypename _Iterator, typename _Container
inline bool
operator!=(const __normal_iterator_Iterator, _Container __lhs,
const __normal_iterator_Iterator, _Container __rhs)
{ return __lhs.base() != __rhs.base(); }
templatetypename _Tp
class allocator
{
public:
typedef _Tp* pointer;
typedef _Tp value_type;
templatetypename _Tp1
struct rebind
{ typedef allocator_Tp1 other; };
pointer allocate(size_t __n, const void* = 0)
{
return static_cast_Tp*(::operator new(__n * sizeof(_Tp)));
}
};
templatetypename _Tp, typename _Alloc
struct _Vector_base
{
typedef typename _Alloc::template rebind_Tp::other _Tp_alloc_type;
struct _Vector_impl
: public _Tp_alloc_type
{
typename _Tp_alloc_type::pointer _M_start;
typename _Tp_alloc_type::pointer _M_finish;
typename _Tp_alloc_type::pointer _M_end_of_storage;
_Vector_impl(_Tp_alloc_type const __a) { }
};
public:
typedef _Alloc allocator_type;
_Vector_base(size_t __n, const allocator_type __a)
: _M_impl(__a)
{
this-_M_impl._M_start = this-_M_allocate(__n);
this-_M_impl._M_finish = this-_M_impl._M_start;
this-_M_impl._M_end_of_storage = this-_M_impl._M_start + __n;
}
public:
_Vector_impl _M_impl;
typename _Tp_alloc_type::pointer
_M_allocate(size_t __n)
{ return __n != 0 ? _M_impl.allocate(__n) : 0; }
};
templatetypename _Tp, typename _Alloc = allocator_Tp
class vector : protected _Vector_base_Tp, _Alloc
{
typedef _Vector_base_Tp, _Alloc _Base;
typedef typename _Base::_Tp_alloc_type _Tp_alloc_type;
public:
typedef _Tp value_type;
typedef typename _Tp_alloc_type::pointer pointer;
typedef __normal_iteratorpointer, vector iterator;
typedef _Alloc allocator_type;
protected:
using _Base::_M_allocate;
using _Base::_M_impl;
public:
explicit
vector(size_t __n, const value_type __value = value_type(),
const allocator_type __a = allocator_type())
: _Base(__n, __a)
{ _M_fill_initialize(__n, __value); }
iterator begin()
{ return iterator(this-_M_impl._M_start); }
iterator end()
{ return iterator(this-_M_impl._M_finish); }
protected:
void
_M_fill_initialize(size_t __n, const value_type __value)
{
this-_M_impl._M_finish =
[Bug fortran/50463] [4.6/4.7 Regression] -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-20 16:57:28 UTC --- This is caused/exposed by revision 165422 Author: rguenth Date: Wed Oct 13 13:03:31 2010 New Revision: 165422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165422 Log: 2010-10-13 Richard Guenther rguent...@suse.de PR tree-optimization/45970 * tree-ssa-alias.h (stmt_kills_ref_p): Declare. * tree-ssa-alias.c (stmt_kills_ref_p_1): New function. (stmt_kills_ref_p): Likewise. * tree-ssa-dse.c (dse_optimize_stmt): Use it. * gcc.dg/tree-ssa/ssa-dse-13.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-dse.c If I revert the patch for trunk/gcc/tree-ssa-dse.c in revision 179007, the wrong code is fixed (however gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-13.c fails). I don't know if the cause is in the fortran front-end or in the middle-end, but in my opinion writing such code is asking for trouble;-(
[Bug fortran/50463] [4.6/4.7 Regression] -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 --- Comment #5 from manz at intes dot de 2011-09-20 17:11:56 UTC --- (In reply to comment #2) I confirm the problem on 4.6.1 and trunk, but the code seems to work as expected with 4.5.3 and 4.4.6. It also works if I merge the three files in one, or if I use -flto. Assuming that the test is coming from a bigger project, could you try -flto on it? I have never tried -flto on the complete source since its too big (more than 4.5 million lines of Fortran code).
[Bug target/50464] Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50464 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-20 Target Milestone|--- |4.6.2 Ever Confirmed|0 |1 Known to fail||4.6.2, 4.7.0 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-09-20 17:18:29 UTC --- Confirmed.
[Bug target/50465] New: [avr] Use insn attribute to depict if and how instruction lengths have to be adjusted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50465 Bug #: 50465 Summary: [avr] Use insn attribute to depict if and how instruction lengths have to be adjusted Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: g...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr At current, avr.c:adjust_insn_length() uses bunch of C-code to find out if and how instruction lengths have to be adjusted. This can be done in a more legible way by means of a new insn attribute.
[Bug target/50465] [avr] Use insn attribute to depict if and how instruction lengths have to be adjusted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50465 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-20 CC||eric.weddington at atmel ||dot com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug target/50464] Using -Ofast -march=bdver1 results in internal compiler error: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50464 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-09-20 17:59:37 UTC --- Created attachment 25328 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25328 Patch to fix the ICE. Can you please test the attached patch?
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
jules at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||jules at gcc dot gnu.org
Resolution|FIXED |
--- Comment #9 from jules at gcc dot gnu.org 2011-09-20 19:03:43 UTC ---
This appears to have regressed on mainline. I now get the following assembly
output for the test case added by Maxim:
longfunc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd sp!, {r4, r5}
umull r4, r5, r0, r2
mul r3, r0, r3
mla r1, r2, r1, r3
mov r0, r4
add r1, r1, r5
ldmfd sp!, {r4, r5}
bx lr
[Bug c++/50442] [4.6 regression] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-09-20 19:25:36 UTC --- Author: jason Date: Tue Sep 20 19:25:32 2011 New Revision: 179015 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179015 Log: PR c++/50442 * g++.dg/overload/ref-conv1.C: New. Added: trunk/gcc/testsuite/g++.dg/overload/ref-conv1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/50466] New: Compiled code behaves differently with -O2 -fPIC flag combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50466
Bug #: 50466
Summary: Compiled code behaves differently with -O2 -fPIC
flag combination
Classification: Unclassified
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hmil...@gluster.com
Compiled code behaves differently with -O2 -fPIC flag combination. Taking out
either of the flags makes the compiled code behave predictably.
Also, commenting out certain lines in the code (highlighted as comments) makes
the code compile predictably even in the presence of -O2 -fPIC.
Other compiler versions always behave predictably for this test case.
#include stdlib.h
#include assert.h
#include stdio.h
struct list_head {
struct list_head *next;
struct list_head *prev;
};
struct pool {
struct list_head list;
int count;
unsigned long size;
void *slab;
};
char global_init;
/* Uncommenting the prototype with attribute masks the bug */ //void *__calloc
(size_t nmemb, size_t size) __attribute_malloc__;
void *
__calloc (size_t nmemb, size_t size)
{
return calloc (nmemb, size);
}
void
pool_validate (struct pool *pool)
{
struct list_head *list = NULL;
struct list_head *head = NULL;
int count = 0;
head = pool-list;
for (list = head-next; list != head; list = list-next) {
count++;
}
if (pool-count == count) {
printf (GOOD :)\n);
} else {
printf (BAD :(\n);
}
}
struct pool *
pool_new (int size, int count)
{
struct pool *pool = NULL;
void *slab = NULL;
int i = 0;
struct list_head *list = NULL;
struct list_head *head = NULL;
/* commenting the below line hides the bug */
do { if (!global_init) break; } while (0);
pool = __calloc (sizeof (*pool), 1);
if (!pool)
return NULL;
head = pool-list;
head-next = head-prev = head;
pool-size = size;
pool-count = count;
slab = __calloc (count, size);
if (!slab) {
free (pool);
return NULL;
}
for (i = 0; i count; i++) {
list = slab + (i * (size));
list-next = list-prev = list;
list-next = head;
list-prev = head-prev;
list-next-prev = list;
list-prev-next = list;
}
pool-slab = slab;
return pool;
}
int main (int argc, char *argv[])
{
struct pool *pool = NULL;
pool = pool_new (1024, 1024);
pool_validate (pool);
return 0;
}
-
blackhole:~/comp-bug # gcc --version
gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] Copyright (C) 2008 Free
Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
blackhole:~/comp-bug # make all
gcc-4.3 -Wall -O0 -fPIC pool.c -o good
gcc-4.3 -Wall -O2 -fPIC pool.c -o bad
./good
GOOD :)
./bad
BAD :(
[Bug c/50466] Compiled code behaves differently with -O2 -fPIC flag combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50466 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-20 21:00:55 UTC --- 4.3.x is no longer maintained and had at least one known strict aliasing bug. Try 4.5.x or 4.6.x.
[Bug target/50467] New: Compiler can move stack cleanup before last memory reference involving the stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50467 Bug #: 50467 Summary: Compiler can move stack cleanup before last memory reference involving the stack Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: meiss...@gcc.gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux In looking at the 462.libquantum spec 2006 benchmark, we noticed that the addi used to undo the stack frame before the return is done can be moved above memory operations involving the stack. In the example we noticed (specrand.c), it was using a convert 32-bit integer to floating point sequence. On all powerpc processors except for power6x, this conversion involves doing a store to the stack and a reload into the FPR, since there is no move GPR to FPR instruction. However, the LFIWAX and LFIWZX instructions do not have a reg+offset form, and only support reg+reg. The Altivec and VSX vector instructions are similar in only having reg+reg forms. The address that is used to reference the stack does not have the stack pointer in it, so the scheduler thinks there is no conflict in moving it up.
[Bug target/50467] Compiler can move stack cleanup before last memory reference involving the stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50467 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org 2011-09-20 21:04:17 UTC --- Created attachment 25329 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25329 Code from the libquantum benchmark.
[Bug c++/45114] implement C++0x alias-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | --- Comment #7 from Dodji Seketeli dodji at gcc dot gnu.org 2011-09-20 21:24:27 UTC --- Mine
[Bug lto/50468] New: ICE in force_type_die when compiling binutils with -flto -O[12]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50468 Bug #: 50468 Summary: ICE in force_type_die when compiling binutils with -flto -O[12] Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Got this when building binutils-2.21.53.20110810 from source using g++-4.6.real (Ubuntu/Linaro 4.6.1-9ubuntu3) or g++-4.7.0 20110914 on Ubuntu 11.10 amd64: g++ -W -Wall-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=ld-new -g -flto -O2 -Wl,-Bsymbolic-functions -o ld-new main.o i386.o x86_64.o sparc.o powerpc.o arm.o arm-reloc-property.o libgold.a ../libiberty/libiberty.a -ldl -lz -lm incremental.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters In member function ‘__base_ctor ’: lto1: internal compiler error: in force_type_die, at dwarf2out.c:21022 Interestingly, changing -O2 to -O1 introduces this variation: incremental.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters In file included from ../../gold/incremental.h:5152:0, from :4601: ../../gold/icf.h: In member function ‘__base_dtor ’: ../../gold/icf.h:62:5: internal compiler error: in force_type_die, at dwarf2out.c:21022
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2011-09-20 22:19:38 UTC --- I haven't found out exactly what libs are affected yet, because I've copied them in large chunks. Hmm, this is quite weird. I am not aware of any really important LTO related wrong code issues (and in general my experience is that LTO tends to ICE or produce missing symbols, not really produce wrong code that often). So my bet would be that libreoffice uses some tricks that breaks with LTO and we will need to idenitfy which one. If you could look into it, perhaps it would be interesting to identify smallest library that misoptimize and see what is happening with it. One common cause of problems is that -flto confuse the configure scripts. Some of configure tests are written in a way so LTO optimize the interesting part away and the test always pass. This usually leads to some link/parse errors but it also might break other things. Since you have both lto and non-lto builds, you could compare the config caches and see if they match? Thanks! Honza
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386
--- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-09-20
22:32:49 UTC ---
I think this is a bootstrap issue rather than a problem with libgomp . A
reduced testcase of this form fails with the stage2 compiler but is ok with the
stage1 compiler.
struct gomp_work_share
{
/* This member records the SCHEDULE clause to be used for this construct.
The user specification of runtime will already have been resolved.
If this is a SECTIONS construct, this value will always be DYNAMIC. */
union {
struct {
/* This is the chunk_size argument to the SCHEDULE clause. */
long chunk_size;
/* This is the iteration end point. If this is a SECTIONS construct,
this is the number of contained sections. */
long end;
/* This is the iteration step. If this is a SECTIONS construct, this
is always 1. */
long incr;
}u;
};
}a;
Where the stage2 compiler goes :
/home/4/t1.i:21:3: warning: unnamed struct/union that defines no instances
[enabled by default]
and the stage1 compiler goes quietly.
Could you check if you see similar behaviour ?
Ramana
[Bug fortran/50469] New: [4.7 Regression] FAIL: gfortran.dg/storage_size_2.f08
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50469 Bug #: 50469 Summary: [4.7 Regression] FAIL: gfortran.dg/storage_size_2.f08 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 179013 gave FAIL: gfortran.dg/storage_size_2.f08 -O (test for errors, line 17) FAIL: gfortran.dg/storage_size_2.f08 -O (test for errors, line 17) FAIL: gfortran.dg/storage_size_2.f08 -O (test for errors, line 20) FAIL: gfortran.dg/storage_size_2.f08 -O (test for errors, line 20) FAIL: gfortran.dg/storage_size_2.f08 -O (test for excess errors) FAIL: gfortran.dg/storage_size_2.f08 -O (test for excess errors) Revision 179007 is OK.
[Bug testsuite/50469] [4.7 Regression] FAIL: gfortran.dg/storage_size_2.f08
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50469 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-09-20 22:59:53 UTC --- Author: hjl Date: Tue Sep 20 22:59:49 2011 New Revision: 179022 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179022 Log: Replace must be be with must be. 2011-09-20 H.J. Lu hongjiu...@intel.com PR testsuite/50469 * gfortran.dg/storage_size_2.f08: Replace must be be with must be. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/storage_size_2.f08
[Bug testsuite/50469] [4.7 Regression] FAIL: gfortran.dg/storage_size_2.f08
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50469 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||FIXED --- Comment #2 from kargl at gcc dot gnu.org 2011-09-20 23:15:40 UTC --- HJ Thanks for catching this issue. It never occurred to me that someone might actually write must be be in an error message, and then test for that string in the testsuite. I'm closing this as fixed. Sorry about the noise in your tester.
[Bug c++/49488] [C++0x] Use 'final' for devirtualization purposes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49488 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-20 23:44:07 UTC --- Implemented with: 2011-09-20 Roberto Agostino Vitillo raviti...@lbl.gov * call.c (build_new_method_call_1): Use non-virtual lookup for final virtual functions.
[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #58 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-20 23:45:12 UTC --- I think this is completely done by now.
[Bug driver/50470] New: gcc does not respect -nostdlib with regard to search paths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50470 Bug #: 50470 Summary: gcc does not respect -nostdlib with regard to search paths Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: bug...@aerifal.cx Even with -nostdlib, gcc leaves the default library paths in the search path, including /usr/lib (in the form of /usr/lib/gcc/targetstring/version/../../..). This makes -nostdlib basically useless for its only foreseeable purpose, building programs against a completely alternate library ecosystem(*). The only workaround I've found is installing a wrapper script with -wrapper to remove the unwanted paths. (*) Leaving default paths in the search path after the custom ones is not acceptable because configure scripts will find and attempt to use libraries in the default paths if the corresponding library does not exist in the custom path.
[Bug driver/50470] gcc does not respect -nostdlib with regard to search paths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50470 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-21 01:20:48 UTC --- I think this is why GCC created the --with-sysroot option while building GCC itself. And really -nostdlib is not just for alternate library ecosystem. It is so you can supply all the libraries you want to link against explicitly. It is used to link glibc and other libc's tobegin with. Also if you list the full path to the library there is no search involved.
[Bug driver/50470] gcc does not respect -nostdlib with regard to search paths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50470 --- Comment #2 from Rich Felker bugdal at aerifal dot cx 2011-09-21 01:34:29 UTC --- The sysroot features may be nice but they're not a substitute for being able to eliminate the default library search path. For example, when using sysroot, -L/new/path will prepend the sysroot to /new/path.
[Bug target/50467] Compiler can move stack cleanup before last memory reference involving the stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50467 Alan Modra amodra at gmail dot com changed: What|Removed |Added Target|powerpc64-linux |powerpc-linux, powerpc-eabi Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2011-09-21 CC||amodra at gmail dot com Host|powerpc64-linux |powerpc-linux Ever Confirmed|0 |1 Build|powerpc64-linux |powerpc-linux --- Comment #2 from Alan Modra amodra at gmail dot com 2011-09-21 01:53:33 UTC --- I believe this is another instance of PR30282 but with access to a compiler generated stack temp rather than an auto var moving past the stack update.
[Bug c++/50471] New: Qualified lookup fails to find template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50471 Bug #: 50471 Summary: Qualified lookup fails to find template function Classification: Unclassified Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zol...@epochcapital.com.au Please see the attached sample file, functions g1() and g2() should produce the same output, but they do not. The difference is that g2() finds a template function when called with an unqualified name, g1() does not find the template function when called with a qualified name. GCC version: [zoltan@epcau-srv-dev:test]$ g++-4.5 -v Using built-in specs. Reading specs from /usr/lib64/gcc/x86_64-suse-linux/4.5/defaults.spec COLLECT_GCC=g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.5/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,fortran --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.5.0 20100414 [gcc-4_5-branch revision 158342] (SUSE Linux)
[Bug c++/50471] Qualified lookup fails to find template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50471 --- Comment #1 from Zoltan Glozik zoltan at epochcapital dot com.au 2011-09-21 05:41:57 UTC --- Created attachment 25330 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25330 bug
[Bug c++/50471] Qualified lookup fails to find template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50471
--- Comment #2 from Zoltan Glozik zoltan at epochcapital dot com.au
2011-09-21 05:43:44 UTC ---
Comment on attachment 25330
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25330
bug
#include iostream
namespace NS {
templateclass T
struct A {
T t;
};
templateclass T
void f(T t)
{
std::cout function 1 std::endl;
}
templateclass T
void g1(T t)
{
// qualify with namespace
NS::f(t);
}
templateclass T
void g2(T t)
{
// do not qualify with namespace
f(t);
}
templateclass T
void f(AT t)
{
std::cout function 2 std::endl;
}
}
int main()
{
using namespace NS;
Aint a;
g1(a); // this should print: function 2, bug?
g2(a); // this prints function 2 correctly.
return 0;
}
