[Bug c++/48525] New: -O0 produces incorrect results for inlined functions sharing the same name.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48525
Summary: -O0 produces incorrect results for inlined functions
sharing the same name.
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jroel...@gmail.com
When compiling multiple files with inline functions which share the same
signature and name -O0 produces results inconsistent with -O1, -O2, and -O3
(which produce the expected result).
% g++ -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~123/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
% cat double.cpp
inline int sharedname(int a)
{
return a + a;
}
int doub(int a)
{
return sharedname(a);
}
% cat square.cpp
inline int sharedname(int a)
{
return a * a;
}
int square(int a)
{
return sharedname(a);
}
% cat main.cpp
#include stdio.h
int square(int a);
int doub(int a);
int main(int argc, char*argv[])
{
printf(square(3): %d\n, square(3));
printf(doub(3): %d\n, doub(3));
}
% g++ main.cpp double.cpp square.cpp -Wall -O3 ./a.out
square(3): 9
doub(3): 6
% g++ main.cpp double.cpp square.cpp -Wall -O2 ./a.out
square(3): 9
doub(3): 6
% g++ main.cpp double.cpp square.cpp -Wall -O1 ./a.out
square(3): 9
doub(3): 6
% g++ main.cpp double.cpp square.cpp -Wall -O0 ./a.out
square(3): 6
doub(3): 6
Notice that the last version with -O0 enabled produces 6 instead of 9 for
square(3).
[Bug c++/48525] -O0 produces incorrect results for inlined functions sharing the same name.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48525 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-04-09 08:09:36 UTC --- This violates the ODR. [dcl.fct.spec] 4 An inline function shall be defined in every translation unit in which it is used and shall have exactly the same definition in every case (3.2).
[Bug c++/48525] -O0 produces incorrect results for inlined functions sharing the same name.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48525 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-09 09:52:01 UTC --- (In reply to comment #0) When compiling multiple files with inline functions which share the same signature and name -O0 produces results inconsistent with -O1, -O2, and -O3 (which produce the expected result). As Andreas said, this is an One Definition Rule violation, you need to make the functions static or put them in an anonymous namespace if you want to have a different definition in each file. gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) This compiler is not supported by the GCC project, the oldest supported release is 4.3 You should report issues with your compiler to Apple.
[Bug libstdc++/48526] New: [C++0x] std::is_constructiblevoid, Args...::value shall be false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48526
Summary: [C++0x] std::is_constructiblevoid, Args...::value
shall be false
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
According to N3242 20.9.4.3 clause 6, the expression
std::is_constructible void, Args... ::value
shall be false for any type pack 'Args',
because a variable definition
void t( createArgs... );
is ill-formed, given the following function prototype:
template class T
typename std::add_rvalue_referenceT::type create();
But gcc-4.6.0 rejects all following static_assert:
-
#include type_traits
int main()
{
static_assert( !std::is_constructiblevoid::value, );
static_assert( !std::is_constructiblevoid, int::value, );
static_assert( !std::is_constructiblevoid, int, double::value, );
}
[Bug rtl-optimization/48389] [4.5/4.6 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #14 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2011-04-09 10:08:57 UTC --- On Fri, Apr 8, 2011 at 1:38 PM, matz at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #10 from Michael Matz matz at gcc dot gnu.org 2011-04-08 11:37:59 UTC --- I was asking what specifically doesn't work. I.e. why the changes to cfgbuild were necessary. I'm not so dense to not understand that it doesn't work. But you are so dense to not look at all information in the PR? :-P I had made PR48486 blocking this one. It explains what the cfgbuild.c changes were supposed to resolve.
[Bug objc/48527] New: Incorrect list of methods in @protocol used across compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48527
Summary: Incorrect list of methods in @protocol used across
compilation units
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
I'm using GCC 4.6.0.
The following example shows things working correctly when a protocol is used
in the same compilation unit:
[nicola@lampone ~]$ cat x1.m
#include objc/runtime.h
@protocol A
- (void) test;
@end
int main (void)
{
Protocol *p = @protocol (A);
struct objc_method_description method = protocol_getMethodDescription (p,
@selector (test),
YES,
YES);
printf (Protocol name is %s\n, protocol_getName (p));
printf (Method is %s, %s\n, sel_getName (method.name), method.types);
return 0;
}
[nicola@lampone ~]$ gcc x1.m -lobjc
x1.m: In function ‘main’:
x1.m:13:3: warning: incompatible implicit declaration of built-in function
‘printf’ [enabled by default]
[nicola@lampone ~]$ ./a.out
Protocol name is A
Method is test, v8@0:4
[nicola@lampone ~]$
This shows the protocol being recognized, and the full list of methods being
available when you introspect the protocol. :-)
But, if you move the @protocol to another compilation unit, things stop
working! :-(
[nicola@lampone ~]$ cat x2.m
#include objc/runtime.h
@protocol A;
int main (void)
{
Protocol *p = @protocol (A);
struct objc_method_description method = protocol_getMethodDescription (p,
@selector (test),
YES,
YES);
printf (Protocol name is %s\n, protocol_getName (p));
printf (Method is %s, %s\n, sel_getName (method.name), method.types);
return 0;
}
[nicola@lampone ~]$ gcc x2.m -c
x2.m: In function ‘main’:
x2.m:11:3: warning: incompatible implicit declaration of built-in function
‘printf’ [enabled by default]
[nicola@lampone ~]$ cat x3.m
#include objc/runtime.h
@protocol A
- (void) test;
@end
[nicola@lampone ~]$ gcc x3.m -c
[nicola@lampone ~]$ gcc x2.o x3.o -lobjc
[nicola@lampone ~]$ ./a.out
Protocol name is A
Method is null selector, (null)
[nicola@lampone ~]$
As you can see, in this case the protocol looks good if you check only the
name, but it isn't, since the method is not there in the list of protocol
methods!
Thanks
[Bug objc/48527] Incorrect list of methods in @protocol used across compilation units
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48527 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.09 10:47:15 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-04-09 10:47:15 UTC --- The testcases/examples confirm it. Thanks
[Bug libstdc++/48521] [4.5/4.6/4.7 Regression] [C++0x] std::result_of doesn't work with pointer to member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48521 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-09 10:55:02 UTC --- (In reply to comment #0) This means we don't accept std::async(X::foo, ...) Oops, meant to say std::async(X::foo, ...)
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-09 11:28:33 UTC --- Specs are an internal GCC implementation detail, subject to change whenever convenient for implementation purposes. (Whoever put documentation for them in invoke.texi was wrong to do so - and as far as I know, did not have FSF permission either for copying text from gcc.c under one license to invoke.texi under another - the comment starting Specs are strings containing lines is the proper documentation for specs.) My recommendation in http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01486.html for certain broken -D specs in GCC was that any required semantics should be moved into cc1. We have for a long time been moving away from defining built-in macros in specs, towards defining them based on actual logical state derived from option processing. In any case if you wish to submit a patch for some new specs feature I would suggest you include the --enable-fortify-source=2 or similar configure option with it to provide some actual use for that feature in GCC. Note that the spec you give appears wrong in that any -D_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=value option passed by the user should presumably also disable a default -D_FORTIFY_SOURCE=2 option; maybe you actually want an if-macro-not-defined spec function that covers all these cases.
[Bug c++/48528] New: [4.6 Regression] FAIL: g++.dg/cpp0x/sfinae10.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48528 Summary: [4.6 Regression] FAIL: g++.dg/cpp0x/sfinae10.C (test for excess errors) Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ja...@redhat.com On Linux/x86, revision 172224 gave FAIL: g++.dg/cpp0x/sfinae10.C (test for excess errors) Excess errors: /export/gnu/import/svn/gcc-test/src-4.6/gcc/testsuite/g++.dg/cpp0x/sfinae10.C:16:38: error: cannot allocate an object of abstract type 'A' /export/gnu/import/svn/gcc-test/src-4.6/gcc/testsuite/g++.dg/cpp0x/sfinae10.C:13:8: note: because the following virtual functions are pure within 'A': /export/gnu/import/svn/gcc-test/src-4.6/gcc/testsuite/g++.dg/cpp0x/sfinae10.C:13:20: note: virtual A::~A() This is added by revision 172193: http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00388.html
[Bug target/48529] New: [x32] Testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48529
Summary: [x32] Testsuite failures
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
When configured with
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++,fortran --prefix=/usr/gcc-4.7.0-x32
--with-local-prefix=/usr/local --enable-gnu-indirect-function --enable-x32
--enable-cloog-backend=isl --with-ppl-include=/opt/gnu/include
--with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include
--with-cloog-lib=/opt/gnu/lib64 --with-fpmath=sse
compared with -m64,
make -k check RUNTESTFLAGS=--target_board='unix{-mx32}'
has following extra failures:
FAIL: 27_io/basic_filebuf/close/char/4879.cc execution test
FAIL: 27_io/basic_filebuf/close/char/9964.cc execution test
FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test
FAIL: 27_io/basic_filebuf/imbue/wchar_t/14975-2.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/char/26777.cc execution test
FAIL: 27_io/basic_filebuf/underflow/char/10097.cc execution test
FAIL: 27_io/objects/char/7.cc execution test
FAIL: 27_io/objects/char/9661-1.cc execution test
FAIL: 27_io/objects/wchar_t/7.cc execution test
FAIL: 27_io/objects/wchar_t/9661-1.cc execution test
FAIL: ext/ext_pointer/1.cc execution test
FAIL: gcc.c-torture/execute/builtins/strcspn.c execution, -O1
FAIL: gcc.dg/20020219-1.c execution test
FAIL: gcc.dg/c99-stdint-1.c (test for excess errors)
FAIL: gcc.target/i386/pr39543-3.c (test for excess errors)
FAIL: gcc.target/i386/pr43766.c scan-assembler-not lea[lq]?[ \t]
FAIL: g++.dg/abi/covariant3.C execution test
FAIL: g++.dg/abi/vcall1.C execution test
FAIL: g++.dg/inherit/covariant17.C execution test
FAIL: g++.dg/inherit/covariant18.C execution test
FAIL: g++.dg/inherit/covariant3.C execution test
FAIL: g++.dg/inherit/covariant4.C execution test
FAIL: g++.old-deja/g++.abi/vtable3a.C execution test
FAIL: g++.old-deja/g++.abi/vtable3b.C execution test
FAIL: g++.old-deja/g++.abi/vtable3c.C execution test
FAIL: g++.old-deja/g++.abi/vtable3d.C execution test
FAIL: g++.old-deja/g++.abi/vtable3e.C execution test
FAIL: g++.old-deja/g++.abi/vtable3f.C execution test
FAIL: g++.old-deja/g++.abi/vtable3g.C execution test
FAIL: g++.old-deja/g++.abi/vtable3h.C execution test
FAIL: g++.old-deja/g++.abi/vtable3i.C execution test
FAIL: g++.old-deja/g++.abi/vtable3j.C execution test
FAIL: g++.old-deja/g++.mike/p4736b.C execution test
FAIL: g++.old-deja/g++.mike/p4736c.C execution test
FAIL: g++.old-deja/g++.mike/virt2.C execution test
FAIL: g++.old-deja/g++.mike/virt5.C execution test
FAIL: g++.old-deja/g++.oliva/thunk1.C execution test
FAIL: libgomp.fortran/strassen.f90 -O execution test
FAIL: libmudflap.cth/pass37-frag.c execution test
FAIL: libmudflap.cth/pass37-frag.c output pattern test
FAIL: libmudflap.cth/pass39-frag.c execution test
FAIL: libmudflap.cth/pass39-frag.c output pattern test
FAIL: libmudflap.cth/pass39-frag.c (-O2) execution test
FAIL: libmudflap.cth/pass39-frag.c (-O2) output pattern test
FAIL: libstdc++-abi/abi_check
[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from John David Anglin danglin at gcc dot gnu.org 2011-04-09 15:21:21 UTC --- Fixed on trunk.
[Bug c/48509] Fails to Vectorize loop involving doubles which was vectorized in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48509 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-09 15:53:12 UTC --- Ok.
[Bug tree-optimization/48484] [4.7 Regression] ICE: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 with -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48484 --- Comment #3 from davidxl xinliangli at gmail dot com 2011-04-09 16:32:37 UTC --- Fixed in r172229. David
[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-04-09 16:36:28 UTC --- (In reply to comment #2) Can you try again after: 2011-04-08 Vladimir Makarov vmaka...@redhat.com PR 48435 * ira-color.c (setup_profitable_hard_regs): Add comments. Don't take prohibited hard regs into account. (setup_conflict_profitable_regs): Rename to get_conflict_profitable_regs. (check_hard_reg_p): Check prohibited hard regs. It doesn't help.
[Bug c++/48530] New: [C++0x][SFINAE] Hard errors with deleted d'tors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48530
Summary: [C++0x][SFINAE] Hard errors with deleted d'tors
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
The following program in C++0x mode is not well-formed, but should be:
templateclass T,
class = decltype(T())
char f(int);
templateclass
char (f(...))[2];
struct DelDtor {
~DelDtor() = delete;
};
static_assert(sizeof(fDelDtor(0)) != 1, Error);
error: use of deleted function ‘DelDtor::~DelDtor()’
Note: This should be a case where the revised decltype rules in regard to
complete types would not apply, so it should be well-formed even after
implementing this new rule.
[Bug c++/48525] -O0 produces incorrect results for inlined functions sharing the same name.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48525 --- Comment #3 from Jon Roelofs jroelofs at gmail dot com 2011-04-09 17:08:06 UTC --- (In reply to comment #2) (In reply to comment #0) When compiling multiple files with inline functions which share the same signature and name -O0 produces results inconsistent with -O1, -O2, and -O3 (which produce the expected result). As Andreas said, this is an One Definition Rule violation, you need to make the functions static or put them in an anonymous namespace if you want to have a different definition in each file. gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) This compiler is not supported by the GCC project, the oldest supported release is 4.3 You should report issues with your compiler to Apple. I get the same results on: gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) Would it not be prudent for g++ to at least emit a warning when the ODR is violated in cases like this?
[Bug c++/48531] New: [C++0x][SFINAE] Hard errors with arrays of unknown bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48531 Summary: [C++0x][SFINAE] Hard errors with arrays of unknown bound Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com CC: ja...@redhat.com The following program should be well-formed, but is not: templateclass T, class = decltype(T()) char f(int); templateclass char (f(...))[2]; static_assert(sizeof(fint[](0)) != 1, Error); cannot value-initialize array of unknown bound ‘int []’
[Bug preprocessor/48532] New: Wrong location of namespaced pragma involing macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48532
Summary: Wrong location of namespaced pragma involing macros
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: do...@gcc.gnu.org
ReportedBy: do...@gcc.gnu.org
Consider this test case taken from
gcc/testsuite/gcc.dg/gomp/preprocess-1.c:
[dodji@adjoa prtests]$ cat -n test.c
1void foo (void)
2{
3 int i1, j1, k1;
4#define p parallel
5#define P(x) private (x##1)
6#define S(x) shared (x##1)
7#define F(x) firstprivate (x##1)
8#pragma omp p P(i) \
9 S(j) \
10 F(k)
11 ;
12}
[dodji@adjoa prtests]$
And now consider its preprocessed output:
[dodji@adjoa prtests]$ cc1 -quiet -E -fopenmp ./test.c
# 1 ./test.c
# 1 interne
# 1 command-line
# 1 ./test.c
void foo (void)
{
int i1, j1, k1;
# 33554432 ./test.c
# 8 ./test.c
#pragma omp parallel private (i1) shared (j1) firstprivate (k1)
;
}
[dodji@adjoa prtests]$
This line in the output is wrong, and should not be present:
# 33554432 ./test.c
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524
--- Comment #2 from Ryan Hill dirtyepic at gentoo dot org 2011-04-09 18:51:20
UTC ---
Sorry, i just wanted a trivial example. The actual rule we use is
%{!D_FORTIFY_SOURCE:%{!D_FORTIFY_SOURCE=*:%{!U_FORTIFY_SOURCE:-D_FORTIFY_SOURCE=2}}}
but this is just one example of several. The reason we use specs instead of
just changing the default is so we can easily bypass them at runtime. This
allows us, for example, to have a single compiler for both normal and hardened
profiles.
I understand what you're saying, but it still seems like an omission to me to
not have a way to match switches with separate arguments. Surely this isn't
the only case where this is useful?
[Bug c++/48528] [4.6 Regression] FAIL: g++.dg/cpp0x/sfinae10.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48528 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-04-09 19:04:14 UTC --- Author: jason Date: Sat Apr 9 19:04:11 2011 New Revision: 172230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172230 Log: PR c++/48528 * g++.dg/cpp0x/sfinae10.C: Remove abstract class. Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/sfinae10.C
[Bug c++/48528] [4.6 Regression] FAIL: g++.dg/cpp0x/sfinae10.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48528 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-04-09 19:05:26 UTC --- Oops, that portion of the test depended on a patch I haven't applied to 4.6.
[Bug libgcj/48533] New: Installer fails on libjava component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48533 Summary: Installer fails on libjava component Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@worldlinc.net I just built gcc-4.6.0 with all components requested, built with /usr/local/ as prefix. Ada not built. On make install, libjava fails later in installation process because it tries to find and link a libppl file by looking in /usr/lib instead of /usr/local/lib. I copied the first not-found file into /usr/lib and it linked that and failed on the next one. This system has two versions of ppl and cloog files, 0.10.2 in /usr and 0.11 in /usr/local. The first is required for gcc-4.4.5 and the other for 4.6.0 and the linkers and installer should find the right version for the right gcc. The installer goes looking first in /usr/lib and fails, though. Why doesn't it at least use the system library path which is said to list /usr/local/lib before /usr/lib? The only references to the wrong prefix that I found in the top makefile and the libjava makefile are in the var oldincludedir=/usr/include.
[Bug preprocessor/48532] Wrong location of namespaced pragma involing macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48532 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.09 19:11:39 Ever Confirmed|0 |1 --- Comment #1 from Dodji Seketeli dodji at gcc dot gnu.org 2011-04-09 19:11:39 UTC --- In scan_translation_unit, It seems the call to cpp_get_token_with_location yields a location equals to zero. From there, bad things happen; basically maybe_print_line is passed a zero location. It looks up a location map for it, and that lookup yields the map that was created for location 1 (for builtins). The file path of that location is test.c (hence the test.c file on the wrong line) and the source line number is garbage, as that location map was never used to map location 0. I think cpp_get_token_with_location should not have returned a zero location to begin with.
[Bug middle-end/48464] [4.7 Regression] @171649: ICE in setup_pressure_classes, at ira.c:877
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48464 --- Comment #2 from Jan-Benedict Glaw jbg...@lug-owl.de 2011-04-09 20:58:00 UTC --- Just to mention: This is not an ICE that shows up on this specific code snipplet, but it is rather a start-up problem that either got merged in with the IRA update or was uncovered by it: vax-linux-gcc -c -x c /dev/null /dev/null:1:0: internal compiler error: in setup_pressure_classes, at ira.c:877 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (This is r172231 = d82cf2b25062950d .)
[Bug c++/48525] -O0 produces incorrect results for inlined functions sharing the same name.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48525 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added CC||d.g.gorbachev at gmail dot ||com --- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-04-09 21:08:05 UTC --- Would it not be prudent for g++ to at least emit a warning when the ODR is violated in cases like this? Gold (a linker) can detect such cases: $ g++ main.cpp double.cpp square.cpp -Wall -O0 -g -Wl,--detect-odr-violations /usr/local/bin/ld: warning: while linking a.out: symbol 'sharedname(int)' defined in multiple places (possible ODR violation): square.cpp:2 from /tmp/ccwt9DKt.o double.cpp:2 from /tmp/ccb8pMLx.o
[Bug libfortran/48511] Implement Steele-White algorithm for numeric output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.09 21:19:09 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2011-04-09 21:19:09 UTC --- Does any of the Fortran edit descriptors require, or for that matter allow, this kind of shortest decimal representation output? If not, the one place where I see this could be useful if we decide to change list formatted output to always use the shortest field width for variables, as some other compilers do. However, the output part is only half of the puzzle; if we do this we must make sure that the input routines are able to convert the shortest decimal representation into the correct binary representation. FWIW, rather than the Steele White algorithm or the Burger one, most actual uses seems to use David Gay's implementation for performance reasons. AFAIK glibc uses code based on Gay's, and also libquadmath in turn uses code based on glibc. So maybe we can find something there. There's also libjava/classpath/native/fdlibm/dtoa.c . For some discussion about issues with this kind of conversions, see e.g. http://bugs.python.org/issue1580
[Bug c++/48534] New: [C++0x][SFINAE] Compiler break down on explicit scoped enum = bool conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48534 Summary: [C++0x][SFINAE] Compiler break down on explicit scoped enum = bool conversion Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com CC: ja...@redhat.com The following code should be ill-formed, but is not: //-- templateclass T T create(); templateclass T, class U, class = decltype(static_castT(createU())) char f(int); templateclass, class char (f(...))[2]; enum class SEB : bool; static_assert(sizeof(fbool, SEB(0)) == 1, Error); // # something that went wrong...; // Should be ill-formed, but is not //-- After the line marked with # the compiler does no longer compile code, but dies a silent death. Any following lines are ignored. It seems that this is specifically isolated to a conversion from a scoped enum *with underlying type bool* to bool.
[Bug c++/48535] New: [C++0x][SFINAE] Hard errors during list-value-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48535
Summary: [C++0x][SFINAE] Hard errors during
list-value-initialization
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
In several situations during list-initialization with an empty braced list gcc
produces either hard errors:
a) abstract class
b) function type
c) class type with deleted destructor
d) binding a temporary to a reference to non-const
e) binding a temporary to a reference to const
or accepts ill-formed code:
f) attempting to produce a zero-length array
//-
templateclass T,
class = decltype(T{})
char f(int);
templateclass
char (f(...))[2];
struct A { virtual ~A() = 0; };
struct NonDtor {
~NonDtor() = delete;
};
static_assert(sizeof(fA(0)) != 1, Error); // (a)
static_assert(sizeof(fvoid()(0)) != 1, Error); // (b)
static_assert(sizeof(fNonDtor(0)) != 1, Error); // (c)
static_assert(sizeof(fint(0)) != 1, Error); // (d)
static_assert(sizeof(fconst int(0)) == 1, Error); // (e)
static_assert(sizeof(fint[](0)) != 1, Error); // (f)
//-
(a): error: cannot allocate an object of abstract type ‘A’ because the
following virtual functions are pure within ‘A’
(b): error: compound literal of non-object type ‘void()’
(c): error: use of deleted function ‘NonDtor::~NonDtor()’
(d): error: compound literal of non-object type ‘int’
(e): error: compound literal of non-object type ‘const int’
(f): Assertion triggers!
[Bug c++/48536] New: C++0x Automatic Enumerator Incrementation is not compliant with Clause 7.2/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48536
Summary: C++0x Automatic Enumerator Incrementation is not
compliant with Clause 7.2/5
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shaw.joh...@gmail.com
The enumerations defined below are well-formed C++0x, but g++, with C++0x
extensions enabled, still treats #1 as an overflow error.
Note: Comeau C/C++ 4.3.10.1 with C++0x extensions enabled reports no errors.
#include climits
//
// g++ version 4.5.2 and below
//
// Compiler options:
//-std=c++0x
//-std=gnu++0x
// non-compliant error message:
//error: overflow in enumeration values
//
// According to C++ draft N1905 (2005) and above / Clause 7.2/5
// The following enumeration is well-formed.
//
enum Enum_Inc { EI_1=UINT_MAX, EI_2 }; // #1
// The above should be equivalent to the following
enum Enum_Inc2 { FI_1=UINT_MAX, FI_2=FI_1+1 }; // #2
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-10 00:27:28 UTC ---
On Sat, 9 Apr 2011, dirtyepic at gentoo dot org wrote:
Sorry, i just wanted a trivial example. The actual rule we use is
%{!D_FORTIFY_SOURCE:%{!D_FORTIFY_SOURCE=*:%{!U_FORTIFY_SOURCE:-D_FORTIFY_SOURCE=2}}}
but this is just one example of several. The reason we use specs instead of
just changing the default is so we can easily bypass them at runtime. This
allows us, for example, to have a single compiler for both normal and hardened
profiles.
I understand what you're saying, but it still seems like an omission to me to
not have a way to match switches with separate arguments. Surely this isn't
the only case where this is useful?
The same principle applies that if you wish to submit a patch to add such
a feature it is desirable to have a (properly functional) use case in FSF
GCC, as code with no such use case is liable to be removed in cleanups.
[Bug libstdc++/48526] [C++0x] std::is_constructiblevoid, Args...::value shall be false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48526 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-10 00:45:26 UTC --- For 4.7 we'll have a completely new implementation, conforming to N3242. Will not happen in 4_6-branch though.
[Bug c++/48537] New: C++0x: ICE using union with non-trivial member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48537
Summary: C++0x: ICE using union with non-trivial member
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yacw...@gmail.com
Target: x86_64-unknown-linux-gnu
Created attachment 23936
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23936
Test source - ICEs.
If a union contains a member with a non-trivial default constructor, attempting
to explicitly call (or decltype) the default constructor results in an ICE.
(This relates to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf, implemented
in GCC 4.6)
Simplest example (attached).
== union-non-trivial-member-simple.cpp
struct SFoo
{
SFoo() =delete;
};
union UFoo
{
SFoo foo;
};
int main()
{
UFoo();
}
g++ union-non-trivial-member-simple.cpp -std=c++0x
../union-non-trivial-member-simple.cpp: In function ‘int main()’:
../union-non-trivial-member-simple.cpp:13:8: internal compiler error: in
build_value_init_noctor, at cp/init.c:374
NOTE: Line may not be 374 for you.
I've indicated the line here:
=== cp/init.c ==
build_value_init_noctor (tree type, tsubst_flags_t complain)
{
if (CLASS_TYPE_P (type))
{
gcc_assert (!TYPE_NEEDS_CONSTRUCTING (type)); // ( THIS LINE!!
if (TREE_CODE (type) != UNION_TYPE)
{
- Works as expected (error but no ICE) with copy constructor, assignment or
destructor.
- Works as expected (error but no ICE) for implicit declaration (eg: UFoo
foo;).
- Can reject valid code if using SFINAE.
USEFULNESS:
I am attempting to use SFINAE (using decltype) on a template union containing a
given type to determine the trivial-ness of the given type's special member
functions.
[C++ standard:9.5.2]
...[Note: If any non-static data member of a union has a non-trivial default
constructor (12.1 [class.ctor]), copy constructor (12.8 [class.copy]), copy
assignment operator (12.8 [class.copy]), or destructor (12.4 [class.dtor]), the
corresponding member function of the union must be user-declared or it will be
implicitly deleted (8.4 [dcl.fct.def]) for the union. —end note]
Which (I hope) should allow classifications like trivial class to be
calculated without relying on compiler-specific stuff.
SPECS:
gcc: version 4.7.0 2011-04-05 (experimental) (svn = 171986)
gcc: version 4.6.0 2011-02-13 (experimental) (svn = 170074)
- tested with both.
- both GCCs manually patched by
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html)
- patch is unlikely to have any effect.
ubuntu: 10.10 (64 bit)
intel: core2 duo
HTH.
Simon.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #58 from Dongsheng Song dongsheng.song at gmail dot com 2011-04-10 04:32:23 UTC --- (In reply to comment #57) (In reply to comment #56) What works for me on Cygwin, and so may well also work for anyone using MSYS, is setting the heap_chunk_in_mb registry parameter to some value in the range 1024 - 1536. I use 1024 myself and that gives me sufficient headroom to link libgcj dll, which is huge; if it works for that, it's likely to help with wx dll as well. http://cygwin.com/cygwin-ug-net/setup-maxmem.html I don't think so. Because I observed ld.exe use memory over 1.7GB, so link wx monolithic library require use more memory than 32 bit OS limit. For cross compile under Linux, link wx can use near 3G memory, it still failed. Then link wx require 4G or more memory, maybe someone can try use 64bit linker to build single huge monolithic library, tell us the max memory ld used. I test on 64bit Linux VM, after ld running 6 CPU hours, use 4728MB memory, still not finished, so I think there maybe have potential infinite loop and memory leaks when link many object files. I don't know this is GCC bug, or ld bug, or both ? http://sourceware.org/bugzilla/show_bug.cgi?id=12658 ld running 6 hours cpu time, use 4.6GB memory: VmPeak: 4776608 kB VmSize: 4734656 kB VmLck: 0 kB VmHWM: 3020260 kB VmRSS: 2982304 kB VmData: 4728000 kB VmStk: 100 kB VmExe: 912 kB VmLib: 1504 kB VmPTE: 9232 kB Threads:1 Cpu(s): 7.9%us, 11.5%sy, 0.0%ni, 44.4%id, 33.3%wa, 0.2%hi, 2.7%si, 0.0%st Mem: 3095296k total, 3073516k used,21780k free, 16k buffers Swap: 7811064k total, 3905532k used, 3905532k free, 9484k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1110 dongshen 20 0 4623m 2.8g 196 D 49 96.1 358:15.13 ld
