[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2011-03-02 09:59:52 UTC --- (In reply to comment #6) 1- Please make sure the code is minimally documented (are the comments in longlong.h enough?) Ok, I wasn't sure it was worth it if the code was unlikely to ever make it. 2- I see stuff like __builtin_clzll(__d) on __d a uintmax_t, I'm not sure it's always ok, on any 32-bit and 64-bit target. Do you have a better alternative in mind? Should I reimplement it using templates? It shouldn't be too hard, but I would check on the gcc ML first. More generally - I'm asking to Marc the mathematician here, not Mark the libstdc++ contributor - do we have a clear characterization of which specific overflows can be avoided? All of those where both the input and the output are legal std::ratio. Are we *really* sure the boost::rational implementation is equivalent to GCC and weaker than what you are proposing: the first time I looked into it I remember seeing a normalization happening earlier toward the end, per the last two lines of that comment: // Which proves that instead of normalizing the result, it is better to // divide num and den by gcd((a*d1 + c*b1), g) Boost isn't exactly equivalent to gcc. Making a mix of their ratio and rational (and possibly extrapolating a bit), they avoid some overflows of the numerator by factoring out the gcd of the numerators, and they avoid all overflows of the denominator by reducing the numerator with the gcd of the denominators so they can compute directly the right denominator. They still fail on 2 types of numerator overflow, either when the numerator is too large before simplification with the gcd, or when the 2 products are large but their sum is small. The example at the end of the attached file shows the second case.
[Bug debug/47946] Dwarf uses 64-bits to refer to a structure offset unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946 --- Comment #4 from hariharans at picochip dot com 2011-03-02 10:11:19 UTC --- Hello Jakub, I tested the patch and it fixes the problem. Thanks for looking into this. Cheers Hari
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 10:12:10 UTC --- Created attachment 23511 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23511 gcc46-pr47283.patch Untested fix.
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 10:16:12 UTC --- (In reply to comment #11) The original LTO proposal included assembler changes to allow multiple local symbols with the same name in the output. You could resurrect that, though allowing references to the multiple local symbols from asm imposes extra requirements on what the assembler interface must look like (directives to say which versions are being referred to by asms in a particular part of the input?). Hmm, doing that would imply need to refer to the static in some global way anyway. When it is referenced from regular code and two static variables from two different units might end up in the same instruction. Not too hard to implement I guess. I think we settled on the idea to delay mangling of local symbols until after we composed ltrans units (so we can also compose units in a way to avoid the need to mangle local symbols with a used attribute). It shouldn't be too difficult to implement but sofar nobody has done the work (and it will likely be easier with a global symbol table which we hopefully will get for 4.7). I do not like much the idea of improsing new artificial limits on the partitioning. Once we start doing fancy stuff at the ltrans time, we will have hard time partitioning the important stuff into single partition. Those extra requirements would just make it harder I probably like most the variant with extending the asm syntax for inputs/outputs at toplevel statements (like Sun compiler seems to do already) and declaring direct references to statics not LTO compatible. It seems much cleaner to me to declare that variable is used at the place it is actually used rather than annotating the declaration. Also it avoid the need for asm statement to be aware of target mangling rules (i.e. prefixing with _) Well we can still simply not mangle a static if it is marked used and all conflicting decls are not used and also static. Likewise not mangle a static if there are no conflicts. I consider this a QOI issue also with regard to debugging. This would be just delaying the mangling until WPA stage (symbol merging), not ltrans stage. It wouldn't fix the case with two conflicting used vars but it probably would catch most real-world cases. Richard. Honza
[Bug target/47948] ICE: in emit_move_insn, at expr.c:3355 with -mno-sse2 on very simple code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47948 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.02 10:20:59 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 10:20:59 UTC --- I think this is expected. But we should sorry () instead when you disable HW features required for the ABI and you make use of that part of the ABI. I also think we have a dup for this PR.
[Bug target/47949] Missed optimization for -Os using xchg instead of mov.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47949 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target|x86 / amd64 |x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.02 10:23:29 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 10:23:29 UTC --- Interesting idea.
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.0 |---
[Bug target/47948] ICE: in emit_move_insn, at expr.c:3355 with -mno-sse2 on very simple code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47948 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 10:47:12 UTC --- We have PR46716, but that's wrong-code with m64 -mno-sse2, not ICE. Other than that, it is basically a dup, yeah.
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-03-02 10:51:51 UTC --- (In reply to comment #7) (In reply to comment #6) I think the intention is to warn, at least for a == (void *)0, since the address of a cannot be zero or null. So I would say that this is a regression. But this is valid in C, and in practice, such a test can occur in macro expansions: a macro can check whether some pointer is null before doing something with it. There shouldn't be a warning in such a case. Every warning warns about something valid in C, otherwise it would be an error not a warning.
[Bug target/47949] Missed optimization for -Os using xchg instead of mov.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47949 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 10:53:28 UTC --- I'm afraid it will upset Linux kernel people and others who are using -Os for performance reasons to decrease its cache footprint, but if their code slows down too much, they won't be happy.
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-02 10:59:06 UTC --- Hi, 1- Please make sure the code is minimally documented (are the comments in longlong.h enough?) Ok, I wasn't sure it was worth it if the code was unlikely to ever make it. Right. Mine was sort of a general comment: the comments in ratio_less are also rather terse ;) 2- I see stuff like __builtin_clzll(__d) on __d a uintmax_t, I'm not sure it's always ok, on any 32-bit and 64-bit target. Do you have a better alternative in mind? Should I reimplement it using templates? It shouldn't be too hard, but I would check on the gcc ML first. I don't think you should really handcode something, just pick the right __builtin_* depending on the actual type of uintmax_t (after all it's just a typedef for one of the builtin types). Thus, if we aim for something really general here, use just a bit of templates to pick the best match among the various available __builtin_*, via make_signed on uintmax_t and then three special cases for int, long, long long. Granted, probably on widespread 32-bit and 64-bit machines, long long it's indeed a safe bet. More generally - I'm asking to Marc the mathematician here, not Mark the libstdc++ contributor - do we have a clear characterization of which specific overflows can be avoided? All of those where both the input and the output are legal std::ratio. Right. I was just curious to understand whether we can somehow characterize the inputs which are going anyway to overflow either numerator or denominator. I'm trying to figure out what the brute force approach boils down to: is it just matter of attempting simplification at each arithmetic operation, or we have to do also something else, of a more global nature in order to achieve the goal? Whatever we do, I think eventually we need something in a comment before the code anyway... Boost isn't exactly equivalent to gcc. Making a mix of their ratio and rational (and possibly extrapolating a bit), they avoid some overflows of the numerator by factoring out the gcd of the numerators, and they avoid all overflows of the denominator by reducing the numerator with the gcd of the denominators so they can compute directly the right denominator. They still fail on 2 types of numerator overflow, either when the numerator is too large before simplification with the gcd, or when the 2 products are large but their sum is small. The example at the end of the attached file shows the second case. Understood. Since 4.6.0 is approaching, do you think it would make sense for this release series to modify only a bit the GCC code, to the point that we are as good or even slightly better, if possible, than Boost, without requiring too much new code? I fear regressions, as you of course can easily understand. Ideally, we should add, mano a mano, testcases for each subclass of inputs which we are able to process without overflowing.
[Bug c++/47950] New: [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950
Summary: [C++0x] Internal compiler error: non-dependent
declaration as condition causes tsubst_copy_and_build
assertion failure.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk
The following program demonstrates an assertion failure in
tsubst_copy_and_build when compiling in C++0x mode.
It may be related to bug 47808 which fails the same assertion via a different
route (looks like it's using a non-dependent constexpr function to determine
the size of an array).
This issue demonstrated here appears to manifest only when a non-dependent
declaration is used as a condition within a selection statement inside a
template -- and only then if the standard initializer syntax is used with the
rhs being a constructor or function call.
This was done using 4.6.0 20110302 built this morning. Failures only occur in
C++0x mode.
This is a recent regression -- a build from a few days ago did not exhibit this
issue.
template typename T struct empty
{
// allow success case to build (not relevant to bug)
operator bool() { return true; }
};
template typename T struct from_int
{
from_int(int) {}
// allow success case to build (not relevant to bug)
operator bool() { return true; }
};
template typename T
from_intT via_function(T v)
{
return from_intT(v);
}
template typename T
void f()
{
// * this section compiles ***
// these plain initializers work fine
from_intint a = 7;
from_intint b = from_intint(7);
emptyintc = emptyint();
from_intT ta = 7;
from_intT tb = from_intT(7);
emptyTtc = emptyT();
// these dependent condition decls work fine
if (emptyT x = emptyT())
;
if (from_intT x = 7)
;
if (from_intT x = from_intT(7))
;
if (from_intT x = via_function(T()))
;
// this non-dependent condition decl using conversion works fine
if (from_intint x = 7)
;
// these non-dependent condition decls using conversion or braced-
// initialization work fine (in c++0x mode only course)
#if __GXX_EXPERIMENTAL_CXX0X__
if (emptyint x {})
;
if (from_intint x {7})
;
#endif
// ** this section fails in C++0x ***
// the following non-dependent condition decls cause an assertion
// failure in
//
// tsubst_copy_and_build, at cp/pt.c:13370
//
// in C++0x mode
//
if (emptyint x = emptyint())
;
if (from_intint x = from_intint(7))
;
if (from_intint x = via_function(7))
;
}
int main()
{
fint();
}
[Bug target/47951] New: [4.6 Regression] web.c:union_match_dups segmentation fault for bfin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47951 Summary: [4.6 Regression] web.c:union_match_dups segmentation fault for bfin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: stuart.hender...@analog.com bfin-uclinux fails to build libgfortran due to a seg fault in union_match_dups in web.c Looks like this is the blackfin version of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742 which was caused by: http://gcc.gnu.org/viewcvs?view=revisionrevision=158187 i'm not sure what the guilty pattern is though. /home/shender/gnu/toolchain/gcc_build-4.6/./gcc/xgcc -B/home/shender/gnu/toolchain/gcc_build-4.6/./gcc/ -B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/bin/ -B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/lib/ -isystem /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/include -isystem /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include -DHAVE_CONFIG_H -I. -I/home/shender/gnu/toolchain/gcc-4.6/libgfortran -iquote/home/shender/gnu/toolchain/gcc-4.6/libgfortran/io -I/home/shender/gnu/toolchain/gcc-4.6/libgfortran/../gcc -I/home/shender/gnu/toolchain/gcc-4.6/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -ftree-vectorize -funroll-loops -g -O1 -c /home/shender/gnu/toolchain/gcc-4.6/libgfortran/generated/matmul_i1.c -o matmul_i1.o /home/shender/gnu/toolchain/gcc-4.6/libgfortran/generated/matmul_i1.c: In function ‘matmul_i1’: /home/shender/gnu/toolchain/gcc-4.6/libgfortran/generated/matmul_i1.c:374:1: internal compiler error: Segmentation fault
[Bug target/47948] ICE: in emit_move_insn, at expr.c:3355 with -mno-sse2 on very simple code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47948 --- Comment #3 from Zdenek Sojka zsojka at seznam dot cz 2011-03-02 11:42:47 UTC --- Thank you for replies. I am sorry for a wrong report, I thought this switch combination is valid and expected to work. There are tests in the testsuite that use -msse -mno-sse2. I didn't expect that vector of shorts is SSE2 specific (that is, doesn't work with just SSE).
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #9 from Marc Glisse marc.glisse at normalesup dot org 2011-03-02 11:50:41 UTC --- (In reply to comment #8) Right. Mine was sort of a general comment: the comments in ratio_less are also rather terse ;) I'll try to expand a bit on them. I don't think you should really handcode something, just pick the right __builtin_* depending on the actual type of uintmax_t (after all it's just a typedef for one of the builtin types). Thus, if we aim for something really general here, use just a bit of templates to pick the best match among the various available __builtin_*, via make_signed on uintmax_t and then three special cases for int, long, long long. Granted, probably on widespread 32-bit and 64-bit machines, long long it's indeed a safe bet. If intmax_t is guaranteed to be one of int/long/long long, then it seems that it has to be equivalent to long long. I was more afraid that it might be a bigger type than long long. (by the way, __builtin_clz takes an unsigned argument) Understood. Since 4.6.0 is approaching, do you think it would make sense for this release series to modify only a bit the GCC code, to the point that we are as good or even slightly better, if possible, than Boost, without requiring too much new code? I fear regressions, as you of course can easily understand. Ideally, we should add, mano a mano, testcases for each subclass of inputs which we are able to process without overflowing. I think there is nothing wrong with the implementation of ratio_add currently in libstdc++ (shipping it as it is seems fine), but we could indeed easily avoid all unnecessary denominator overflows (attachment in a minute). The factorization of the gcd of numerators is a heuristic that sometimes helps but doesn't really close a category of overflow, so I am more reluctant to add it, but it is really easy if you think it should be done.
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #10 from Marc Glisse marc.glisse at normalesup dot org 2011-03-02 11:53:58 UTC --- Created attachment 23512 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23512 avoid denominator overflows (untested)
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-02 11:59:34 UTC --- Thanks for the attachment. Do you have a small testcase for it? I would test here, commit, and then we can proceed with more serious changes for post 4.6...
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-02 12:07:13 UTC --- About int/long/long long I see what you mean, but we should double check that __builtin_clzll is unconditionally available and the same as __builtin_clz if intmax_t == int (etc): at the moment I'm not 100% sure.
[Bug target/47951] [4.6 Regression] web.c:union_match_dups segmentation fault for bfin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47951 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.6.0
[Bug c++/47952] New: [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 Summary: [trans-mem] undefined reference to transaction clone Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org, javier.ar...@bsc.es Created attachment 23513 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23513 attached almost reduced testcase. An undefined reference to a transaction clone appears at link time. $ g++ -save-temps -O0 -c -Wall -fgnu-tm testcase.i testcase.o:(.tm_clone_table+0x8): undefined reference to `transaction clone for std::_List_iteratorGame::BuildProject::_List_iterator(std::_List_node_base*)' The testcase is not completely reduced... I will post it a better one soon. Considered it as high priority since it happens in the Velox stack. Thanks :) Patrick.
[Bug debug/47858] [4.5/4.6 Regression] IPA-SRA decreases quality of debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47858 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c/47939] Missing DW_TAG_typedef for qualified types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 13:12:16 UTC --- I have a patch.
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-02 13:22:14 UTC --- (In reply to comment #6) (In reply to comment #4) The regression appeared between revisions 158105 and 159105. In the above revision range r158253 looks by far the most likely candidate for this regression. Revision 158253 is indeed the cause of this pr: the tests compile and run with r158252, but yields ICEs with 158253.
[Bug rtl-optimization/47925] delete_trivially_dead_insns mishandles volatile mems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47925 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-02 13:25:13 UTC --- Author: rsandifo Date: Wed Mar 2 13:25:10 2011 New Revision: 170613 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170613 Log: gcc/ PR rtl-optimization/47925 * cse.c (count_reg_usage): Don't ignore the SET_DEST of instructions with side effects. Remove the more-specific check for volatile asms. gcc/testsuite/ PR rtl-optimization/47925 * gcc.c-torture/execute/pr47925.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr47925.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog
[Bug c/47953] New: Code generation depends on function prototype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47953
Summary: Code generation depends on function prototype
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: js...@gcc.gnu.org
On Linux/x86-64, I got
[hjl@gnu-6 ilp32-27]$ cat x.c
void (*foo[6][6]) (int);
void bar (hdR)
int hdR;
{ }
void xxx ()
{
unsigned int i, j;
for (i = 0; i 6; ++i)
for (j = 0; j 6; ++j)
foo [i][j] = bar;
}
[hjl@gnu-6 ilp32-27]$ cat y.c
void (*foo[6][6]) (int);
void bar (int hdR)
{ }
void xxx ()
{
unsigned int i, j;
for (i = 0; i 6; ++i)
for (j = 0; j 6; ++j)
foo [i][j] = bar;
}
[hjl@gnu-6 ilp32-27]$ make x.s y.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -O3 x.c
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o y.s -O3 y.c
[hjl@gnu-6 ilp32-27]$ cat x.s y.s
.filex.c
.text
.p2align 4,,15
.globlbar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE0:
.sizebar, .-bar
.p2align 4,,15
.globlxxx
.typexxx, @function
xxx:
.LFB1:
.cfi_startproc
movq.LC0(%rip), %xmm1
punpcklqdq%xmm1, %xmm1
movdqa%xmm1, foo(%rip)
movdqa%xmm1, foo+16(%rip)
movdqa%xmm1, foo+32(%rip)
movdqa%xmm1, foo+48(%rip)
movdqa%xmm1, foo+64(%rip)
movdqa%xmm1, foo+80(%rip)
movdqa%xmm1, foo+96(%rip)
movdqa%xmm1, foo+112(%rip)
movdqa%xmm1, foo+128(%rip)
movdqa%xmm1, foo+144(%rip)
movdqa%xmm1, foo+160(%rip)
movdqa%xmm1, foo+176(%rip)
movdqa%xmm1, foo+192(%rip)
movdqa%xmm1, foo+208(%rip)
movdqa%xmm1, foo+224(%rip)
movdqa%xmm1, foo+240(%rip)
movdqa%xmm1, foo+256(%rip)
movdqa%xmm1, foo+272(%rip)
ret
.cfi_endproc
.LFE1:
.sizexxx, .-xxx
.commfoo,288,32
.section.rodata.cst8,aM,@progbits,8
.align 8
.LC0:
.quadbar
.identGCC: (GNU) 4.6.0 20110224 (experimental)
.section.note.GNU-stack,,@progbits
.filey.c
.text
.p2align 4,,15
.globlbar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE0:
.sizebar, .-bar
.p2align 4,,15
.globlxxx
.typexxx, @function
xxx:
.LFB1:
.cfi_startproc
movq$bar, foo(%rip)
movq$bar, foo+8(%rip)
movq$bar, foo+16(%rip)
movq$bar, foo+24(%rip)
movq$bar, foo+32(%rip)
movq$bar, foo+40(%rip)
movq$bar, foo+48(%rip)
movq$bar, foo+56(%rip)
movq$bar, foo+64(%rip)
movq$bar, foo+72(%rip)
movq$bar, foo+80(%rip)
movq$bar, foo+88(%rip)
movq$bar, foo+96(%rip)
movq$bar, foo+104(%rip)
movq$bar, foo+112(%rip)
movq$bar, foo+120(%rip)
movq$bar, foo+128(%rip)
movq$bar, foo+136(%rip)
movq$bar, foo+144(%rip)
movq$bar, foo+152(%rip)
movq$bar, foo+160(%rip)
movq$bar, foo+168(%rip)
movq$bar, foo+176(%rip)
movq$bar, foo+184(%rip)
movq$bar, foo+192(%rip)
movq$bar, foo+200(%rip)
movq$bar, foo+208(%rip)
movq$bar, foo+216(%rip)
movq$bar, foo+224(%rip)
movq$bar, foo+232(%rip)
movq$bar, foo+240(%rip)
movq$bar, foo+248(%rip)
movq$bar, foo+256(%rip)
movq$bar, foo+264(%rip)
movq$bar, foo+272(%rip)
movq$bar, foo+280(%rip)
ret
.cfi_endproc
.LFE1:
.sizexxx, .-xxx
.commfoo,288,32
.identGCC: (GNU) 4.6.0 20110224 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 ilp32-27]$
The only difference in input is:
void bar (hdR)
int hdR;
{ }
vs.
void bar (int hdR)
{ }
I am expecting the same assembly code.
[Bug testsuite/47954] New: gcc.dg/tree-ssa/ssa-ccp-33.c fails with link error on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47954 Summary: gcc.dg/tree-ssa/ssa-ccp-33.c fails with link error on m68k-linux Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se On m68k-linux the gcc.dg/tree-ssa/ssa-ccp-33.c test case fails: fgrep ssa-ccp-33 gcc/testsuite/gcc/gcc.log Executing on host: /mnt/scratch/objdir46/gcc/xgcc -B/mnt/scratch/objdir46/gcc/ /mnt/scratch/gcc-4.6-20110226/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-33.c -O -lm -o ssa-ccp-33.exe(timeout = 300) ssa-ccp-33.c:(.text+0x2a): undefined reference to `link_error' ssa-ccp-33.c:(.text+0x2a): undefined reference to `link_error' FAIL: gcc.dg/tree-ssa/ssa-ccp-33.c (test for excess errors) ssa-ccp-33.c:(.text+0x2a): undefined reference to `link_error' The test case uses sizeof(int)-1 to generate a mask of bits that must be zero in an int *p, and calls link_error() if this isn't the case, the intention being that the compiler completely eliminates the call. However, on m68k-linux __alignof__(int) == 2 while sizeof(int) == 4, so the compiler fails to optimize the check away, leading to the link error. The test case should use __alignof__ not sizeof.
[Bug testsuite/47954] gcc.dg/tree-ssa/ssa-ccp-33.c fails with link error on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47954 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.02 13:40:10 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 13:40:10 UTC --- A patch changing it that way is pre-approved.
[Bug target/47955] New: gcc.dg/stack-usage-1.c fails on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47955 Summary: gcc.dg/stack-usage-1.c fails on m68k-linux Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se The gcc.dg/stack-usage-1.c test case fails on m68k-linux: fgrep stack-usage- gcc/testsuite/gcc/gcc.log Executing on host: /mnt/scratch/objdir46/gcc/xgcc -B/mnt/scratch/objdir46/gcc/ /mnt/scratch/gcc-4.6-20110226/gcc/testsuite/gcc.dg/stack-usage-1.c -fstack-usage -S -o stack-usage-1.s(timeout = 300) /mnt/scratch/gcc-4.6-20110226/gcc/testsuite/gcc.dg/stack-usage-1.c: In function 'foo': /mnt/scratch/gcc-4.6-20110226/gcc/testsuite/gcc.dg/stack-usage-1.c:53:1: warning: -fstack-usage not supported for this target [enabled by default] /mnt/scratch/gcc-4.6-20110226/gcc/testsuite/gcc.dg/stack-usage-1.c: In function 'foo': /mnt/scratch/gcc-4.6-20110226/gcc/testsuite/gcc.dg/stack-usage-1.c:53:1: warning: -fstack-usage not supported for this target [enabled by default] FAIL: gcc.dg/stack-usage-1.c (test for excess errors) /mnt/scratch/gcc-4.6-20110226/gcc/testsuite/gcc.dg/stack-usage-1.c:53:1: warning: -fstack-usage not supported for this target [enabled by default] FAIL: gcc.dg/stack-usage-1.c scan-file foo\t(256|264)\tstatic The issue is that the m68k backend doesn't set stack usage data, which generic parts detect and report as -fstack-usage not supported. m68k_expand_prologue() should update current_function_static_stack_size if flag_stack_usage is set.
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
--- Comment #9 from Thomas Henlich thenlich at users dot sourceforge.net
2011-03-02 13:49:15 UTC ---
It seems that MinGW has its own implementation of snprintf called
__mingw_snprintf which can be activated by defining __USE_MINGW_ANSI_STDIO
__mingw_snprintf has the desired behaviour:
#include stdio.h
main() {
double d = .14285714285714286;
char str[200];
__mingw_snprintf(str, sizeof(str), MinGW: %35.32f, d);
puts(str);
_snprintf(str, sizeof(str), MSVCRT: %35.32f, d);
puts(str);
return;
}
MinGW: 0.14285714285714284921269268124888
MSVCRT: 0.14285714285714285000
Is there a way to use this in Fortran too?
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4 --- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 13:51:36 UTC --- This isn't a bootstrap failure any longer from what I can understand, any Fortran isn't release critical.
[Bug c++/47956] New: gcc accepts static data member declaration with initializer for non-const literal type if type-specifier is auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47956
Summary: gcc accepts static data member declaration with
initializer for non-const literal type if
type-specifier is auto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
gcc accepts static data member declaration with brace-or-equal-initializer for
non-const literal type, when the type-specifier is the plain auto specifier.
struct X
{
static auto member = 0 ;
} ;
The type of X::member is deduced to be int.
But static data member declaration is allowed to have
brace-or-equal-initializer if the type is const literal type.
So this code must be ill-formed.
[Bug tree-optimization/47615] [4.5 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 13:56:48 UTC --- Author: rguenth Date: Wed Mar 2 13:56:41 2011 New Revision: 170614 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170614 Log: 2011-03-02 Richard Guenther rguent...@suse.de Backport from mainline 2011-02-07 Richard Guenther rguent...@suse.de PR tree-optimization/47615 * tree-ssa-sccvn.h (run_scc_vn): Take a vn-walk mode argument. * tree-ssa-sccvn.c (default_vn_walk_kind): New global. (run_scc_vn): Initialize it. (visit_reference_op_load): Use it. * tree-ssa-pre.c (execute_pre): Use VN_WALK if in PRE. * g++.dg/opt/pr47615.C: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/opt/pr47615.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-pre.c branches/gcc-4_5-branch/gcc/tree-ssa-sccvn.c branches/gcc-4_5-branch/gcc/tree-ssa-sccvn.h
[Bug tree-optimization/47615] [4.5 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 13:57:17 UTC --- Fixed.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #28 from Jeffrey A. Law law at redhat dot com 2011-03-02 13:58:19 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/11 06:51, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4 --- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 13:51:36 UTC --- This isn't a bootstrap failure any longer from what I can understand, any Fortran isn't release critical. And the PA isn't (or shouldn't be) a primary platform :-) jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNbkzwAAoJEBRtltQi2kC70GMH/0ZIq10zhwuOjnMBJaUPMZVV Bq8Jsu7PqFFE4IJ0rQUpFEcNNmKkPlrINHK3eZNafKTmacqwSfVCZd1worUdvHpH JRr86cOxHKF2diwih4NpGgx4JtcfeGEDlA5I++3iTRifz5H/nQfrBil7BVI4ocpi wBcd6mCQa25LxfJePxxR6Az0fDcxxHPnHuQt/ve40v1zugDpk8TE3kjxLXfoclCg DZIqNZ84D7UGwPuGo/+VYNi07u1RO/MxBStSBFJvCDatAIQ8kzKLP60SVUGfSHyK auckyBMr5+LQWmJyh50UJyxtYn7c/aLnUzQfQ3aNUNdlaJT1mubgXCgFhzTGw4A= =pWH0 -END PGP SIGNATURE-
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #32 from Thomas Henlich thenlich at users dot sourceforge.net 2011-03-02 14:01:18 UTC --- No further bugs are known at this time...
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #29 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 14:01:20 UTC --- hppa2.0w-hp-hpux11.11 is listed as secondary platform, though not sure how narrowly we consider that (if hppa2.0w-hp-hpux10.* is considered also secondary, or just hpux11...).
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #13 from Marc Glisse marc.glisse at normalesup dot org 2011-03-02 14:05:23 UTC --- (In reply to comment #11) Thanks for the attachment. Do you have a small testcase for it? I would test here, commit, and then we can proceed with more serious changes for post 4.6... constexpr intmax_t m=(intmax_t)1(4*sizeof(intmax_t)-1); ratio_addratio1,(m-1)*(m-2),ratio1,(m-3)*(m-2) fails with the current libstdc++, works with the small patch, works with boost.
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-02 14:14:55 UTC --- Excellent.
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #15 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-03-02 14:58:00 UTC --- Author: paolo Date: Wed Mar 2 14:57:57 2011 New Revision: 170616 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170616 Log: 2011-03-02 Marc Glisse marc.gli...@normalesup.org PR libstdc++/47913 * include/std/ratio (ratio_add): Avoid denominator overflow. * testsuite/20_util/ratio/operations/47913.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/ratio/operations/47913.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/ratio
[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42622 --- Comment #8 from Marc Glisse marc.glisse at normalesup dot org 2011-03-02 14:58:06 UTC --- Created attachment 23514 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23514 4 lines of comments... It might be better to write a single paragraph explaining the algo instead of a couple lines at each step.
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-02 14:59:23 UTC --- Done. Then we can add more tests to 47913.cc.
[Bug libstdc++/42622] [C++0x] Improve std::ratio_less to not overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42622 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-02 15:06:29 UTC --- Applied, thanks.
[Bug tree-optimization/47714] verify_ssa fails with error: invalid argument to gimple call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47714 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.02 15:16:29 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-02 15:16:29 UTC --- Mine. It's not being marked for renaming in assemble_thunk for some reason.
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #9 from Vincent Lefèvre vincent at vinc17 dot org 2011-03-02
15:17:33 UTC ---
(In reply to comment #8)
Every warning warns about something valid in C, otherwise it would be an error
not a warning.
No, for instance:
int main(void)
{
int i;
return i;
}
This is undefined behavior and detected by GCC, but one gets only a warning:
tst.c: In function ‘main’:
tst.c:4: warning: ‘i’ is used uninitialized in this function
Compare to a == 0 in the above testcase, which has a well-defined behavior.
[Bug c++/47950] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950
Adam Butcher dev.lists at jessamine dot co.uk changed:
What|Removed |Added
CC||dev.lists at jessamine dot
||co.uk, jason at gcc dot
||gnu.org
--- Comment #1 from Adam Butcher dev.lists at jessamine dot co.uk 2011-03-02
15:39:00 UTC ---
Added Jason to CC.
Rolling back to my previous HEAD reveals that the reduced example above still
fails whereas the code I was originally trying to build worked. So obviously
my reduction has changed something. It doesn't change the fact that there is
an internal compiler error with the example above but it does mean that maybe
it is less likely to be hit.
So I was wrong that the above code has regressed in the last few days. The
code that I was originally trying to build, which did work a few days ago and
now fails with the symptoms described above was using BOOST_FOREACH. Obviously
this is unnecessary in C++0x as there is for(:) but it was compiling fine
before (and does in an old GCC 4.5 I have in C++0x mode).
The boost example was a non-dependent boost.foreach in a function template:
#include vector
#include boost/foreach.hpp
template typename T
void f()
{
std::vectorint v = { 1,2,3,4 };
BOOST_FOREACH(int x, v)
{
}
}
int main()
{
fint();
}
Making the vector dependent on T rather than int makes the problem go away. I
arrived at the reduction stated previously by breaking down BOOST_FOREACH until
the failure occurred.
Clearly there is an issue here but I'll do a bit more investigation into why
the boost example worked a few builds ago and why my reduction doesn't.
[Bug tree-optimization/45967] [4.5 Regression] gcc-4.5.x optimizes code with side-effects away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45967 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 15:54:36 UTC --- Created attachment 23515 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23515 patch for the 4.5 branch
[Bug c++/47957] New: Type mismatch when a class derived a same name with template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47957
Summary: Type mismatch when a class derived a same name with
template parameter
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
This bug report is for gcc 4.6(built in 2011/02/26)
I tried other version(gcc 4.1). But it doesn't have this problem.
struct Base
{
typedef int T ;
} ;
template typename T
struct Derived : Base
{
T member ; // T is Base::T, its type is int.
void f()
{// for instantiation Derived double
// type of T is double
std::cout T= typeid(T).name() std::endl ;
T variable ;
// type of variable is double
std::cout variable= typeid(variable).name() std::endl ;
// type of member is int
std::cout member= typeid(member).name() std::endl;
}
};
int main()
{
Derived double d ;
d.f() ;
}
Derived's base class is non-dependent name, so in the class scope Derived, name
T is Base::T, not a template parameter name T.
So for instantiation Deriveddouble, the name T in Derived class scope is
Base::T. it's type is int.
But in gcc 4.6,
Although the type of Derived::member is int,
the type of T become double in the member function body.
It looks like gcc 4.6 treat name T as a template parameter T in member function
body.
[Bug c++/47950] [4.6 Regression] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.02 16:07:53 Summary|[C++0x] Internal compiler |[4.6 Regression] [C++0x] |error: non-dependent|Internal compiler error: |declaration as condition|non-dependent declaration |causes |as condition causes |tsubst_copy_and_build |tsubst_copy_and_build |assertion failure. |assertion failure. Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-02 16:07:53 UTC --- (In reply to comment #1) So I was wrong that the above code has regressed in the last few days. Confirmed, it fails with 4.6.0 20110219 too, but not in c++98 mode or with 4.5
[Bug rtl-optimization/47958] New: [x32] reload generates invalid address reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47958
Summary: [x32] reload generates invalid address reference
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
[hjl@gnu-6 ilp32-27]$ cat x.i
void (*foo[6][6]) (int);
void bar (hdR)
int hdR;
{ }
void xxx ()
{
unsigned int i, j;
for (i = 0; i 6; ++i)
for (j = 0; j 6; ++j)
foo [i][j] = bar;
}
[hjl@gnu-6 ilp32-27]$ make x.o
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O3 x.i
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -O3 -c -o x.o x.s
x.s: Assembler messages:
x.s:39: Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
make: *** [x.o] Error 1
[hjl@gnu-6 ilp32-27]$ cat x.s
.filex.i
.text
.p2align 4,,15
.globlbar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE0:
.sizebar, .-bar
.p2align 4,,15
.globlxxx
.typexxx, @function
xxx:
.LFB1:
.cfi_startproc
movd.LC0(%rip), %xmm1
pshufd$0, %xmm1, %xmm0
movdqa%xmm0, foo(%rip)
movdqa%xmm0, foo+16(%rip)
movdqa%xmm0, foo+32(%rip)
movdqa%xmm0, foo+48(%rip)
movdqa%xmm0, foo+64(%rip)
movdqa%xmm0, foo+80(%rip)
movdqa%xmm0, foo+96(%rip)
movdqa%xmm0, foo+112(%rip)
movdqa%xmm0, foo+128(%rip)
ret
.cfi_endproc
.LFE1:
.sizexxx, .-xxx
.commfoo,144,32
.section.rodata.cst8,aM,@progbits,8
.align 8
.LC0:
.quadbar
.identGCC: (GNU) 4.6.0 20110301 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 ilp32-27]$
We have
(insn 6 2 7 2 (set (reg/f:DI 60 [ pretmp.6 ])
(symbol_ref:DI (bar) [flags 0x3] function_decl 0x70cebf00
bar)) x.i:6 62 {*movdi_internal_rex64}
(nil))
Reload calls force_const_mem (DImode, op) on symbol_ref:DI (bar).
The address reference in memory should be SImode/ptr_mode.
[Bug c++/47957] [4.3/4.4/4.5/4.6 Regression] Type mismatch when a class derived a same name with template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47957 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.2.4 Keywords||wrong-code Last reconfirmed||2011.03.02 16:13:35 Ever Confirmed|0 |1 Summary|Type mismatch when a class |[4.3/4.4/4.5/4.6 |derived a same name with|Regression] Type mismatch |template parameter |when a class derived a same ||name with template ||parameter Target Milestone|--- |4.3.6 Known to fail||4.3.5, 4.5.2, 4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 16:13:35 UTC --- Confirmed.
[Bug c++/47950] [4.6 Regression] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950 --- Comment #3 from Adam Butcher dev.lists at jessamine dot co.uk 2011-03-02 16:30:30 UTC --- (In reply to comment #1) Rolling back to my previous HEAD reveals that the reduced example above still fails whereas the code I was originally trying to build worked. So obviously my reduction has changed something. Okay. My original reduction was okay but I also added additional examples that yielded the same assertion failure (obviously via different route!). The function-call case following is the one that causes the failure in non-dependent use of boost.foreach on the latest 4.6 HEAD. It compiles okay on my 4.6 build from last week (prior to 170488). if (from_intint x = via_function(7)) ; The constructor cases below have failed for a much longer time (though are okay in 4.5). if (emptyint x = emptyint()) ; if (from_intint x = from_intint(7)) ; So the only recent regression is the function-call case. But all cases are all still legitimate 4.5 - 4.6 regressions. Before rev 170488 (25th Feb) the function-call case compiled. I don't know when the constructor cases stopped working -- I went quite a way back and they still failed.
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #13 from Jan Hubicka hubicka at ucw dot cz 2011-03-02 16:32:20 UTC --- Not mangling statics unless conflict is found is indeed desirable QOI thing. It makes assembly and other things look a lot more smoother than it does now. Honza
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #14 from Jan Hubicka hubicka at ucw dot cz 2011-03-02 16:34:22 UTC --- Ah, the reason for writting reply was primarily the observation that enforcing partitioning based on origin of asm statement won't fly with crossmoudle inlining, so I think it is quite useless complication of the whole thing. Also the not mangling unless we hit conflict probably should be implemented in a way that when conflict exists all static of same name are renamed, so asm statements won't compile rather that end up referring random other variable. Honza
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 16:39:09 UTC --- (In reply to comment #14) Ah, the reason for writting reply was primarily the observation that enforcing partitioning based on origin of asm statement won't fly with crossmoudle inlining, so I think it is quite useless complication of the whole thing. Well, with a used global local decl I would just leave the unit alone, doing a 1:1 partition for it (not mangling it). That way we can even handle multiple conflicting used declared statics ... Of course that's the same end-result as if the user would compile the unit without -flto. Not sure if it's worth going that way though. Also the not mangling unless we hit conflict probably should be implemented in a way that when conflict exists all static of same name are renamed, so asm statements won't compile rather that end up referring random other variable. Yes (assuming people forgot to annotate vars with attribute((used))). We should also consider mangling them according to the function or TU context, also for easier debugging. Not sure if this is possible without running into target limitations though. Richard.
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-02 16:42:02 UTC --- (In reply to comment #15) (In reply to comment #14) Ah, the reason for writting reply was primarily the observation that enforcing partitioning based on origin of asm statement won't fly with crossmoudle inlining, so I think it is quite useless complication of the whole thing. Well, with a used global local decl I would just leave the unit alone, doing a 1:1 partition for it (not mangling it). That way we can even handle multiple conflicting used declared statics ... Of course that's the same end-result as if the user would compile the unit without -flto. Not sure if it's worth going that way though. Also the not mangling unless we hit conflict probably should be implemented in a way that when conflict exists all static of same name are renamed, so asm statements won't compile rather that end up referring random other variable. Yes (assuming people forgot to annotate vars with attribute((used))). Of course if there is a conflict with a global (non-local) decl then the asm will bogously pick that up. So either way isn't bullet-proof. Richard.
[Bug debug/47919] -fcompare-debug failure with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47919 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-03-02 16:44:30 UTC --- Created attachment 23516 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23516 different testcase Another testcase that needs insane flags to reproduce... $ gcc -fcse-follow-jumps -fgcse -frerun-cse-after-loop -O -fira-region=one -fPIC -fcompare-debug -fno-dce -fno-ivopts -fno-tree-ch -funroll-loops -fno-web -m32 testcase.c gcc: error: testcase.c: -fcompare-debug failure (length)
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-02 16:45:26 UTC --- (In reply to comment #9) It seems that MinGW has its own implementation of snprintf called __mingw_snprintf [...] __mingw_snprintf has the desired behaviour From libgfortran/libgfortran.h: #if HAVE_MINGW_SNPRINTF extern int __mingw_snprintf (char *, size_t, const char *, ...) __attribute__ ((format (gnu_printf, 3, 4))); #undef snprintf #define snprintf __mingw_snprintf #endif That should take care of it - but seemingly it does not.
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 --- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-03-02 16:50:20 UTC --- I do not believe any component of the GCC or src tree uses a target libiberty. Thus, I do not think such a target libiberty should be built or installed by default. I also think host libiberty should not be installed by default, but that's a separate matter. http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html
[Bug c/47953] Code generation depends on function prototype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47953 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-03-02 16:54:10 UTC --- I suspect this is the same as bug 46076; at least it looks related.
[Bug lto/43038] DECL_PRESERVE_P or attribute((used)) static globals not completely preserved with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2011-03-02 16:56:47 UTC --- Well, with a used global local decl I would just leave the unit alone, doing a 1:1 partition for it (not mangling it). That way we can even handle multiple conflicting used declared statics ... Well, you would not only require 1:1 partition but prevent inliing functions containing asm statements posisbly referring used global local decl to other units. Not sure if it's worth going that way though. I would preffer we do not. It is ugly. Also the not mangling unless we hit conflict probably should be implemented in a way that when conflict exists all static of same name are renamed, so asm statements won't compile rather that end up referring random other variable. Yes (assuming people forgot to annotate vars with attribute((used))). I think this won't help, since alias analysis, readonly var discovery and others will stand in the way and break code on random basis. Main benefit IMO is to reduce the symbol tables and make nm output more readable etc. We should also consider mangling them according to the function or TU context, also for easier debugging. Not sure if this is possible without running into target limitations though. You mean something like mylocalstatic.mysourcefile.c? Possibly, it would make names noticeably longer obviously. Honza
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-02 17:03:47 UTC --- (In reply to comment #9) It seems that MinGW has its own implementation of snprintf called __mingw_snprintf which can be activated by defining __USE_MINGW_ANSI_STDIO In MinGW64, __USE_MINGW_ANSI_STDIO is set when _POSIX is specified. In MinGW that does not seem to be the case and one needs to specify it either directly or use another define such as _POSIX_SOURCE. Cf. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/_mingw.h?rev=1.61cvsroot=src From libgfortran/libgfortran.h: #if defined __MINGW32__ # define _POSIX 1 # define gfc_printf gnu_printf #else
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.03.02 17:06:47 Ever Confirmed|0 |1 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-03-02 17:06:47 UTC --- (In reply to comment #9) This is undefined behavior and detected by GCC, but one gets only a warning: I am not going to waste time discussing the fine-points of what is a valid C program. If you don't want this warning, please contribute a testcase to gcc-patc...@gcc.gnu.org, so this warning won't reappear in the future: http://gcc.gnu.org/wiki/HowToPrepareATestcase Otherwise, someone will come who thinks that this should be warned and they will fix it.
[Bug c/47953] Code generation depends on function prototype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47953 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-03-02 17:09:48 UTC --- (In reply to comment #1) I suspect this is the same as bug 46076; at least it looks related. I am not sure if they are related. Here we generate different codes based on function prototype.
[Bug c++/47956] [C++0x] gcc accepts static data member declaration with initializer for non-const literal type if type-specifier is auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47956 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.02 17:18:22 Summary|gcc accepts static data |[C++0x] gcc accepts static |member declaration with |data member declaration |initializer for non-const |with initializer for |literal type if |non-const literal type if |type-specifier is auto |type-specifier is auto Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-02 17:18:22 UTC --- confirmed, not a regression
[Bug c++/47959] New: [C++0x] brace-or-equal-initializer not allowed for static data member of const literal type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47959
Summary: [C++0x] brace-or-equal-initializer not allowed for
static data member of const literal type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
struct Lit { constexpr Lit() {} };
struct L
{
static const Lit l = Lit();
} ;
init.cc:5:30: error: 'constexpr' needed for in-class initialization of static
data member 'l' of non-integral type
I think the diagnostic is wrong.
[class.static.data] p3 says
If a static data member is of const literal type, its declaration in
the class definition can specify a brace-or-equal-initializer in which
every initializer-clause that is an assignment-expression is a constant
expression.
Lit is a literal type, L::l is of const literal type, the initializer is a
constant expression, so the example should be accepted.
[Bug libstdc++/47145] configure test for docbook-xsl-ns stylesheets uses hardcoded path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #23 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-03-02 17:43:54 UTC --- Created attachment 23517 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23517 what debian is currently using from Matthias Klose
[Bug rtl-optimization/47899] [4.5/4.6 Regression] ICE in get_loop_body, at cfgloop.c:831
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47899
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02
17:48:27 UTC ---
Thanks, this patch seems to work (I've bootstrapped/regtested it on
x86_64-linux and i686-linux together with the #c3 testcase with
/* PR rtl-optimization/47899 */
/* { dg-do compile } */
/* { dg-options -O -funroll-loops } */
under gcc/testsuite/gcc.dg/pr47899.c, no regressions).
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net 2011-03-02 17:54:34 UTC --- (In reply to comment #11) From libgfortran/libgfortran.h: #if defined __MINGW32__ # define _POSIX 1 # define gfc_printf gnu_printf #else Since the comment above that reads: /* Ensure that ANSI conform stdio is used. This needs to be set before any system header file is included. */ could it be that it was the intention to set __USE_MINGW_ANSI_STDIO in effect? So is this a bug in libgfortran.h and it was intended to put # define _POSIX_SOURCE 1 there?
[Bug c++/47960] New: dlopen call during DSO initialization breaks C++ RTTI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47960 Summary: dlopen call during DSO initialization breaks C++ RTTI Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: a_salni...@yahoo.com Hi, I am debugging a complex problem with our Linux-based applications sometimes crashing in mysterious ways. This is kind of usual exception RTTI problem when the exceptions thrown in one DSO is not correctly recognized in another DSO. We know so well that DSO and C++ RTTI do not always mix, but we follow all standard advices about how to build the apps to make RTTI work correctly and still it breaks. Our apps are a mixture of the Python interpreter and many C++ shared libraries loaded from Python (using dlopen). Some C++ libs in turn use dlopen to load other shared libraries. Everything is linked with the correct flags (no symbol hiding) and all dlopen calls use RTLD_GLOBAL flags, so we do expect things to work correctly. Things do work correctly but only when we link the DSOs together with the C++ main(), thus eliminating top-level dlopen call (other dlopen calls still remain there). With LD_DEBUG I was able to confirm that in that case all typeinfo instances are resolved correctly and bound to one instance in the library linked to main app. In case of Python calling dlopen on the same library LD_DEBUG shows that typeinfo resolution fails and there are two instances of the typeinfo object for the Exception type in question. I tried to reproduce the problem with simple example involving just a couple of DSOs and after some hair pulling I managed to do it. The peculiarity of the case (which I did not recognized initially) is that one of the dlopen() calls happens from the constructor of the global object (that is during the initialization of the corresponding DSO). If all dlopen calls happen in a regular way (after main() starts) then there is no problem at all. But if dlopen() happens during DSO init call then that DSO somehow is not used in the lookup for the dlopen'ed library symbols even tho DSO has RTLD_GLOBAL set. The example code that I attach here demonstrates exactly this. To build the example app just do (should work on Linux without patching): % tar zxf example.tgz % make This will build main app called 'main' and two DSOs: liba.so and libb.so. Main app calls ldopen for liba.so and calls a run() function from it. liba.so calls dlopen on libb.so either from run() function or from DSO init code depending on the particular envvar and then calls run() function from libb. libb's run() throws an exception that liba's run() tries to catch and analyze. To show default correct behavior with dlopen called only from inside main(): % ./main As expected: typeid(ex):0x2b594ce6e600 typeid(Exception): 0x2b594ce6e600 typeid(ex).name:9Exception typeid(Exception).name: 9Exception typeid(Exception)==typeid(ex): true To see what happens when dlopen is called from liba init code: % TEST_GLOBAL_INIT=1 ./main *** Not expected: typeid(ex):0x2b4532ad2050 typeid(Exception): 0x2b45328d0600 typeid(ex).name:9Exception typeid(Exception).name: 9Exception typeid(Exception)==typeid(ex): false In this case the exception cannot be caught with its real type (it is caught as std::exception) so RTTI is totally broken. Then name in the exception typeinfo is still correct, but the addresses of the typeinfo in liba and libb are different. From what I gather the C++ code in the example should be legal, global object initialization should not have restrictions on what functions it can call. But it seems like the implementation of the RTTI in gcc relies on the features that do not always work. Is there any way to fix the situation or at least to produce some kind of diagnostics when this situation happens? Regards, Andy
[Bug c++/47960] dlopen call during DSO initialization breaks C++ RTTI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47960 --- Comment #1 from Andy a_salnikov at yahoo dot com 2011-03-02 17:58:58 UTC --- Created attachment 23518 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23518 test case
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-02 18:02:15 UTC --- (In reply to comment #12) could it be that it was the intention to set __USE_MINGW_ANSI_STDIO in effect? Yes - and that is what does happen for _POSIX=1 on MinGW64. But it does not happen for _POSIX=1 on the 32bit MinGW. Jerry et al.: Do you think the following patch is OK? --- a/libgfortran/libgfortran.h +++ b/libgfortran/libgfortran.h @@ -33,6 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see any system header file is included. */ #if defined __MINGW32__ # define _POSIX 1 +# define _POSIX_SOURCE 1 # define gfc_printf gnu_printf #else # define gfc_printf __printf__
[Bug c++/47960] dlopen call during DSO initialization breaks C++ RTTI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47960 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-02 18:12:13 UTC --- works as expected with gcc 4.5, possibly due to the change to __GXX_MERGED_TYPEINFO_NAMES
[Bug libfortran/47945] REAL(8) output conversion error on MinGW32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #14 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-03-02 18:17:30 UTC --- On Wed, Mar 02, 2011 at 06:02:22PM +, burnus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-02 18:02:15 UTC --- (In reply to comment #12) could it be that it was the intention to set __USE_MINGW_ANSI_STDIO in effect? Yes - and that is what does happen for _POSIX=1 on MinGW64. But it does not happen for _POSIX=1 on the 32bit MinGW. Jerry et al.: Do you think the following patch is OK? --- a/libgfortran/libgfortran.h +++ b/libgfortran/libgfortran.h @@ -33,6 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see any system header file is included. */ #if defined __MINGW32__ # define _POSIX 1 +# define _POSIX_SOURCE 1 # define gfc_printf gnu_printf #else # define gfc_printf __printf__ I though a leading underscore in C denoted the namespace of the C compiler, and a userspace program should not set such a macro. Guess I'll pull out n1256.pdf later to read up on the convention. You may want to ask Joseph. It may also be prudent to add #if define _POSIX_SOURCE #undef _POSIX_SOURCE #endif prior to (re)setting it to 1.
[Bug c++/47200] [C++0x] ICE: in adjust_temp_type, at cp/semantics.c:5821 with missing definition of constexpr function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47200 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-03-02 18:18:35 UTC --- Author: jason Date: Wed Mar 2 18:18:31 2011 New Revision: 170620 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170620 Log: PR c++/47200 * semantics.c (cxx_bind_parameters_in_call): Don't call adjust_temp_type on non-constant args. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-non-const-arg2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/46159] [4.5/4.6 Regression] Bogus warning about lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46159 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-02 18:18:48 UTC --- Author: jason Date: Wed Mar 2 18:18:41 2011 New Revision: 170621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170621 Log: PR c++/46159 * parser.c (cp_parser_primary_expression): Don't warn about a failed tentative parse. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-98.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47957] [4.3/4.4/4.5/4.6 Regression] Type mismatch when a class derived a same name with template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47957 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 18:21:07 UTC --- This changed behavior in http://gcc.gnu.org/viewcvs?root=gccview=revrev=143315 (i.e. for PR36019 ).
[Bug c++/46159] [4.5 Regression] Bogus warning about lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46159 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|[4.5/4.6 Regression] Bogus |[4.5 Regression] Bogus |warning about lambdas |warning about lambdas Known to fail||4.5.2 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-02 18:22:45 UTC --- Fixed on the trunk so far.
[Bug c++/46159] [4.5 Regression] Bogus warning about lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46159 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-03-02 18:46:04 UTC --- Author: jason Date: Wed Mar 2 18:46:01 2011 New Revision: 170622 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170622 Log: PR c++/46159 * parser.c (cp_parser_primary_expression): Don't warn about a failed tentative parse. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-98.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/parser.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug c++/46159] [4.5 Regression] Bogus warning about lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46159 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-03-02 18:48:04 UTC --- Fixed in 4.5 as well.
[Bug c++/47960] dlopen call during DSO initialization breaks C++ RTTI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47960 --- Comment #3 from Andy a_salnikov at yahoo dot com 2011-03-02 18:50:56 UTC --- (In reply to comment #2) works as expected with gcc 4.5, possibly due to the change to __GXX_MERGED_TYPEINFO_NAMES Hi Jonathan, sorry, I do not watch closely the progress, do you mean tha gcc 4.6 has __GXX_MERGED_TYPEINFO_NAMES disabled? Andy
[Bug c++/47960] dlopen call during DSO initialization breaks C++ RTTI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47960 --- Comment #4 from Andy a_salnikov at yahoo dot com 2011-03-02 18:51:49 UTC --- (In reply to comment #3) (In reply to comment #2) works as expected with gcc 4.5, possibly due to the change to __GXX_MERGED_TYPEINFO_NAMES Hi Jonathan, sorry, I do not watch closely the progress, do you mean tha gcc 4.6 has __GXX_MERGED_TYPEINFO_NAMES disabled? Andy Sorry, that should have been 4.5, not 4.6.
[Bug c++/47952] [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.03.02 19:03:48 Ever Confirmed|0 |1 --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-03-02 19:03:48 UTC --- I can't reproduce the error. Instead, I get: houston:/build/tm/gcc$ /build/tm/install/bin/c++ a.c -fgnu-tm -O0 -fgnu-tm -litm /usr/lib/../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /tmp/ccOXn6kg.o: In function `buildProjectSyncStepConcurrently()': a.c:(.text+0x23): undefined reference to `transaction clone for Game::isHardSpaceForBuilding()' /tmp/ccOXn6kg.o: In function `transaction clone for buildProjectSyncStepConcurrently()': a.c:(.text+0xe0): undefined reference to `transaction clone for Game::isHardSpaceForBuilding()' collect2: ld returned 1 exit status As I see no definition for isHardSpaceForBuilding() in the source (just a prototype), I expect this error. Did you give me an incorrect testcase, or perhaps this is a binutils (linker) problem (I'm using binutils-2.20.51.0.7-6.fc14.x86_64). ??
[Bug c++/47960] dlopen call during DSO initialization breaks C++ RTTI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47960 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-02 19:43:17 UTC --- Yes, from http://gcc.gnu.org/gcc-4.5/changes.html The default behavior for comparing typeinfo names has changed, so in typeinfo, __GXX_MERGED_TYPEINFO_NAMES now defaults to zero. I think the changes were made to the trunk around October 2009
[Bug c++/47960] dlopen call during DSO initialization breaks C++ RTTI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47960 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-02 19:45:02 UTC --- http://gcc.gnu.org/viewcvs?view=revisionrevision=153768
[Bug c++/47873] [4.6 Regression] virtual Inheritance - Covariant Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47873 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2011-03-02 19:49:50 UTC --- Fixed.
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #17 from Marc Glisse marc.glisse at normalesup dot org 2011-03-02 20:50:42 UTC --- Some more examples. Using the constants: m=INTMAX_MAX; n=INTMAX_MAX/2; p=((intmax_t)1(4*sizeof(intmax_t)-1))-3 (m,2)-(m,3)==(m,6) boost should manage this one (m/7*5-1,5)-(m-2,7) __big_mul would be enough (__big_div is the hard thing) (n-5,15)+(n,35) one could cheat by removing the integral part (p^2,(2*p-3)*(p-2))-(p+2,(p-1)*(p-2)) one may be able to write gcd=(p-2), p^2 as (p+2)*gcd+4 and the computation of the numerator becomes gcd*((p+2)*(p-1)-(2*p-3))+4*(p-1)-4*(2*p-3) and both computations (p+2)*(p-1)-(2*p-3) and 4*(p-1)-4*(2*p-3) fit in a intmax_t. But with a larger gcd, they may not (I'll try to add an example later).
[Bug c/47961] New: media-libs/xvid-1.3.0 fails to build on SPARC unless -mvis flag stripped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47961
Summary: media-libs/xvid-1.3.0 fails to build on SPARC unless
-mvis flag stripped
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alex.bu...@munted.org.uk
Using -mcpu=ultrasparc3 -mvis results in xvi-1.3.0 failing to compile its
source. Symptoms include the following:
standard input}:11751: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11781: Error: Architecture mismatch on bge,pn %icc,.LL483.
{standard input}:11781: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11787: Error: Architecture mismatch on bl,a,pt %icc,.LL522.
{standard input}:11787: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11792: Error: Architecture mismatch on be,a,pn %icc,.LL523.
{standard input}:11792: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11819: Error: Architecture mismatch on return.
{standard input}:11819: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11832: Error: Architecture mismatch on fcmped.
my solution was to remove the -mvis flag, and all was well.
[Bug c/47962] New: media-libs/xvid-1.3.0 fails to build on SPARC unless -mvis flag stripped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47962
Summary: media-libs/xvid-1.3.0 fails to build on SPARC unless
-mvis flag stripped
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alex.bu...@munted.org.uk
Host: SPARC64
Target: SPARC64
Build: SPARC64
Using -mcpu=ultrasparc3 -mvis results in xvi-1.3.0 failing to compile its
source. Symptoms include the following:
standard input}:11751: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11781: Error: Architecture mismatch on bge,pn %icc,.LL483.
{standard input}:11781: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11787: Error: Architecture mismatch on bl,a,pt %icc,.LL522.
{standard input}:11787: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11792: Error: Architecture mismatch on be,a,pn %icc,.LL523.
{standard input}:11792: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11819: Error: Architecture mismatch on return.
{standard input}:11819: (Requires v9|v9a|v9b; requested architecture is
sparclite.)
{standard input}:11832: Error: Architecture mismatch on fcmped.
my solution was to remove the -mvis flag, and all was well.
[Bug target/47949] Missed optimization for -Os using xchg instead of mov.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47949 --- Comment #3 from Steven Fuerst svfuerst at gmail dot com 2011-03-02 21:51:12 UTC --- Having a quick look at generated code... it appears that this pattern doesn't come up all that often. However, there is one case where it does: the epilogue of a function. i.e. gcc tends to generate code looking like: movl%ebp, %eax movq8(%rsp), %rbx movq16(%rsp), %rbp movq24(%rsp), %r12 movq32(%rsp), %r13 addq$40, %rsp ret Replacing the move to %eax with an exchange with %ebp is a win in this particular case. The extra cycle or two of latency that xchg takes doesn't matter as the other moves and ret instruction overlap in execution with it. Benchmarking on an opteron in 64bit mode confirms this hypothesis even in the degenerate case where no other moves exist: foo1: mov %edi, %eax retq foo2: xchg %eax, %edi retq foo1 and foo2 take the same time to execute.
[Bug c/47963] New: [4.5/4.6 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47963 Summary: [4.5/4.6 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 23519 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23519 reduced testcase Compiler output: $ gcc -fopenmp testcase.c testcase.c: In function 'foo': testcase.c:3:7: error: size of array 'A' has non-integer type testcase.c:3:7: error: size of array 'A' has non-integer type testcase.c:4:9: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r170594 - crash 4.5 r170013 - crash 4.4 r170013 - OK
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org 2011-03-02 22:08:51 UTC --- Did you build the application as a 32 bit or 64 bit application? If you used the default 32 bit on AIX did you try using -maix64?
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2011-03-02 22:29:43 UTC --- I can reproduce this bug. It occurs in AIX 32 bit mode, but not in AIX 64 bit mode. Linux 32 bit mode ABI is different than AIX 32 bit ABI, so it is more difficult for LTC to reproduce. They are going to try Linux 32 bit -fpic/-fPIC.
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 --- Comment #4 from Tejas Karkhanis tkarkha at us dot ibm.com 2011-03-02 22:35:01 UTC --- David, I tried building with -maix64 flag. Here is the output after compiling with -maix64 flag: gcc-4.6.0 -Wall -O3 -I ./ -std=gnu99 -maltivec -mabi=altivec -flax-vector-conversions -mvsx -mcpu=power7 -mtune=power7 -maix64 gccBugTest.c -o gccBugTest_GCC $ ./gccBugTest_GCC DEBUG:: u_in0 = 1.00,2.00,3.00,4.00 DEBUG:: u_in1 = 5.00,6.00,7.00,8.00 DEBUG::foo:: l_temp0 = 1.00,2.00,3.00,4.00 DEBUG::foo:: l_temp1 = 5.00,6.00,7.00,8.00 DEBUG::foo:: in0 HI = 1.00,0.00 DEBUG::foo:: in0 LO = 3.00,0.00 DEBUG::foo:: in1 HI = 5.00,0.00 DEBUG::foo:: in1 LO = 7.00,0.00 DEBUG::foo:: l_result HI = 6.00,8.00 DEBUG::foo:: l_result LO = 10.00,0.00 DEBUG::foo:: result:: l_temp2 = 6.00,8.00,10.00,0.00 DEBUG:: u_out = 6.00,8.00,10.00,0.00 $ Notice that this time the error is in the right-most element of the variable u_out -- the right-most element should have been 12.00.
[Bug c++/47950] [4.6 Regression] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47950 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 --- Comment #5 from David Edelsohn dje at gcc dot gnu.org 2011-03-02 22:48:10 UTC --- The bug does not occur with -O1. It does occur with -O2 and above, both 32 bit and 64 bit AIX.
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 --- Comment #6 from David Edelsohn dje at gcc dot gnu.org 2011-03-02 22:51:04 UTC --- Created attachment 23520 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23520 Assembly output from testcase
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 --- Comment #7 from Pat Haugen pthaugen at gcc dot gnu.org 2011-03-02 23:01:59 UTC --- -fpic/-fPIC don't cause a failure on Linux either. I consistently get the following output no matter what I've tried. [pthaugen@ltcgranola3p01 hmmer]$ a.out DEBUG:: u_in0 = 1.00,2.00,3.00,4.00 DEBUG:: u_in1 = 5.00,6.00,7.00,8.00 DEBUG::foo:: l_temp0 = 1.00,2.00,3.00,4.00 DEBUG::foo:: l_temp1 = 5.00,6.00,7.00,8.00 DEBUG::foo:: in0 HI = 1.00,2.00 DEBUG::foo:: in0 LO = 3.00,4.00 DEBUG::foo:: in1 HI = 5.00,6.00 DEBUG::foo:: in1 LO = 7.00,8.00 DEBUG::foo:: l_result HI = 6.00,8.00 DEBUG::foo:: l_result LO = 10.00,12.00 DEBUG::foo:: result:: l_temp2 = 6.00,8.00,10.00,12.00 DEBUG:: u_out = 6.00,8.00,10.00,12.00
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 --- Comment #8 from Pat Haugen pthaugen at gcc dot gnu.org 2011-03-02 23:03:36 UTC --- (In reply to comment #6) Created attachment 23520 [details] Assembly output from testcase David, Can you post your output you get from this run, since we've seen variations now.
[Bug target/47947] Varibles of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47947 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.0 |---
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-02 23:21:07 UTC --- (In reply to comment #17) Some more examples. Using the constants: m=INTMAX_MAX; n=INTMAX_MAX/2; p=((intmax_t)1(4*sizeof(intmax_t)-1))-3 (m,2)-(m,3)==(m,6) boost should manage this one I'm not sure to understand, I was under the impression that right now GCC is essentially equal to boost::rational?!?
