[Bug c/53580] Internal Segmentation fault in nested omp parallel, omp parallel for and omp parallel for reduction Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-05 06:34:08 UTC --- I'll look at it, but note that your testcase is invalid OpenMP.
[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-06-05 08:29:39 UTC --- (In reply to comment #7) Hans-Peter and Greta, Could you please test trunk and, if the commit above fixes the issue for you, close the bug please? Yes, thanks. The witch is cooked (SCNR :)
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #6 from Keean Schupke ke...@fry-it.com 2012-06-05 09:06:01 UTC ---
The suggested work around in the error message 'adding -fpermissive' to
gcc-4.7.0 does not fix the problem as suggested by the error message. This
would suggest the compiler is not displaying the correct error message for the
problem.
g++ -fpermissive test.cpp
Still generates:
test.cpp: In instantiation of ‘T f(T) [with T = int]’:
test.cpp:27:9: required from here
test.cpp:18:12: error: ‘g’ was not declared in this scope, and no declarations
were found by argument-dependent lookup at the point of instantiation
[-fpermissive]
test.cpp:21:5: note: ‘int g(int)’ declared here, later in the translation unit
A further test:
int g(int x) {
return x + 1;
}
char g(char x) {
return x - 1;
}
template typename T T f(T t) {
return g((T)t);
}
double g(double x) {
return x;
}
main() {
double x(f(1.0L));
}
generates the following compile time error:
test.cpp: In instantiation of ‘T f(T) [with T = long double]’:
test.cpp:18:17: required from here
test.cpp:10:15: error: call of overloaded ‘g(long double)’ is ambiguous
test.cpp:10:15: note: candidates are:
test.cpp:1:5: note: int g(int)
test.cpp:5:6: note: char g(char)
Which is interesting as it suggests that the overloading of 'g' is happening
from the definitions of 'g' that are in scope at the template definition. This
is quite strange behaviour, as the compiler must have to capture a list all
available overloads at the time of definition of each template. This looks like
a deliberate behaviour rather than a bug.
So this looks more like a misunderstanding of the specification is the cause of
this incorrect behaviour?
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-06-05 09:21:49 UTC --- It seems that __builtin_sh_media_FMAC_S is broken on trunk in the first place, though I can test it only on sh64-elf environment now. Anyway the patch should OK in this regard. Looking into the __builtin_sh_media_FMAC_S implementation, it takes 2 floating arguments and one return float value. It looks that a = __builtin_sh_media_FMAC_S (b, c) was expected to work. I guess that this is broken in concept. We can make it take 3 arguments but I suspect that no one has used it at all. It might be better to simply remove this intrinsic because now your patch makes fma usable naturally.
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-05 09:24:48 UTC --- Author: rguenth Date: Tue Jun 5 09:24:43 2012 New Revision: 188232 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188232 Log: 2012-06-05 Richard Guenther rguent...@suse.de PR tree-optimization/53081 * tree-loop-distribution.c (generate_memset_builtin): Handle all kinds of byte-sized stores. (classify_partition): Likewise. (tree_loop_distribution): Adjust seed statements used for !flag_tree_loop_distribution. * gcc.dg/tree-ssa/ldist-19.c: New testcase. * gcc.c-torture/execute/builtins/builtins.exp: Always pass -fno-tree-loop-distribute-patterns. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp trunk/gcc/tree-loop-distribution.c
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-06-05 10:02:25 UTC --- (In reply to comment #6) The suggested work around in the error message 'adding -fpermissive' to gcc-4.7.0 does not fix the problem as suggested by the error message. This would suggest the compiler is not displaying the correct error message for the problem. g++ -fpermissive test.cpp Still generates: test.cpp: In instantiation of ‘T f(T) [with T = int]’: test.cpp:27:9: required from here test.cpp:18:12: error: ‘g’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] test.cpp:21:5: note: ‘int g(int)’ declared here, later in the translation unit With GCC 4.8 revision 187148, -fpermissive generates a warning as it should. However, -fpermissive is not meant to fix anything, it is just a work-around to make non-standard code compile. I am not sure if this is a bug or not, so I am not touching the status.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #8 from Keean Schupke ke...@fry-it.com 2012-06-05 10:15:18 UTC --- (In reply to comment #7) Have a read of the C++ standard, the example given in: N3242=11-0012 14.6 Name Resolution: paragraph 10 Which I have pasted above into comment #4 and the extract from C++ Special Edition (Technicalities C.13.8.3) which is pasted in comment #3. How do you interpret these two? (In reply to comment #6) The suggested work around in the error message 'adding -fpermissive' to gcc-4.7.0 does not fix the problem as suggested by the error message. This would suggest the compiler is not displaying the correct error message for the problem. g++ -fpermissive test.cpp Still generates: test.cpp: In instantiation of ‘T f(T) [with T = int]’: test.cpp:27:9: required from here test.cpp:18:12: error: ‘g’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] test.cpp:21:5: note: ‘int g(int)’ declared here, later in the translation unit With GCC 4.8 revision 187148, -fpermissive generates a warning as it should. However, -fpermissive is not meant to fix anything, it is just a work-around to make non-standard code compile. I am not sure if this is a bug or not, so I am not touching the status.
[Bug middle-end/30442] Expanded array initialization can use memset builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-05
10:50:22 UTC ---
The
long long test2(void)
{
long long a[32];
int i;
for (i = 0; i 32; i++)
a[i] = 0;
return foo(a);
}
loop is transformed to memset at -O3. The unrolled version is not re-rolled
still, and basic-block vectorization does not catch it because of the
call in the basic-block. I'm trying to fix that.
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 --- Comment #6 from Yuri Gribov tetra2005 at gmail dot com 2012-06-05 10:53:56 UTC --- Jan's suggestion indeed fixed the bug, thanks! Regarding Richard's suggestion: should we ask binutils guys to detect situation when LTO plugin fails to deliver symbols which it promised in resolution file and work around it? I think this would be a major refactor on their side.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 10:54:36 UTC --- (In reply to comment #2) The function called in the template definition is clearly dependent on the template parameter 'T' and therefore itsname should be resolved at the point of instantiation where 'g' is clearly defined and in scope (and is not local). The error message says: no declarations were found by argument-dependent lookup at the point of instantiation when 'g' should be found. Built-in types have no associated namespaces so ADL can not find 'g' via ADL. A declaration must be visible at the point of definition. The example in comment 1 is ill-formed. Paragraph 10 doesn't apply because the call is clearly dependent. N.B. N3242 is not the C++ standard and neither is C++ Special Edition which is quite old now.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 11:03:26 UTC --- (In reply to comment #6) The suggested work around in the error message 'adding -fpermissive' to gcc-4.7.0 does not fix the problem as suggested by the error message. As Manu says, -fpermissive changes the error to a warning, allowing the code to compile. Please check it again. I'm going to close this, as I think G++ handles comment 1 correctly and both EDG and Clang agree. I didn't check all your other examples in detail but I don't think they show anything different: ADL doesn't find anything for built-in types such as int or char.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #11 from Keean Schupke ke...@fry-it.com 2012-06-05 11:07:14 UTC --- (In reply to comment #9) Can you point me at where in the specification this is defined? (In reply to comment #2) The function called in the template definition is clearly dependent on the template parameter 'T' and therefore itsname should be resolved at the point of instantiation where 'g' is clearly defined and in scope (and is not local). The error message says: no declarations were found by argument-dependent lookup at the point of instantiation when 'g' should be found. Built-in types have no associated namespaces so ADL can not find 'g' via ADL. A declaration must be visible at the point of definition. The example in comment 1 is ill-formed. Paragraph 10 doesn't apply because the call is clearly dependent. N.B. N3242 is not the C++ standard and neither is C++ Special Edition which is quite old now.
[Bug c/53580] Internal Segmentation fault in nested omp parallel, omp parallel for and omp parallel for reduction Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580 Fernando G. Tinetti fernando at info dot unlp.edu.ar changed: What|Removed |Added CC||fernando at info dot ||unlp.edu.ar --- Comment #2 from Fernando G. Tinetti fernando at info dot unlp.edu.ar 2012-06-05 11:07:07 UTC --- (In reply to comment #1) I'll look at it, but note that your testcase is invalid OpenMP. We saw this with Federico, and we agree in that the testcase is invalid OpenMP code. Furthermore: 1) the compiler message is right. 2) should the compiler report an error instead of a warning? (I don't know what the compiler is required to report...). Fernando.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #12 from Keean Schupke ke...@fry-it.com 2012-06-05 11:14:00 UTC
---
(In reply to comment #10)
although -fpermissive allows the code to compile (in some circumstances) it
does not in all, and it also produces incorrect output, for example:
#include iostream
char g(char x) {
return x - 1;
}
template typename T T f(T t) {
return g(t);
}
double g(double x) {
return x;
}
main() {
double x(f(1.0L));
std::cout x \n;
}
will output 0 instead of 1 choosing the wrong overloaded function. In the
case below:
#include iostream
char g(char x) {
return x - 1;
}
int g(int x) {
return x + 1;
}
template typename T T f(T t) {
return g(t);
}
double g(double x) {
return x;
}
main() {
double x(f(1.0L));
std::cout x \n;
}
compilation still fails with:
test.cpp: In instantiation of ‘T f(T) [with T = long double]’:
test.cpp:20:17: required from here
test.cpp:12:12: error: call of overloaded ‘g(long double)’ is ambiguous
test.cpp:12:12: note: candidates are:
test.cpp:3:6: note: char g(char)
test.cpp:7:5: note: int g(int)
even with -fpermissive
(In reply to comment #6)
The suggested work around in the error message 'adding -fpermissive' to
gcc-4.7.0 does not fix the problem as suggested by the error message.
As Manu says, -fpermissive changes the error to a warning, allowing the code
to
compile. Please check it again.
I'm going to close this, as I think G++ handles comment 1 correctly and both
EDG and Clang agree.
I didn't check all your other examples in detail but I don't think they show
anything different: ADL doesn't find anything for built-in types such as int
or
char.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #13 from Keean Schupke ke...@fry-it.com 2012-06-05 11:25:40 UTC
---
(In reply to comment #9)
From ISO14882 14.6 - Name resolution [temp.res]
-8- When looking for the declaration of a name used in a template definition,
the usual lookup rules (basic.lookup.unqual, basic.lookup.koenig) are used for
nondependent names. The lookup of names dependent on the template parameters is
postponed until the actual template argument is known (temp.dep). [Example:
#include iostream
using namespace std;
templateclass T class Set {
T* p;
int cnt;
public:
Set();
SetT(const SetT);
void printall()
{
for (int i = 0; icnt; i++)
cout p[i] '\n';
}
// ...
};
in the example, i is the local variable i declared in printall, cnt is the
member cnt declared in Set, and cout is the standard output stream declared in
iostream. However, not every declaration can be found this way; the resolution
of some names must be postponed until the actual template-arguments are known.
For example, even though the name operator is known within the definition of
printall() and a declaration of it can be found in iostream, the actual
declaration of operator needed to print p[i] cannot be known until it is
known what type T is (temp.dep). ]
-9- If a name does not depend on a template-parameter (as defined in temp.dep),
a declaration (or set of declarations) for that name shall be in scope at the
point where the name appears in the template definition; the name is bound to
the declaration (or declarations) found at that point and this binding is not
affected by declarations that are visible at the point of instantiation.
[Example:
void f(char);
templateclass T void g(T t)
{
f(1); // f(char)
f(T(1));// dependent
f(t); // dependent
dd++; // not dependent
// error: declaration for dd not found
}
void f(int);
double dd;
void h()
{
g(2); // will cause one call of f(char) followed
// by two calls of f(int)
g('a'); // will cause three calls of f(char)
}
So it was like this in 1998, and it is the same in the latest working draft.
--- end example]
(In reply to comment #2)
The function called in the template definition is clearly dependent on the
template parameter 'T' and therefore itsname should be resolved at the
point of
instantiation where 'g' is clearly defined and in scope (and is not local).
The
error message says: no declarations were found by argument-dependent
lookup at
the point of instantiation when 'g' should be found.
Built-in types have no associated namespaces so ADL can not find 'g' via ADL.
A
declaration must be visible at the point of definition.
The example in comment 1 is ill-formed.
Paragraph 10 doesn't apply because the call is clearly dependent.
N.B. N3242 is not the C++ standard and neither is C++ Special Edition which
is quite old now.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 11:31:07 UTC --- [temp.dep.res] says dependent name resolution considers declarations visible at the point of definition, and declarations from associated namespaces from the instantiation context and the definition context. [basic.lookup.argdep]/2 says If T is a fundamental type, its associated sets of namespaces and classes are both empty.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 11:33:59 UTC --- (In reply to comment #12) (In reply to comment #10) although -fpermissive allows the code to compile (in some circumstances) it does not in all, and it also produces incorrect output, for example: -fpermissive is a kluge to allow non-standard code to compile, so *obviously* it gives the wrong result in some cases, that's the point! It allows comment 1 to compile, as the diagnostic indicates. If you don't like the results of using -fpermissive then fix your code and don't use it.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #16 from Keean Schupke ke...@fry-it.com 2012-06-05 11:53:32 UTC
---
(In reply to comment #14)
Basic.lookup.argdep is not specific to templates, so why does the dependent
lookup work outside of templates?
int g(int x) {
return x - 1;
}
double g(double x) {
return x + 1.0L;
}
main() {
int x(g(1.0L));
}
why does ADL work here if [basic.lookup.argdep] means what you imply?
[temp.dep.res] says dependent name resolution considers declarations visible
at
the point of definition, and declarations from associated namespaces from the
instantiation context and the definition context.
[basic.lookup.argdep]/2 says If T is a fundamental type, its associated sets
of namespaces and classes are both empty.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #16 from Keean Schupke ke...@fry-it.com 2012-06-05 11:53:32 UTC
---
(In reply to comment #14)
Basic.lookup.argdep is not specific to templates, so why does the dependent
lookup work outside of templates?
int g(int x) {
return x - 1;
}
double g(double x) {
return x + 1.0L;
}
main() {
int x(g(1.0L));
}
why does ADL work here if [basic.lookup.argdep] means what you imply?
[temp.dep.res] says dependent name resolution considers declarations visible
at
the point of definition, and declarations from associated namespaces from the
instantiation context and the definition context.
[basic.lookup.argdep]/2 says If T is a fundamental type, its associated sets
of namespaces and classes are both empty.
--- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05
11:53:55 UTC ---
(In reply to comment #13)
double dd;
void h()
{
g(2); // will cause one call of f(char) followed
// by two calls of f(int)
g('a'); // will cause three calls of f(char)
}
So it was like this in 1998, and it is the same in the latest working draft.
(Please stop quoting large chunks of copyrighted documents.)
No it isn't the same, the example above was incorrect and different in C++11,
see DR 197: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197
[Bug fortran/50619] Surprising interaction between -finit-real=NAN and the associate construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619 --- Comment #6 from Stephan Weller gcc.10.dimsea at spamgourmet dot org 2012-06-05 11:56:59 UTC --- Great, this fixes the problem for me. In current svn revision, -finit-real=NAN works as expected. Thanks for keeping up the good work!
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 11:57:20 UTC --- (In reply to comment #16) why does ADL work here if [basic.lookup.argdep] means what you imply? That's not ADL, so I don't know what you're asking. Bugzilla is not the right place to learn C++, please take this to an appropriate forum.
[Bug middle-end/30442] Expanded array initialization can use memset builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-05 12:38:30 UTC --- Author: rguenth Date: Tue Jun 5 12:38:26 2012 New Revision: 188235 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188235 Log: 2012-06-05 Richard Guenther rguent...@suse.de PR tree-optimization/30442 * tree-vect-data-refs.c (vect_analyze_data_refs): For basic-block vectorization stop analysis at the first stmt we cannot compute a data-reference for instead of giving up completely. * gcc.dg/vect/bb-slp-30.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/bb-slp-30.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug middle-end/30442] Expanded array initialization can use memset builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-05 12:39:29 UTC --- So, $summary is still true but we now at least vectorize the initialization.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #19 from Keean Schupke ke...@fry-it.com 2012-06-05 12:55:06 UTC --- (In reply to comment #18) Sorry about that. It does indeed seem that the combination of [temp.dep.res] and [basic.lookup.argdep] imply this behaviour. I think my point was more about why it is different from usual lookup, any you are quite right this is not the place for that discussion. (In reply to comment #16) why does ADL work here if [basic.lookup.argdep] means what you imply? That's not ADL, so I don't know what you're asking. Bugzilla is not the right place to learn C++, please take this to an appropriate forum.
[Bug fortran/50619] Surprising interaction between -finit-real=NAN and the associate construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-05 13:05:38 UTC --- Author: burnus Date: Tue Jun 5 13:05:31 2012 New Revision: 188237 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188237 Log: 2012-06-05 Tobias Burnus bur...@net-b.de PR fortran/50619 * resolve.c (build_default_init_expr): Don't initialize ASSOCIATE names. 2012-06-05 Tobias Burnus bur...@net-b.de PR fortran/50619 * gfortran.dg/init_flag_10.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/init_flag_10.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/53581] New: Segmentation fault when enabling -std=c++0x on template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53581 Bug #: 53581 Summary: Segmentation fault when enabling -std=c++0x on template code Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgg...@gmail.com Created attachment 27560 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27560 The code that crashes gcc When compiling the attached code like this: g++ foo.cpp then everything works fine. As soon as I enable c++0x: g++ -std=c++0x foo.cpp I get this error: ... foo.cpp:36:7: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. ... --- The full output of /usr/bin/g++ -v -std=c++0x foo.cpp Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.7-20120505/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --enable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release --with-fpmath=sse Thread model: posix gcc version 4.7.0 20120505 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -quiet -v -D_GNU_SOURCE foo.cpp -quiet -dumpbase foo.cpp -mtune=generic -march=x86-64 -auxbase foo -std=c++11 -version -o /tmp/cc8d1FHu.s GNU C++ (GCC) version 4.7.0 20120505 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20120505 (prerelease), GMP version 5.0.5, MPFR version 3.1.0-p7, MPC version 0.9 warning: MPFR header version 3.1.0-p7 differs from library version 3.1.0-p10. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-unknown-linux-gnu /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed /usr/include End of search list. GNU C++ (GCC) version 4.7.0 20120505 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20120505 (prerelease), GMP version 5.0.5, MPFR version 3.1.0-p7, MPC version 0.9 warning: MPFR header version 3.1.0-p7 differs from library version 3.1.0-p10. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 06ee681e989ff71c2bb63d42d05c64ab foo.cpp: In instantiation of ‘ChildA, M, N BaseA, M, N::operator-(const BaseA, M, N) const [with A = float; int M = 3; int N = 3]’: foo.cpp:30:65: required from ‘bool OpsA, N::bar() const [with A = float; int N = 3]’ foo.cpp:40:18: required from here foo.cpp:36:7: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.archlinux.org/ for instructions.
[Bug target/53575] --with-abi=x32 without --with-multilib-list doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575
--- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-06-05
13:13:01 UTC ---
Author: hjl
Date: Tue Jun 5 13:12:52 2012
New Revision: 188240
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188240
Log:
Select x32 run-time library for --with-abi={x32|mx32}
PR target/53575
* config.gcc: Select x32 run-time library if --with-abi={x32|mx32}
is used for x86_64-*-*.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
[Bug target/53575] --with-abi=x32 without --with-multilib-list doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-06-05
13:13:01 UTC ---
Author: hjl
Date: Tue Jun 5 13:12:52 2012
New Revision: 188240
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188240
Log:
Select x32 run-time library for --with-abi={x32|mx32}
PR target/53575
* config.gcc: Select x32 run-time library if --with-abi={x32|mx32}
is used for x86_64-*-*.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-06-05 13:13:38
UTC ---
Fixed.
[Bug target/53575] --with-abi=x32 without --with-multilib-list doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-06-05 13:13:38 UTC --- Fixed.
[Bug c++/53581] Segmentation fault when enabling -std=c++0x on template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53581 --- Comment #1 from Jan Rüegg rggjan at gmail dot com 2012-06-05 13:19:58 UTC --- Might have to do something with: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53498
[Bug lto/50620] undefined reference errors / csmith lto testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50620 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added Status|NEW |RESOLVED Version|4.7.0 |4.8.0 Resolution||FIXED --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-06-05 16:04:46 UTC --- Fixed in 4.8.0
[Bug lto/50679] [meta-bug] Linux kernel LTO tracking bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-06-05 16:11:05 UTC --- (In reply to comment #2) I've seen a few strange segfaults while testing the LTO kernel however. For example: screen[1608]: segfault at 7fff42d73e98 ip 0040600a sp 7fff42d73ea0 error 6 in screen[40+55000] or zsh[1643]: segfault at 7f7980eb4000 ip 7f7981db6cb0 sp 7fff1f4b6dd8 error 7 in libc-2.14.90.so[7f7981d34000+15f000] But I'm not 100% sure, that they're really LTO related. No. It turned out that the segfaults above weren't related to LTO kernels.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-05 16:31:21 UTC --- I'm under the impression that the bug reports using the word 'broken' are the ones most likely broken, err invalid. Maybe just another manifestation of the illusion of confidence, well known to the psychologjsts? (for a very nice intro see, eg, Chabris Simons, 'The invisible gorilla', Ch 3)
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #21 from Keean Schupke ke...@fry-it.com 2012-06-05 17:01:01 UTC --- (In reply to comment #20) Yes, once again sorry. Obviously not GCC's problem for implementing the standard correctly, but this causes problems producing elegant datatype generic code. For example if a concept is defined in a library (using Boost Concept Checking for example) and I want to make 'int' comply to that concept, I would have to declare the new int methods before including the library. This seems very odd in end user code. In this case there is nothing intuitively wrong with the way GCC was doing it - it was not difficult for the compiler authors to implement, and nor did it lead to incorrect or hard to understand code, in fact it worked very well for generic programming. Is there any chance this 'feature' of GCC could be kept as a g++ specific extension in 'gnu++11' mode, as I think the old behaviour is an improvement over that suggested in the standard, and GCC provides other extensions to standard behaviour where it is useful. I'm under the impression that the bug reports using the word 'broken' are the ones most likely broken, err invalid. Maybe just another manifestation of the illusion of confidence, well known to the psychologjsts? (for a very nice intro see, eg, Chabris Simons, 'The invisible gorilla', Ch 3)
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 17:30:18 UTC --- (In reply to comment #21) Is there any chance this 'feature' of GCC could be kept as a g++ specific extension in 'gnu++11' mode, as I think the old behaviour is an improvement over that suggested in the standard, and GCC provides other extensions to standard behaviour where it is useful. I doubt it. The old behaviour was the source of several long-standing bug reports. Now G++ implements the standard's required behaviour and agrees with other leading compilers. GNU extensions usually allow new features by supporting new syntax not by changing the meaning of valid code, it would not be a pure extension.
[Bug c++/53582] New: [4.6 regression, fixed in 4.7, I think] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53582
Bug #: 53582
Summary: [4.6 regression, fixed in 4.7, I think] ICE on valid
code
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu
g++ -O2 segfaults on this code. Tested on gcc (GCC) 4.6.3 20120306 (Red Hat
4.6.3-2). 4.7 and trunk work. 4.5 seems okay as well.
struct A {
A();
};
unsigned f1();
void f2() {
while(true) {
unsigned x;
try {
f1();
} catch(char) {
x = (unsigned)-1;
}
if (x != 1) {
new A;
continue;
}
}
}
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-06-05 18:07:14 UTC --- OK, here's the problem: free_lang_data_in_type clears TYPE_CONTEXT of Holder. gen_tagged_type_die tries to emit an enclosing class first, but since TYPE_CONTEXT is null, it thinks Holder isn't a nested class. gen_struct_or_union_type_die calls scope_die_for, which forces out ExtensionCord, which also generates a DIE for Holder. gen_struct_or_union_type_die contiues to generate what is now a duplicate DIE for Holder. What is the rationale for clearing TYPE_CONTEXT of Holder? It seems quite deliberate, but there's no comment explaining why it would be a good idea.
[Bug libstdc++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 18:15:28 UTC --- some ideas at http://gcc.gnu.org/ml/libstdc++/2012-05/msg00085.html
[Bug libstdc++/53270] Error when bootstrapping gcc on hppa2.0-unknown-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org |
[Bug bootstrap/53583] New: gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 Bug #: 53583 Summary: gcc 4.6.2 build issue.. Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ravish_nayak2...@yahoo.co.in Hi I am trying to build gcc 4.6.2 from source on rhe5-x86_64 platform. with the following dependencies. gmp - 5.0.4 --- configure ABI=32 and ABI=64 (both option I tried) mpfr - 3.1.0 mpc - 0.9 ./configure --prefix=/path/ --with-gmp=/path --with-mpfr=/path --with-mpc=/path After 2 hrs I am getting lib/libgmp.so: could not read symbols: File in wrong format In some blog I found that gmp should support 32bit and 64bit otherwise use disable libjava option in config parameter to continue the gcc installation. We need libjava option too and cannot disable it. could you please provide us an alternative fix for this issue.. Regards, Ravish
[Bug bootstrap/53583] gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|critical|normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 19:32:11 UTC --- I cannot build gcc is not a bug, please use the gcc-help mailing list for help installing gcc, but first try the procedure described at http://gcc.gnu.org/wiki/InstallingGCC
[Bug target/53487] [4.8 Regression] Unrecognizable insn for conditional move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53487 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org 2012-06-05 19:40:39 UTC --- Author: meissner Date: Tue Jun 5 19:40:34 2012 New Revision: 188248 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188248 Log: [gcc] 2012-06-04 Michael Meissner meiss...@linux.vnet.ibm.com PR target/53487 * config/rs6000/rs6000.c (rs6000_generate_compare): If we are doing an unsigned compare, make sure the second argument is not a negative constant. (rs6000_emit_cmove): Don't allow floating point comparisons when generating ISEL moves. [gcc/testsuite] 2012-06-04 Michael Meissner meiss...@linux.vnet.ibm.com * gcc.target/powerpc/pr53487.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr53487.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/53583] gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-05 19:44:29 UTC --- Dup of bug 42750. Related to PR 39747 *** This bug has been marked as a duplicate of bug 42750 ***
[Bug libgcj/42750] OpenMP/gcc build fails with /usr/local/lib/libgmp.so: could not read symbols: File in wrong format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42750 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||ravish_nayak2003 at yahoo ||dot co.in --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-05 19:44:29 UTC --- *** Bug 53583 has been marked as a duplicate of this bug. ***
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-05 20:08:08 UTC --- (In reply to comment #4) Make -mfused-madd no-op instead to remove for the backward compatibility. Sorry, I don't quite follow. According to my understanding we have something like the following... (A): New behavior (attachment 27558, using common gcc/config/fused-madd.opt) (B): Old behavior (C): New behavior, with -mfused-madd being a nop | | (A) | (B)| (C) 1st option | 2nd option | fma pat. | fmac pat.| fma pat. (new) | | (new)| (old)| (mfused-madd = nop) =+==+==+==+== no option | -ffp-contract= | 1| 0| 1 | no opt = fast | | | -+--+--+--+-- no option | -fpp-contract=off| 0| 0| 0 -+--+--+--+-- -mfused-madd | -ffp-contract= | 1| 1| 1 | no opt = fast | | | -+--+--+--+-- -mno-fused-madd | -ffp-contract= | 0| 0| 0 | no opt = fast | | | -+--+--+--+-- -mfused-madd | -fpp-contract=off| 0| 1| 0 -+--+--+--+-- -mno-fused-madd | -fpp-contract=off| 0| 0| 0 -+--+--+--+-- -fpp-contract=off| -mfused-madd | 1| 1| 0 (*) -+--+--+--+-- -fpp-contract=off| -mno-fused-madd | 0| 0| 0 -+--+--+--+-- My intention was to avoid having any special -mfused-madd handling in the SH target code and to re-use the existing common gcc/config/fused-madd.opt. Making -mfused-madd a no-op with special handling will only differ in the (*) marked case. Is this what you had in mind?
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-05 20:12:51 UTC --- (In reply to comment #6) Looking into the __builtin_sh_media_FMAC_S implementation, it takes 2 floating arguments and one return float value. It looks that a = __builtin_sh_media_FMAC_S (b, c) was expected to work. I guess that this is broken in concept. I really wonder what the expected result should be in this case ;) We can make it take 3 arguments but I suspect that no one has used it at all. It might be better to simply remove this intrinsic because now your patch makes fma usable naturally. OK, I will just remove this built-in in the final patch.
[Bug c++/53584] New: [4.7 Regression] [C++0x] deleted function unique_ptr::operator=(const unique_ptr )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53584
Bug #: 53584
Summary: [4.7 Regression] [C++0x] deleted function
unique_ptr::operator=(const unique_ptr )
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lil...@gmail.com
The following code can compile with G++ 4.6 but not 4.7. G++ 4.7 complains
that the deleted function std::unique_ptr_Tp, _Dp::operator=(const
std::unique_ptr_Tp, _Dp) is required. However, please note that the code is
doing a move assignment. Strangely, removing the customized destructor
~UniqVec makes G++ 4.7 happy.
$ cat test.cpp
#include memory
#include vector
struct UniqVec : public std::vectorstd::unique_ptrint {
~UniqVec() {} // Comment this line out and GCC 4.7 will be happy.
};
void f() {
UniqVec u, v;
u = std::move(v);
}
$ g++ -c -std=c++0x test.cpp
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/memory:64:0,
from test.cpp:1:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:
In instantiation of ‘static _OI std::__copy_movefalse, false,
std::random_access_iterator_tag::__copy_m(_II, _II, _OI) [with _II = const
std::unique_ptrint*; _OI = std::unique_ptrint*]’:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:384:70:
required from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = const std::unique_ptrint*; _OI = std::unique_ptrint*]’
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:422:39:
required from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = __gnu_cxx::__normal_iteratorconst std::unique_ptrint*,
std::vectorstd::unique_ptrint ; _OI =
__gnu_cxx::__normal_iteratorstd::unique_ptrint*,
std::vectorstd::unique_ptrint ]’
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:454:18:
required from ‘_OI std::copy(_II, _II, _OI) [with _II =
__gnu_cxx::__normal_iteratorconst std::unique_ptrint*,
std::vectorstd::unique_ptrint ; _OI =
__gnu_cxx::__normal_iteratorstd::unique_ptrint*,
std::vectorstd::unique_ptrint ]’
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/vector.tcc:197:8:
required from ‘std::vector_Tp, _Alloc std::vector_Tp,
_Alloc::operator=(const std::vector_Tp, _Alloc) [with _Tp =
std::unique_ptrint; _Alloc = std::allocatorstd::unique_ptrint ]’
test.cpp:4:8: required from here
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:329:8:
error: use of deleted function ‘std::unique_ptr_Tp, _Dp std::unique_ptr_Tp,
_Dp::operator=(const std::unique_ptr_Tp, _Dp) [with _Tp = int; _Dp =
std::default_deleteint]’
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/memory:86:0,
from test.cpp:1:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/unique_ptr.h:257:19:
error: declared here
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/memory:64:0,
from test.cpp:1:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:
In instantiation of ‘static _OI std::__copy_movefalse, false,
std::random_access_iterator_tag::__copy_m(_II, _II, _OI) [with _II =
std::unique_ptrint*; _OI = std::unique_ptrint*]’:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:384:70:
required from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = std::unique_ptrint*; _OI = std::unique_ptrint*]’
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:422:39:
required from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = std::unique_ptrint*; _OI = std::unique_ptrint*]’
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:454:18:
required from ‘_OI std::copy(_II, _II, _OI) [with _II =
std::unique_ptrint*; _OI = std::unique_ptrint*]’
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/vector.tcc:202:8:
required from ‘std::vector_Tp, _Alloc std::vector_Tp,
_Alloc::operator=(const std::vector_Tp, _Alloc) [with _Tp =
std::unique_ptrint; _Alloc = std::allocatorstd::unique_ptrint ]’
test.cpp:4:8: required from here
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:329:8:
error: use of deleted function ‘std::unique_ptr_Tp, _Dp std::unique_ptr_Tp,
_Dp::operator=(const std::unique_ptr_Tp, _Dp) [with _Tp = int; _Dp =
std::default_deleteint]’
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/memory:86:0,
[Bug c++/53584] [4.7 Regression] [C++0x] deleted function unique_ptr::operator=(const unique_ptr )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53584 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 20:43:39 UTC --- This behaviour is required by C++11. A move assignment operator will not be implicitly declared for a class with a user-declared destructor. You can fix it by explicitly defaulting the move assignment operator: UniqVec operator=(UniqVec) = default;
[Bug c++/53584] [4.7 Regression] [C++0x] deleted function unique_ptr::operator=(const unique_ptr )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53584 --- Comment #2 from Ling Li liling at gmail dot com 2012-06-05 20:59:24 UTC --- You are right. My bad. I thought having a user-declared destructor would be different than having a user-declared constructor, and the fact that GCC 4.6 accepted the code doubled my belief. I should have checked the standard. Thanks for your time.
[Bug tree-optimization/53571] [4.6/4.7/4.8 regression] ICE with -O{2,3} -floop-parallelize-all in cloog_domain_stride()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53571 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-05 21:03:03 UTC --- (In reply to comment #1) Please specify the cloog/ppl versions you are using. What target is this on? I can reproduce it with the current GCC trunk on openSUSE Factory (x86-64) [package libcloog0-debuginfo-0.15.10+ppl-9.8]. Program received signal SIGSEGV, Segmentation fault. #0 0x2ace1656 in cloog_domain_stride (domain=optimized out, strided_level=optimized out, nb_par=optimized out, stride=0x7fffd5e0, offset=0x7fffd5d0) at source/ppl/domain.c:2813 #1 0x2acd7b21 in cloog_loop_stride_1 (nb_par=2, level=1, loop=0x15a8c20) at source/loop.c:1077 #2 cloog_loop_generate_general (loop=0x0, level=1, scalar=1, scaldims=0x158b000, nb_scattdims=3, nb_par=optimized out, options=0x1596780) at source/loop.c:1371 #3 0x2acd71f3 in cloog_loop_generate_scalar (options=0x1596780, nb_par=2, nb_scattdims=3, scaldims=0x158b000, scalar=0, level=1, loop=0x159c930) at source/loop.c:1489 #4 cloog_loop_generate (loop=optimized out, context=0x0, level=1, scalar=0, scaldims=0x158b000, nb_scattdims=3, nb_par=2, options=0x1596780) at source/loop.c:1573 #5 0x2ace834b in cloog_program_generate (program=0x1595d00, options=0x1596780) at source/program.c:687 #6 0x00cd34b5 in scop_to_clast (scop=0x158e890) at /home/tob/projects/gcc-git/gcc/gcc/graphite-clast-to-gimple.c:1551 #7 0x00cd36d5 in gloog (scop=0x158e890, bb_pbb_mapping=0x158e4f0) at /home/tob/projects/gcc-git/gcc/gcc/graphite-clast-to-gimple.c:1632 #8 0x00cd078e in graphite_transform_loops () at /home/tob/projects/gcc-git/gcc/gcc/graphite.c:276 #9 0x009e2c87 in graphite_transforms () at /home/tob/projects/gcc-git/gcc/gcc/tree-ssa-loop.c:254 The failing line is: cloog_vector_gcd (U-p[0], U-NbColumns, stride); The problem is that U-p == NULL. And U is initialized via cloog_solve_diophantine, cloog_matrix_hermite (temp, hermi, unimod); rank = cloog_dio_get_first_diagonal_zero (hermi); nbc = temp-NbColumns; ... *u = cloog_dio_init_U (unimodinv, hermi-NbColumns, rank); In the latter, one has: if (rank == n) return cloog_matrix_alloc (0, 0); And according to gdb rank==2 (the other arguments are optimized out). Well, and for a 0 argument, cloog_matrix_alloc sets u-p to NULL.
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-06-05 22:35:28 UTC --- (In reply to comment #7) Making -mfused-madd a no-op with special handling will only differ in the (*) marked case. Is this what you had in mind? Yes. -mfused-madd is for a micro optimization after all. It would be tolerable even if it can't generate fmac insns in the case like (*). OTOH deleting that option surprises the old programs which use -mfused-madd. I have no strong opinion, though. On second thought, -mfused-madd would be relatively rare in real use.
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-05 23:06:33 UTC --- (In reply to comment #9) Yes. -mfused-madd is for a micro optimization after all. It would be tolerable even if it can't generate fmac insns in the case like (*). OTOH deleting that option surprises the old programs which use -mfused-madd. I thought, that's what the common gcc/config/fused-madd.opt is for. It does not delete the old -mfused-madd option but issues a warning and sets -fpp-contract=fast. So older code that used -mfused-madd will continue to work as before. The big change will be for code that must not be compiled with FMA insns for 'a*b+c', because now GCC's behavior is to enable FMA by default. Those older programs will probably have no -mfused-madd option set and will have to be patched to add the -fpp-contract=off option anyway. I guess that this case will be the minority. Actually, adopting the -mfused-madd behavior from gcc/config/fused-madd.opt would allow to add a default option -fpp-contract=off for certain compiler builds (like -msoft-atomic on sh-linux) and then still allow programs to override this by specifying -mfused-madd. I have no strong opinion, though. On second thought, -mfused-madd would be relatively rare in real use. Yeah, probably. I also don't care that much which option is on/off by default. I just wanted it to be aligned with the other targets and the overall target independent GCC behavior, that's all :)
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #11 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-06-05 23:49:48 UTC --- (In reply to comment #10) Yeah, probably. I also don't care that much which option is on/off by default. I just wanted it to be aligned with the other targets and the overall target independent GCC behavior, that's all :) OK, please go ahead with the final patch as you like.
[Bug c++/53585] New: template value parameter of pointer-to-member type incorrectly rejects non-direct values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585
Bug #: 53585
Summary: template value parameter of pointer-to-member type
incorrectly rejects non-direct values
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yacw...@gmail.com
Created attachment 27561
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27561
c++ testcase - should be legal
Problem:
Pointer-to-member value parameters appear to only accept direct values (of the
immediate form X::Y) and reject passed constexpr variables.
llvm/clang++ accepts these.
I'm assuming this is legal but I haven't checked the standard.
specs: linux/x64
source (same as attached)
=
struct SFoo
{
int x;
};
constexpr int SFoo::* G_ptr_to_x = SFoo::x;
// Dummy test struct.
template int SFoo::* P
struct SBar {};
SBarG_ptr_to_x G_bar; // ERROR. (This should be legal, and is in clang).
// Additional testing:
SBarSFoo::x G_bar2; // Shows the member-pointer works if immediate.
constexpr int SFoo::* another_ptr = G_ptr_to_x; // Shows could not convert
... error message is incorrect.
int main()
{}
=
Errors (build command = g++ mptr.cpp -std=c++11).
=
test/misc/mptr.cpp:12:16: error: ‘G_ptr_to_x’ is not a valid template argument
for type ‘int SFoo::*’
SBarG_ptr_to_x G_bar; // ERROR. (This should be legal, and is in clang).
^
test/misc/mptr.cpp:12:16: error: it must be a pointer-to-member of the form
‘X::Y’
test/misc/mptr.cpp:12:16: error: could not convert template argument
‘G_ptr_to_x’ to ‘int SFoo::*’
test/misc/mptr.cpp:12:23: error: invalid type in declaration before ‘;’ token
SBarG_ptr_to_x G_bar; // ERROR. (This should be legal, and is in clang).
=
[Bug c++/53586] New: Internal compiler errors on cp/pt.c:12077 and expr.c:9147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53586
Bug #: 53586
Summary: Internal compiler errors on cp/pt.c:12077 and
expr.c:9147
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulotorr...@gnu.org
Trying to compile this small function:
templatetypename T auto ptr2bitmap(T *bitmap, int width, int depth = 3) -
typeof(typeof(unsigned char[depth])[width]) *{
return bitmap;
};
I got this:
Compiling `mjpeg.cpp'...
mjpeg.cpp: In substitution of 'templateclass T unsigned char (*
ptr2bitmap(T*, int, int))[width][depth] [with T = void]':
mjpeg.cpp:223:39: required from here
mjpeg.cpp:200:27: internal compiler error: in tsubst_copy, at cp/pt.c:12077
Please submit a full bug report,
with preprocessed source if appropriate.
See https://trac.macports.org/newticket for instructions.
make: *** [mjpeg.o] Error 1
And, trying to compile this code:
using uc3 = unsigned char[3];
using uc3w = uc3[width];
using uc3wp = uc3w *;
auto img = (uc3wp)rgb;
int w = 0;
for(w = 0; w font_GMT_width; w++) {
for(int y = 0; y font_height; y++) {
((img[y])[w])[0] = font_pixel(font_GMTX + w, y, 0);
((img[y])[w])[1] = font_pixel(font_GMTX + w, y, 1);
((img[y])[w])[2] = font_pixel(font_GMTX + w, y, 2);
};
};
auto add = [](int start) {
for(int x = 0; x font_char_width; x++, w++) {
for(int y = 0; y font_height; y++) {
((img[y])[w + x])[0] = font_pixel(start + x, y, 0);
((img[y])[w + x])[1] = font_pixel(start + x, y, 1);
((img[y])[w + x])[2] = font_pixel(start + x, y, 2);
};
};
};
auto add_colon = [] {
add(font_ColonX);
};
auto add_slash = [] {
add(font_SlashX);
};
I got this:
mjpeg.cpp: In static member function 'static void
std::_Function_handlervoid(_ArgTypes ...), _Functor::_M_invoke(const
std::_Any_data, _ArgTypes ...) [with _Functor = MJPEG::Video::addJpg(void*,
size_t, double, tm*) const::lambda(void*, size_t, size_t); _ArgTypes =
{void*, long unsigned int, long unsigned int}]':
mjpeg.cpp:228:20: internal compiler error: in expand_expr_real_1, at
expr.c:9147
Please submit a full bug report,
with preprocessed source if appropriate.
See https://trac.macports.org/newticket for instructions.
make: *** [mjpeg.o] Error 1
All tests were run on a Mac OS X Lion machine, and GCC as configured as follow:
../gcc-4.7.0/configure --prefix=/opt/local --build=x86_64-apple-darwin11
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.7 --with-libiconv-prefix=/opt/local
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.7 --with-gxx-include-dir=/opt/local/include/gcc47/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl
--enable-stage1-checking --disable-multilib --enable-lto
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc47 4.7.0_3'
[Bug c++/53586] Internal compiler errors on cp/pt.c:12077 and expr.c:9147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53586 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-06 05:58:39 UTC --- What happens if you use decltype instead of typeof ?
