[Bug c++/53505] New: bitfield with bool type generated broken object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53505
Bug #: 53505
Summary: bitfield with bool type generated broken object code
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rock...@gmail.com
compiler flag: -Wall -Wextra -O[0|1|2|3|fast]
All optimization levels: 1,2,3,fast reproduce the bug
-O0 is OK.
The expected output is 0
//
$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.0-RC-20120314/configure --prefix=/opt
--with-gmp=/opt --with-mpfr=/opt --with-mpc=/opt --with-ppl=/opt
--with-cloog=/opt --with-local-prefix=/opt --enable-languages=c,c++ :
(reconfigured) ../gcc-4.7.0-RC-20120314/configure --prefix=/opt --with-gmp=/opt
--with-mpfr=/opt --with-mpc=/opt --with-ppl=/opt --with-cloog=/opt
--with-local-prefix=/opt --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.7.0 20120314 (prerelease) (GCC)
//
#include
#include
#include
#include
#if 1
#define BIT bool // reproduce the bug
#else
#define BIT unsigned // bug vanished
#endif
struct A {
unsigned int a;
unsigned char c1, c2;
BIT b1 : 1;
BIT b2 : 1;
BIT b3 : 1;
A() {
memset(this, -1, sizeof(A));
a = 0;
c1 = c2 = 0;
b1 = 0;
b2 = 0;
b3 = 0;
}
};
void f(const std::vector& v) {
int s = 0;
for (int i = 0, n = v.size(); i < n; ++i) {
const A a = v[i]; // produce the bug
//const A&a = v[i]; // bug vanished if 'a' is a const reference
s += a.b1 ? 1 : 0;
}
printf("%d\n", s);
}
int main(int argc, char* argv[]) {
size_t size = argc < 2 ? 100 : atoi(argv[1]);
std::vector v(size);
f(v);
return 0;
}
[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson 2012-05-28 08:00:18 UTC --- (In reply to comment #0) > ../trunk/configure --prefix=$HOME --enable-languages=c,fortran > --disable-build-poststage1-with-cxx > > The error was: > > ../../trunk/gcc/fortran/decl.c: In function 'match_attr_spec': > ../../trunk/gcc/fortran/decl.c:3276:3: error: typedef 'decl_types' locally > defined but not used [-Werror=unused-local-typedefs] > decl_types; > ^ I got the same error. Deleting the unused type name and the 'typedef' keyword restores bootstrap for me.
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #13 from Jan Hubicka 2012-05-28 08:26:48 UTC --- Hehe, i still love them ;) But inline summaries are separate of cgraph, so it is not cgraph checker's work to verify it ;)) I think the problem is in new profile updating logic in unreachable node removal. I will look into it.
[Bug c++/53506] New: Variadic templates in combination with function pointer problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53506
Bug #: 53506
Summary: Variadic templates in combination with function
pointer problem
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o.mang...@googlemail.com
The example code below appears to be correct to me, but does not compiler with
g++. I tried it also with Intel compiler 12.1, and icc compiles it just fine.
Neither the first, nor the second version of the call of a() seems to work. It
can't deduce the template args from the function pointer and also does not
accept explicit specification. I had expected at least the second version of
the call to work. Is gcc wrong here or icc?
> icpc -strict-ansi -std=c++0x fpointers.cxx
> g++ -std=c++11 fpointers.cxx
fpointers.cxx: In function ‘int main()’:
fpointers.cxx:17:18: error: no matching function for call to ‘A::a(int
(&)(int, int), int)’
fpointers.cxx:17:18: note: candidate is:
fpointers.cxx:5:3: note: template static void
A::a(RES (*)(FARGS ..., SARGS ...), FARGS ...) [with RES = RES; FARGS = {FARGS
...}; SARGS = {int}]
fpointers.cxx:5:3: note: template argument deduction/substitution failed:
fpointers.cxx:17:18: note: candidate expects 1 argument, 2 provided
fpointers.cxx:18:27: error: no matching function for call to ‘A::a(int
(&)(int, int), int)’
fpointers.cxx:18:27: note: candidate is:
fpointers.cxx:5:3: note: template static void
A::a(RES (*)(FARGS ..., SARGS ...), FARGS ...) [with RES = RES; FARGS = {FARGS
...}; SARGS = {int}]
fpointers.cxx:5:3: note: template argument deduction/substitution failed:
fpointers.cxx:18:27: note: candidate expects 1 argument, 2 provided
--- fpointers.cxx ---
template
struct A
{
template static void
a(RES(*func)(FARGS...,SARGS...),FARGS...)
{
}
};
int foo(int,int)
{
return 0;
}
int main()
{
A::a(foo,0);
A::a(foo,0);
return 0;
}
[Bug c++/53490] Segmentation Fault when accessing std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53490 --- Comment #8 from Jamie Allsop 2012-05-28 09:09:30 UTC --- (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > > It was a vanilla bjam build of boost 1.49, so > > > no -std=c++11. > > > > Then technically that's not supported, since there are no guarantees of > > link-compatibility between -std=c++98 and -std=c++11 code (but I'm not > > aware of > > any specific reasons it wouldn't work for a std::set) > > > > So after sifting through the jam files to confirm there is no -std=c++11 set > in > boost for gcc4.7 I modified my bjam invocations to add cxxflags="-std=c++11" > and now the test runs without the segfault. Verifying now on the full code > base. When the tests cycle and presumably pass I'll post back. It does look > however as if the mismatch in compile flags is the culprit here. Apologies for > not being thorough in checking that earlier. All tests cycled and passed so I'd say this issue is understood now and user error.
[Bug c++/53506] Variadic templates in combination with function pointer problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53506
--- Comment #1 from Jonathan Wakely 2012-05-28
09:31:33 UTC ---
4.6 only rejects the first one:
t.cc: In function 'int main()':
t.cc:17:18: error: no matching function for call to 'A::a(int (&)(int,
int), int)'
t.cc:17:18: note: candidate is:
t.cc:5:3: note: template static void A::a(RES
(*)(FARGS ..., SARGS ...), FARGS ...) [with RES = RES, FARGS = {FARGS ...},
SARGS = {int}]
[Bug c++/53490] Segmentation Fault when accessing std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53490 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #9 from Jonathan Wakely 2012-05-28 09:32:36 UTC --- OK, thanks for confirming it.
[Bug rtl-optimization/53507] New: ia32/amd64: bsf can be used to test null memory, bsf sets zero flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53507
Bug #: 53507
Summary: ia32/amd64: bsf can be used to test null memory, bsf
sets zero flag
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr
Compiling:
int I;
void ifnull(void);
void testnull(void) {
if (I == 0)
ifnull();
}
void fct (unsigned u) {
if (u != 0)
I = __builtin_ffs(u) - 1;
}
result in for testnull():
movlI, %eax
testl%eax, %eax
je.L4
rep
ret
.L4:
jmpifnull()
It would be shorter/quicker to replace the two first lines by:
bsfl I, %eax
je ifnull()
i.e. there is no need to load the memory variable into a register with bsf/bsr.
And result for fct():
movl4(%esp), %eax
testl%eax, %eax
je.L5
bsfl%eax, %eax
movl%eax, I
.L5:
rep
ret
It would be shorter/quicker to test if the parameter u is null by the bsf
instruction:
bsfl4(%esp), %eax
cmovne%eax, I
.L5:
rep
ret
[Bug c++/53503] [4.7 Regression] [C++0x] unexpected AST of kind ltgt_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53503 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-28 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.1 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2012-05-28 10:02:44 UTC --- Seems very easy to fix.
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 --- Comment #3 from Greta Yorsh 2012-05-28 11:17:00 UTC --- Created attachment 27512 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27512 preprocessed source
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 Greta Yorsh changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Greta Yorsh 2012-05-28 11:22:46 UTC --- The problem is caused by r187631: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01222.html I am adding the author to CC and attaching the preprocessed sources.
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 Paolo Carlini changed: What|Removed |Added CC|paolo.carlini at oracle dot | |com | --- Comment #5 from Paolo Carlini 2012-05-28 11:36:29 UTC --- Thanks!
[Bug c++/53503] [4.7 Regression] [C++0x] unexpected AST of kind ltgt_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53503 --- Comment #2 from paolo at gcc dot gnu.org 2012-05-28 12:09:10 UTC --- Author: paolo Date: Mon May 28 12:09:01 2012 New Revision: 187928 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187928 Log: gcc/cp 2012-05-28 Paolo Carlini PR c++/53503 * semantics.c (potential_constant_expression_1): Handle LTGT_EXPR. libstdc++-v3 2012-05-28 Paolo Carlini PR c++/53503 * testsuite/26_numerics/headers/cmath/53503.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/53503.cc Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/libstdc++-v3/ChangeLog
[Bug c++/53503] [4.7 Regression] [C++0x] unexpected AST of kind ltgt_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53503 --- Comment #3 from paolo at gcc dot gnu.org 2012-05-28 12:11:15 UTC --- Author: paolo Date: Mon May 28 12:11:04 2012 New Revision: 187929 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187929 Log: gcc/cp 2012-05-28 Paolo Carlini PR c++/53503 * semantics.c (potential_constant_expression_1): Handle LTGT_EXPR. libstdc++-v3 2012-05-28 Paolo Carlini PR c++/53503 * testsuite/26_numerics/headers/cmath/53503.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/53503.cc Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/semantics.c branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
[Bug c++/53503] [4.7 Regression] [C++0x] unexpected AST of kind ltgt_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53503 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from paolo at gcc dot gnu.org 2012-05-28 12:11:15 UTC --- Author: paolo Date: Mon May 28 12:11:04 2012 New Revision: 187929 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187929 Log: gcc/cp 2012-05-28 Paolo Carlini PR c++/53503 * semantics.c (potential_constant_expression_1): Handle LTGT_EXPR. libstdc++-v3 2012-05-28 Paolo Carlini PR c++/53503 * testsuite/26_numerics/headers/cmath/53503.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/53503.cc Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/semantics.c branches/gcc-4_7-branch/libstdc++-v3/ChangeLog --- Comment #4 from Paolo Carlini 2012-05-28 12:11:48 UTC --- Fixed mainline and 4.7.1.
[Bug c++/53503] [4.7 Regression] [C++0x] unexpected AST of kind ltgt_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53503 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini 2012-05-28 12:11:48 UTC --- Fixed mainline and 4.7.1.
[Bug c++/53503] [4.7 Regression] [C++0x] unexpected AST of kind ltgt_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53503 --- Comment #5 from Ling Li 2012-05-28 12:37:44 UTC --- Thanks much for the super quick fix.
[Bug c++/53505] [4.7/4.8 Regression] bitfield with bool type generated broken object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53505 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-28 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.1 Summary|bitfield with bool type |[4.7/4.8 Regression] |generated broken object |bitfield with bool type |file|generated broken object ||file Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2012-05-28 12:53:19 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revision&revision=184214
[Bug c++/53505] [4.7/4.8 Regression] bitfield with bool type generated broken object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53505 --- Comment #2 from Jakub Jelinek 2012-05-28 13:25:34 UTC --- SRA creates: a$6; ... a$6_21 = MEM[(const struct A &)D.9923_20 + 6]; D.10122_23 = (int) a$6_21; which expansion doesn't handle as extract_bit_field (both MEM_REF and TARGET_MEM_REF are expanded that way), so the zero extension is performed just as QI->SImode zero extension. I'd say that SRA shouldn't be creating such MEM_REFs and instead should keep the BIT_FIELD_REFs.
[Bug c++/53505] [4.7/4.8 Regression] bitfield with bool type generated broken object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53505 --- Comment #3 from Jakub Jelinek 2012-05-28 13:39:12 UTC --- That revision added: + /* But leave bitfield accesses alone. */ + && (root->offset % BITS_PER_UNIT) == 0) Here root->offset % BITS_PER_UNIT is 0, still it is a bitfield and IMHO we should leave it alone. The question is how to differentiate bitfields at byte boundary offsets from e.g. non-bitfield _Bool where it should be user's responsibility to keep just 0 or 1 in the whole byte.
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 --- Comment #15 from William J. Schmidt 2012-05-28 13:58:30 UTC --- Author: wschmidt Date: Mon May 28 13:58:18 2012 New Revision: 187930 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187930 Log: 2012-05-28 Bill Schmidt Backport from mainline 2012-05-23 Richard Guenther PR tree-optimization/53438 * tree-sra.c (analyze_access_subtree): Correct bitfield exclusion. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-sra.c
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 William J. Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from William J. Schmidt 2012-05-28 14:02:12 UTC --- Fixed. Thanks, Richard!
[Bug c++/53505] [4.7/4.8 Regression] bitfield with bool type generated broken object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53505 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Jakub Jelinek 2012-05-28 14:09:05 UTC --- Ah, sounds like dup of PR53438. *** This bug has been marked as a duplicate of bug 53438 ***
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 Jakub Jelinek changed: What|Removed |Added CC||rockeet at gmail dot com --- Comment #17 from Jakub Jelinek 2012-05-28 14:09:05 UTC --- *** Bug 53505 has been marked as a duplicate of this bug. ***
[Bug c++/53505] [4.7/4.8 Regression] bitfield with bool type generated broken object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53505 --- Comment #5 from Jakub Jelinek 2012-05-28 14:28:06 UTC --- Author: jakub Date: Mon May 28 14:28:00 2012 New Revision: 187931 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187931 Log: PR tree-optimization/53505 * c-c++-common/torture/pr53505.c: New test. Added: trunk/gcc/testsuite/c-c++-common/torture/pr53505.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/53505] [4.7/4.8 Regression] bitfield with bool type generated broken object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53505 --- Comment #6 from Jakub Jelinek 2012-05-28 14:28:55 UTC --- Author: jakub Date: Mon May 28 14:28:42 2012 New Revision: 187932 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187932 Log: PR tree-optimization/53505 * c-c++-common/torture/pr53505.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/c-c++-common/torture/pr53505.c Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 --- Comment #18 from Jakub Jelinek 2012-05-28 14:34:30 UTC --- (In reply to comment #14) > > Anyway, would it be possible to have a testcase for the gcc testsuite too? > > I've been trying, but so far haven't been able to come up with anything other > than the enormous "reduced" testcase. Seems it may require a combination of > templates and inlining to get the bitfield access in the right form to exhibit > the bug, but I haven't figured it out yet. Ideas welcome. Ok, we now have a testcase in the testsuite from the dup PR: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187931 (and r187932 for 4.7).
[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502 --- Comment #4 from Dominique d'Humieres 2012-05-28 14:48:07 UTC --- Any idea why this does not happen without --disable-build-poststage1-with-cxx?
[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476 Greta Yorsh changed: What|Removed |Added CC||Greta.Yorsh at arm dot com --- Comment #3 from Greta Yorsh 2012-05-28 14:56:47 UTC --- Fails on arm-none-eabi too. FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) Excess errors: attr-weakref-1.c:(.text.startup+0x1c8): undefined reference to `Wv10a' attr-weakref-1.c:(.text.startup+0x1cc): undefined reference to `Wv11a' /work/builds/tst/install/bin/arm-none-eabi-gcc /work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/attr-weakref-1.c -fno-diagnostics-show-caret -O2 -DSTACK_SIZE=16384 /work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/attr-weakref-1a.c -o /work/tmp/attr-weakref-1.exe /tmp/cch8OVNm.o: In function `main': attr-weakref-1.c:(.text.startup+0x1c8): undefined reference to `Wv10a' attr-weakref-1.c:(.text.startup+0x1cc): undefined reference to `Wv11a' collect2: error: ld returned 1 exit status
[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-28 Ever Confirmed|0 |1 --- Comment #5 from Dominique d'Humieres 2012-05-28 15:17:02 UTC --- Confirmed for r187834 on x86_64-apple-darwin10.
[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 --- Comment #5 from Greta Yorsh 2012-05-28 15:28:16 UTC --- (In reply to comment #3) > It seems to me that this issue is dealt with by the patch I have proposed at > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01389.html. The discussion on > that patch is still going on. > > Could you please try that patch and reply to the discussion there to say if it > address the issue on your target? > > Thanks. This patch fixes the regressions observed for arm-none-eabi.
[Bug c++/53398] feature request: option for overloaded methods order in vtable compatibility with msc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398 --- Comment #5 from Roman Wieczorek 2012-05-28 15:50:30 UTC --- As it goes for Leaf classes (IA64 C++ ABI - Category 1: Leaf), vtables are binary defined in com document (only virtual functions, no constructor, no destructor, no overloades). And this one works with mingw. The overloads are not defined, or i have not found it. Some one has made disasembly: http://old.nabble.com/Incorrect-vtable-generation-in-MinGW--td15781052.html I found it works for some people, and i see it works for dll's i use. I hadn't mention about compatibility for Category 3(Virtual Bases Only ) or Category 4 (Complex). They are to far from any specs.
[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek 2012-05-28
15:52:39 UTC ---
I believe because for C++ that kind of typedef isn't useless when the enum is
anonymous - the typedef gives it a name.
On
int
foo ()
{
typedef enum { A = 1 } E1, E2;
typedef enum E { B = 1 } E3, E4;
return A + B;
}
C warns about E{1,2,3,4}, while C++ warns just about E{2,3,4}, but not E1.
[Bug rtl-optimization/53508] New: function.c:stack_protect_epilogue call to predict_insn_def with wrong direction of prediction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53508 Bug #: 53508 Summary: function.c:stack_protect_epilogue call to predict_insn_def with wrong direction of prediction Classification: Unclassified Product: gcc Version: 4.8.0 URL: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01361.htm l Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org The message at the URL and the (original) summary says it all; the branch is *around* a noreturn call, so the call to predict_insn_def has the prediction direction inverted. The doc wrong too; corrected with revision 187934 on trunk. The buglet is as far back as the 4.3-branch. The generated code has the call moved to a "cold" position, so the generated code does not seem to be affected in the trivial case.
[Bug c++/53500] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #7 from Paolo Carlini 2012-05-28 15:59:54 UTC --- Mainline is fine.
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494 --- Comment #8 from Paolo Carlini 2012-05-28 16:11:29 UTC --- "correctly rejects it" in general means "per the ISO C++ Standard, which we are implementing, the testcase is invalid with diagnostics required, thus the compiler is right in rejecting it", thus it doesn't have anything to do with providing a better, more informative, error message. Just to clarify. And indeed, I think Jon's analysis is correct. Maybe Daniel has something to add.
[Bug c++/53405] [4.5/4.6 Regression] Enum-dependent class template instantiations not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53405 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Paolo Carlini 2012-05-28 16:17:35 UTC --- Ok.
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #9 from Jonathan Wakely 2012-05-28
16:21:24 UTC ---
4.6 gets the error right, what you're doing is equivalent to:
struct pair
{
pair(const char*, int) { }
};
struct array
{
pair data[1];
};
array a { { "smile", 1 } };
And that isn't valid. The error 4.6 gives for that is:
t.cc:11:26: error: too many initializers for 'pair [1]'
t.cc:11:26: error: could not convert '(const char*)"smile"' from 'const char*'
to 'pair'
Which is very similar to the error 4.6 gives for your original code, except he
types in your original are more complicated because they involve templates and
typedefs.
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494
--- Comment #10 from Jonathan Wakely 2012-05-28
16:25:12 UTC ---
The code:
array a { { "smile", 1 } };
Attempts to initialize array with { { "smile", 1 } }
which attempts to initialize pair[2] with { "smile", 1 }
which fairly obviously attemptes to initialize the first pair with "smile", and
the second pair with 1, neither of which is valid.
Why do you think the error is misattributed?
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #11 from Paolo Carlini 2012-05-28 16:27:23 UTC --- I will look into the ICE. Not immediately, however.
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494 --- Comment #12 from Paolo Carlini 2012-05-28 16:32:23 UTC --- With checking disabled the error message comes out fine, thus the issue isn't really urgent.
[Bug fortran/53509] New: exp and log function give unexpected results when called with numbers as arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53509 Bug #: 53509 Summary: exp and log function give unexpected results when called with numbers as arguments Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: f.ba...@gmail.com Created attachment 27513 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27513 test script for testing log and exp function I noticed that the exp and log function in gfortran 4.7.0 and 4.5.3 on OSX Lion/macports give unexpected results. When I call exp(1.0) I get 2.76.. and when I call log(2.71...) I get 1.34... $ gfortran-mp-4.7 ./test.f90 && ./a.out 2.76998615 1.34896958 I tried debugging the program, when in the debugger calling log(2.71..) results in the correct value. Another way to get the correct answer is to store the 2.71 in a variable and calling log on that. I also tried with other real types and they all give different but incorrect answers. Please find attached a test program that reproduces the error on OSX Lion. Cheers, Fedor See also: http://trac.macports.org/ticket/34535 http://stackoverflow.com/questions/10673701/can-i-call-the-fortran-log-function-with-a-number
[Bug c++/53500] [4.7 Regression] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #8 from Andrew Pinski 2012-05-28 16:53:49 UTC --- (In reply to comment #5) > Though with -ftime-report I get an internal error: > /usr/include/c++/4.7/bits/alloc_traits.h:48:11: internal compiler error: in > timevar_start, at timevar.c:344 Note while trying to reduce the ICE in timevar_start, I ran into the case where memory usage was way high.
[Bug c++/53500] [4.7 Regression] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #9 from Paolo Carlini 2012-05-28 17:09:21 UTC --- Andrew, please try to provide details about these memory issues, because first blush I didn't notice anything special memory-wise. Maybe open a separate PR.
[Bug c++/53510] New: OOM while compile some code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53510 Bug #: 53510 Summary: OOM while compile some code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org While reducing PR 53500 for a different ICE on the trunk. I ran into a case where it would cause all the memory to be eaten up. Compile with -std=c++11. Sorry it is a big testcase but it is hard to reduce as I have not set the limits yet,
[Bug c++/53510] OOM while compile some code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53510 --- Comment #1 from Andrew Pinski 2012-05-28 17:16:03 UTC --- Created attachment 27514 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27514 Testcase
[Bug c++/53500] [4.7 Regression] internal compiler error in joust()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #10 from Andrew Pinski 2012-05-28 17:16:49 UTC --- (In reply to comment #9) > Andrew, please try to provide details about these memory issues, because first > blush I didn't notice anything special memory-wise. Maybe open a separate PR. I created PR 53510.
[Bug middle-end/53510] [4.8 Regression] OOM while compile some code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53510 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, memory-hog Component|c++ |middle-end Target Milestone|--- |4.8.0 Summary|OOM while compile some code |[4.8 Regression] OOM while ||compile some code --- Comment #2 from Andrew Pinski 2012-05-28 17:21:05 UTC --- #1 0x00f7b7ea in read_line (file=0x18d9b50) at /home/pinskia/src/local/gcc/gcc/input.c:111 111 memcpy (ptr, string, pos); (gdb) p pos $2 = 96889 (gdb) p/x pos $3 = 0x17a79 So this is the error message which is causing the huge memory usage.
[Bug middle-end/53510] [4.8 Regression] OOM while compile some code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53510 --- Comment #3 from Paolo Carlini 2012-05-28 17:28:51 UTC --- Stupid guess: does it happen with -fno-diagnostics-show-caret too?
[Bug middle-end/53510] [4.8 Regression] OOM while compile some code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53510 --- Comment #4 from Andrew Pinski 2012-05-28 17:29:46 UTC --- (In reply to comment #3) > Stupid guess: does it happen with -fno-diagnostics-show-caret too? It does not happen with -fno-diagnostics-show-caret .
[Bug middle-end/53510] [4.8 Regression] OOM while compile some code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53510 Paolo Carlini changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Paolo Carlini 2012-05-28 17:38:11 UTC --- Let's ask Manuel to have a look.
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137 --- Comment #19 from paolo at gcc dot gnu.org 2012-05-28 17:42:34 UTC --- Author: paolo Date: Mon May 28 17:42:29 2012 New Revision: 187937 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187937 Log: /c-family 2012-05-28 Paolo Carlini PR c++/25137 * c-opts.c (c_common_handle_option): For C++ -Wall doesn't enable -Wmissing_braces. 2012-05-28 Paolo Carlini PR c++/25137 * doc/invoke.texi: Document -Wmissing-braces not enabled by -Wall for C++. /testsuite 2012-05-28 Paolo Carlini PR c++/25137 * g++.dg/warn/Wbraces3.C: New. * g++.dg/warn/Wbraces4.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Wbraces3.C trunk/gcc/testsuite/g++.dg/warn/Wbraces4.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #19 from paolo at gcc dot gnu.org 2012-05-28 17:42:34 UTC --- Author: paolo Date: Mon May 28 17:42:29 2012 New Revision: 187937 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187937 Log: /c-family 2012-05-28 Paolo Carlini PR c++/25137 * c-opts.c (c_common_handle_option): For C++ -Wall doesn't enable -Wmissing_braces. 2012-05-28 Paolo Carlini PR c++/25137 * doc/invoke.texi: Document -Wmissing-braces not enabled by -Wall for C++. /testsuite 2012-05-28 Paolo Carlini PR c++/25137 * g++.dg/warn/Wbraces3.C: New. * g++.dg/warn/Wbraces4.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Wbraces3.C trunk/gcc/testsuite/g++.dg/warn/Wbraces4.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog --- Comment #20 from Paolo Carlini 2012-05-28 17:44:52 UTC --- Done.
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #20 from Paolo Carlini 2012-05-28 17:44:52 UTC --- Done.
[Bug fortran/53509] exp and log function give unexpected results when called with numbers as arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53509 Dominique d'Humieres changed: What|Removed |Added CC||howarth at bromo dot ||med.uc.edu --- Comment #1 from Dominique d'Humieres 2012-05-28 18:35:15 UTC --- It works for me on 10.6 (snow leopard). It looks like as a problem with your GMP/MPFR install. Could you have a look at the GMP bugs to see if there is nothing related to 10.7 (lion)? CCed Jack Howarth who will know better.
[Bug target/53268] [4.8 Regression] [SH] libstdc++-dg/conformance.exp failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53268 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Oleg Endo 2012-05-28 20:08:50 UTC --- Problem seems to have disappeared when looking at the test results of rev 187914.
[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53494 --- Comment #13 from mako 2012-05-28 21:04:25 UTC --- Am I interpreting correctly that double braces are /required/ for std::array init lists but only when the subtype has has a multivariable initializer too? ..
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 Paolo Carlini changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #13 from Paolo Carlini 2012-05-28 21:42:02 UTC --- Jon, I'd like to resolve this PR: personally I totally agree with Manuel that adding a few words of clarification in the docs, in particular explaining that "prototype" is a C concept, is a good idea, but I'm not 100% sure about the English. Could you double check the tentative patch here in the audit trail and possibly post it to the mailing list?
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | --- Comment #14 from Jonathan Wakely 2012-05-28 21:47:53 UTC --- Sure
[Bug target/53511] New: SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 Bug #: 53511 Summary: SH Target: Add support for fma patterns Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* As Kaz already mentioned in PR 51340 comment #3 it should be OK to use SH's FMAC insn to implement the new fma patterns.
[Bug target/51340] SH Target: Make -mfused-madd enabled by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #5 from Oleg Endo 2012-05-28 22:11:31 UTC --- (In reply to comment #4) > > > > It seems that we can use the fma pattern, though it would be an another > > issue. > > Maybe when trunk is back to stage 1. Created PR 53511 for this.
[Bug tree-optimization/53438] [4.7/4.8 Regression] Bitfield store replaced with full-byte store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53438 --- Comment #19 from William J. Schmidt 2012-05-28 22:31:40 UTC --- Excellent. Thanks, Jakub.
[Bug inline-asm/52813] %rsp in clobber list is silently ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813 Ralph Corderoy changed: What|Removed |Added CC||ralph-gccbugzilla at ||inputplus dot co.uk --- Comment #5 from Ralph Corderoy 2012-05-28 23:06:51 UTC --- The examples clearly show the problem and it bites me here. Please change the status to confirmed.
[Bug target/53512] New: SH Target: Allow fsca and fsrra for non-SH4A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53512 Bug #: 53512 Summary: SH Target: Allow fsca and fsrra for non-SH4A Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org CC: kkoj...@gcc.gnu.org Target: sh4*-*-* Currently the fsca and fsrra insns are available only for SH4A. However, there are some SH4 variants around (e.g. SH7091) that also support those insns. My idea was to add the following options: -mfsca, -mno-fsca -mfsrra, -mno-fsrra ...to be able to manually enable/disable the respective insns. On SH4A -mfsca and -mfsrra would be enabled by default when setting -funsafe-math-optimizations, which would preserve the current behavior. Any objections?
[Bug fortran/53509] exp and log function give unexpected results when called with numbers as arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53509 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||INVALID --- Comment #2 from kargl at gcc dot gnu.org 2012-05-28 23:45:18 UTC --- Not a gfortran problem. Please, test your MPFR/GMP.
[Bug target/53513] New: SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 Bug #: 53513 Summary: SH Target: Add support for fschg and fpchg insns Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org CC: kkoj...@gcc.gnu.org Target: sh*-*-* Currently FPU mode switches are done by always loading values from the global __fpscr_values array into FPSCR. On SH4A the fpchg insn should be used to do SFmode / DFmode switches. On non-SH4A it would probably be better to toggle the PR bit by other means in order to preserve the other FPSCR bits. One example use case where the FPSCR.FR bit needs to be preserved is matrix multiplication, where user code could swap the register bank using the frchg insn. Even if the user code updated the global __fpscr_values to reflect the FPSCR.FR change, it would break when there are multiple threads that want to use different FPSCR.FR/PR/SZ settings, as there is only one global __fpscr_values array. To provide some backwards compatibility with existing binaries the global __fpscr_values should be kept around. Old code would then still be able to reference them and new code would not touch them except when __set_fpscr is used. Since the FPSCR.PR/SZ settings at function entry and function exit are defined by the selected ABI there should be no interoperability problems.
[Bug c++/53514] New: Make -Wpadded a meta-option for -Wpadded-in-middle and -Wpadded-at-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53514 Bug #: 53514 Summary: Make -Wpadded a meta-option for -Wpadded-in-middle and -Wpadded-at-end Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@doublewise.net "Warn if padding is included in a structure, either to align an element of the structure or to align the whole structure. Sometimes when this happens it is possible to rearrange the fields of the structure to reduce the padding and so make the structure smaller." I would find this warning much more useful if it were two different warnings, -Wpadded-in-middle and -Wpadded-at-end. -Wpadded-at-end would only warn if padding was added to the end of the structure. This could theoretically be useful to let you know about structures that you can add data to "for free" in terms of size. What I'm more interested in, however, is -Wpadded-in-middle. This is what suggests that perhaps you could reduce the size of the structure by changing the order of the elements. This suggestion would make -Wpadded become equivalent to -Wpadded-in-middle -Wpadded-at-end.
[Bug c++/16166] -Weffc++ finer granularity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16166 --- Comment #4 from David Stone 2012-05-29 02:13:53 UTC --- I would recommend against naming each warning -Weffc++[n], but rather, give a more descriptive name. My suggestion is to create a few warnings, so that -Weffc++ would map to the following set of warnings (with their current description for reference and my suggested name): Effective C++: * Item 11: Define a copy constructor and an assignment operator for classes with dynamically allocated memory. -Wcopy-resource-class * Item 12: Prefer initialization to assignment in constructors. -Wassignment-in-constructor * Item 14: Make destructors virtual in base classes. Already covered by -Wnon-virtual-dtor * Item 15: Have operator= return a reference to *this. -Wassignment-operator-return-value * Item 23: Don't try to return a reference when you must return an object. -Wsuspicious-reference-return More Effective C++: * Item 6: Distinguish between prefix and postfix forms of increment and decrement operators. -Wprefix-postfix * Item 7: Never overload &&, ||, or ,. Perhaps this should be split into two warnings of its own: -Woverloaded-short-circuit -Woverloaded-comma In summary, you could simulate exactly the behavior of -Weffc++ by turning on each of these warnings individually, or you could turn on -Weffc++ and selectively turn off a few warnings that you don't want.
[Bug target/53512] SH Target: Allow fsca and fsrra for non-SH4A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53512 --- Comment #1 from Kazumoto Kojima 2012-05-29 02:39:28 UTC --- (In reply to comment #0) Sounds good.
