[Bug target/56096] Bad code generated for conditional shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56096 --- Comment #1 from Mikael Pettersson 2013-01-24 08:54:44 UTC --- "Bad" is ambiguous, it could mean "sub-optimal" or it could mean "incorrect" or "wrong". In this case it means "sub-optimal", please change the PR summary to reflect that.
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 --- Comment #4 from Mikael Pettersson 2013-01-24 09:31:20 UTC --- I've checked and gcc-4.6 does miscompile this test case, but gets it right with the PR52573 fix applied. Vanilla gcc-4.7 doesn't seem to miscompile this particular test case, but it still miscompiles the original PR52573 test case. Anyway, I'm certain this PR is a dup of PR52573 so please close it as such.
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #5 from Jakub Jelinek 2013-01-24 09:37:17 UTC --- Dup. *** This bug has been marked as a duplicate of bug 52573 ***
[Bug rtl-optimization/52573] [4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 Jakub Jelinek changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #15 from Jakub Jelinek 2013-01-24 09:37:17 UTC --- *** Bug 56087 has been marked as a duplicate of this bug. ***
[Bug other/56076] [4.8 regression] Several 64-bit libgo tests FAIL in read_line_header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56076
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek 2013-01-24
09:47:00 UTC ---
I guess if DW_AT_comp_dir attribute is missing, we could crash that way.
We could do:
--- libbacktrace/dwarf.c.jj2013-01-17 13:42:51.0 +0100
+++ libbacktrace/dwarf.c2013-01-24 10:43:38.234973942 +0100
@@ -1655,7 +1655,8 @@ read_line_header (struct backtrace_state
strnlen ((const char *) hdr_buf.buf, hdr_buf.left) + 1))
return 0;
dir_index = read_uleb128 (&hdr_buf);
- if (IS_ABSOLUTE_PATH (filename))
+ if (IS_ABSOLUTE_PATH (filename)
+ || (dir_index == 0 && u->comp_dir == NULL))
hdr->filenames[i] = filename;
else
{
or perhaps issue an error if dir_index == 0 && u->comp_dir == NULL inside of
else.
But I believe even some GCC versions in the past were buggy and didn't emit
DW_AT_comp_dir always when needed, and other compilers could have similar bugs
too, so perhaps we should be more forgiving.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 --- Comment #8 from Steven Bosscher 2013-01-24 10:30:29 UTC --- Author: steven Date: Thu Jan 24 10:30:26 2013 New Revision: 195420 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195420 Log: gcc/ PR inline-asm/55934 * lra-assigns.c (assign_by_spills): Throw away the pattern of asms that have operands with impossible constraints. Add a FIXME for a speed-up opportunity. * lra-constraints.c (process_alt_operands): Verify that a class selected from constraints on asms is valid for the operand mode. (curr_insn_transform): Remove incorrect comment. testsuite/ PR inline-asm/55934 * gcc.target/i386/pr55934.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55934.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Steven Bosscher 2013-01-24 10:31:06 UTC --- .
[Bug libstdc++/56085] Unsafe negation in C++03 pow(complex,int)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #2 from Paolo Carlini 2013-01-24 11:20:21 UTC --- Thanks Marc for noticing, the core problem seems very old, but probably when it belonged to __pow_helper was less visible because of (non-)inlining. Let's fix this.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #39 from Iain Sandoe 2013-01-24 11:34:20 UTC --- (In reply to comment #38) > Tested proposed patch from Comment 37 on x86_64-apple-darwin11 and > x86_64-apple-darwin12 with Xcode 4.5.2 on both systems. No regressions are > found > in darwin_objdir/x86_64-apple-darwin11.4.2/libitm build directory. Looks good > to go. FAOD, I was not (at this stage) proposing comment #37 as a "fix" - but rather to demonstrate what seems to be inconsistent behavior in the linker. The inconsistency is: (where there is a reference made in "other objects" to some symbol(s) present in both the dylib and the object): causes the references to be satisfied from the object, NOT the dylib. (and also seems unexpected to me) whereas: causes the symbols to be resolved from the dylib (which is what I would have expected) === IFF that behavior is as expected and documented - then, fine - the patch is a fix, but I think we need to establish what is expected behavior - or we will be going around this loop again in 6 months, 1 year .. etc.
[Bug c++/56095] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler 2013-01-24 11:56:31 UTC --- While I agree that the ICE needs to be fixed, let me add in here that any conversion that requires the equivalent of a reinterpret_cast is not valid in a constant expression in C++11. Furthermore, there are even more fundamental restrictions on the form of the non-type template arguments as described in [temp.arg.nontype] p1, which exclude *any* form of a cast expression at that place. These rules also exclude the case that you tried in your second example where you are attempting to use a constexpr variable. The essential wording here is: "a constant expression (5.19) that designates the address of [..] a function with external or internal linkage, including function templates and function template-ids [..], expressed (ignoring parentheses) as &id-expression, except that the & may be omitted if the name refers to a function [..]" Basically this means you can only directly name a function here such as z(); which of course won't work in your case because of the incompatible signature.
[Bug c++/56095] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #3 from Jonathan Wakely 2013-01-24 12:01:32 UTC --- I cant reproduce the crash with any version
[Bug c++/56095] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 --- Comment #4 from Daniel Krügler 2013-01-24 12:07:25 UTC --- (In reply to comment #3) > I cant reproduce the crash with any version Here is what I get with my mingw-64 gcc 4.8.0 20130120 (experimental): "main.cpp||In function 'int main(int, char**)':| main.cpp|7|internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'nop_expr' in decl_linkage, at cp/tree.c:3527" When I use http://liveworkspace.org/code/47sr7W$0 I also get "source.cpp:7:33: internal compiler error: Segmentation fault"
[Bug c++/56095] [4.6/4.7/4.8 Regression] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|Crash casting function |[4.6/4.7/4.8 Regression] |pointer as non-type |Crash casting function |template argument |pointer as non-type ||template argument --- Comment #5 from Jakub Jelinek 2013-01-24 12:11:13 UTC --- I can, with everything starting from http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166167 You need --enable-checking=yes compiler though.
[Bug c++/56095] [4.6/4.7/4.8 Regression] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |4.6.4
[Bug lto/56088] [4.8 Regression] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|LTO error: error: inlining |[4.8 Regression] LTO error: |failed in call to |error: inlining failed in |always_inline ‘vswprintf’: |call to always_inline |recursive inlining |‘vswprintf’: recursive ||inlining
[Bug c++/56095] [4.6/4.7/4.8 Regression] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-24 Ever Confirmed|0 |1 --- Comment #6 from Jonathan Wakely 2013-01-24 12:13:56 UTC --- Doh, sorry, copy'n'paste failure. I copied the test wrong.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener 2013-01-24 12:17:14 UTC --- Statements with no location inherit that of the surrounding statements. The issue is that the rewritten statements usually do not exist in literal form in the original program. The final assignment of the result of course should retain use->stmts location. Now what can happen is that the stmts without location are scheduled into the prologue ... not sure how / if we want to avoid this. Jakub? Note I didn't look at the testcase at all.
[Bug libstdc++/56085] Unsafe negation in C++03 pow(complex,int)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085 --- Comment #3 from paolo at gcc dot gnu.org 2013-01-24 12:21:06 UTC --- Author: paolo Date: Thu Jan 24 12:20:57 2013 New Revision: 195421 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195421 Log: 2013-01-24 Paolo Carlini PR libstdc++/56085 * include/std/complex (pow(const complex<>&, int)): Avoid __n signed overflow. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/complex
[Bug libstdc++/56085] Unsafe negation in C++03 pow(complex,int)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085 --- Comment #4 from paolo at gcc dot gnu.org 2013-01-24 12:21:33 UTC --- Author: paolo Date: Thu Jan 24 12:21:24 2013 New Revision: 195422 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195422 Log: 2013-01-24 Paolo Carlini PR libstdc++/56085 * include/std/complex (pow(const complex<>&, int)): Avoid __n signed overflow. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/std/complex
[Bug libstdc++/56085] Unsafe negation in C++03 pow(complex,int)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #5 from Paolo Carlini 2013-01-24 12:22:31 UTC --- Fixed mainline and 4.7.3.
[Bug middle-end/56077] [4.6/4.7/4.8 Regression] volatile ignored when function inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56077 Jakub Jelinek changed: What|Removed |Added CC||abel at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|volatile ignored when |[4.6/4.7/4.8 Regression] |function inlined|volatile ignored when ||function inlined --- Comment #7 from Jakub Jelinek 2013-01-24 12:30:54 UTC --- This (for -O2) regressed with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139854 (for -O -fschedule-insns2 it regressed later, when fwprop got added for -O1). r139854 added sel-sched support, but I believe it wasn't (and isn't) the default scheduler on x86_64/i?86, thus clearly the branch merge must have affected also behavior of the normal scheduler.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-24 12:45:44 UTC --- > --- Comment #30 from Richard Biener 2013-01-23 > 16:49:05 UTC --- > Is it still a regression from 4.7.x? Not anymore, judging from my testcase: trunk: real6:57.67 user6:51.39 sys0.58 4.7 branch: real 23:22.10 user 23:21.08 sys0.45 Rainer
[Bug tree-optimization/56097] New: Segmentation fault with -01 -ftree-vrp -ftree-loop-distribute-patterns -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56097
Bug #: 56097
Summary: Segmentation fault with -01 -ftree-vrp
-ftree-loop-distribute-patterns -funswitch-loops
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sti...@gmail.com
Possible duplicate of bug 55964. The following test case fails with -01
-ftree-vrp -ftree-loop-distribute-patterns -funswitch-loops. The same test case
worked fine with gcc 4.5:
$ cat test3.c
struct test_struct {
int a, b[10], c[10], d[10];
};
extern struct test_struct* new_struct;
void testfunc(struct test_struct* old_struct) {
int i;
for (i = 0; i < 10; ++i) {
new_struct->b[i] = old_struct ? old_struct->b[i] : -1;
new_struct->c[i] = old_struct ? old_struct->c[i] : 0;
new_struct->d[i] = old_struct ? old_struct->d[i] : 0;
}
/* commenting out the following line eliminates the crash */
if (old_struct) old_struct->a++;
}
$ gcc -c -O1 -ftree-vrp -ftree-loop-distribution -funswitch-loops -o test3.o
test3.c
test3.c: In function ‘testfunc’:
test3.c:7:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
$ gcc -v
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078 --- Comment #7 from Jakub Jelinek 2013-01-24 13:27:55 UTC --- Created attachment 29264 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29264 gcc48-pr56078.patch Patch I've bootstrapped/regtested. It seems in most places constructor_max_index == NULL was treated as unlimited bound (compared to e.g. constructor_max_index being -1 as zero size bound with nothing allowed), but these two spots either didn't handle it at all, or incorrectly. The patch fixes the new testcase, both that it doesn't ICE and behaves expectedly, but unfortunately at the same time regresses gcc.c-torture/compile/20030305-1.c testcase, which is no longer accepted. It was filed as ice-on-invalid, is it really supposed to be a valid GNU C99 testcase?
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #37 from William J. Schmidt 2013-01-24 13:30:53 UTC --- (In reply to comment #36) > Bill, tests in Instrumentation/AddressSanitizer are compiler-only tests > and thus are mostly platform independent. > The interesting part is the run-time tests that can be run with "make > check-asan" > (only in cmake build) > These build on PPC64 today and some of them even pass, but not all. OK. Please let me know if we can assist setting up a PPC bot in the future, to help maintain compatibility.
[Bug c++/54835] [C++11] Explicit default constructors not respected during copy-list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-24 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2013-01-24 13:32:34 UTC --- confirmed, not a regression
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078 --- Comment #8 from Jakub Jelinek 2013-01-24 13:33:13 UTC --- Before my patch we got: 20030305-1.c:15:5: warning: excess elements in struct initializer [enabled by default] 20030305-1.c:15:5: warning: (near initialization for ‘s2_array[0]’) [enabled by default] 20030305-1.c:16:5: warning: excess elements in struct initializer [enabled by default] 20030305-1.c:16:5: warning: (near initialization for ‘s2_array[1]’) [enabled by default] 20030305-1.c:17:5: warning: excess elements in struct initializer [enabled by default] 20030305-1.c:17:5: warning: (near initialization for ‘s2_array[2]’) [enabled by default] and with the patch: 20030305-1.c:15:5: error: initialization of flexible array member in a nested context 20030305-1.c:15:5: error: (near initialization for ‘s2_array[0].s1_array’) 20030305-1.c:16:5: error: initialization of flexible array member in a nested context 20030305-1.c:16:5: error: (near initialization for ‘s2_array[1].s1_array’) 20030305-1.c:17:5: error: initialization of flexible array member in a nested context 20030305-1.c:17:5: error: (near initialization for ‘s2_array[2].s1_array’) instead. I'd lean towards the errors being correct, Joseph, do you agree? If so, I'll move the 20030305-1.c testcase into gcc.dg and add dg-error comments.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #23 from Andrey Belevantsev 2013-01-24 13:37:05 UTC --- You are right from the target maintainer point of view, as you understand what really happens in the code. But this is not what the compiler sees as the relations between insns you are talking about are not always expressed in the RTL. Consider insns 17 and 23, not looking at the other insns. From their RTL there is no "clear control and data dependencies" at all, they don't mention the same register or memory. (You are saying that insn 17 represents a call but it is not clear from its representation, too.) As I mentioned, the only reason insn 23 gets dependent on insn 17 is that ira_implicitly_set_insn_hard_regs kicks in and says, we have a LINK_REGS alternative in insn 23, and the corresponding reg class is small, let us consider insn 23 clobber reg 65 (LR), and because insn 17 also clobbers reg 65 you get a dependency. This was added with the sched-pressure code, which is why I CC'd Vlad. And this issue is not sel-sched specific, you need just to disable the if (! reload_completed) at sched-deps.c:2805 with e.g. && INSN_UID (insn) != 23, and remove the -fselective-scheduling flag, and you will see the regular scheduler happily lift off insn 23 through insn 17 and place it before insn 17, as there is no dependency that can be guessed by the regular sched-deps analysis just by looking at the RTL of those insns. If you want to have such a dependency, I'd suggest to add some specific clobber as it is done for insn 17. This will fix this particular issue, but in general the question on the register renaming in the sel-sched remains, as we just see 17: r3 = rhs1 20: use(r3) 24: r3 = rhs2 and we assume we can do new1: r150 = rhs2 17: r3 = rhs1 20: use(r3) new2: r3 = r150 and this will not create random dependencies between insn new1 and insn 17 as it happens now. Again, there is no dependencies that can be seen from the RTL that prevent us from doing so.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #38 from Kostya Serebryany 2013-01-24 13:46:17 UTC --- > OK. Please let me know if we can assist setting up a PPC bot in the future, > to > help maintain compatibility. Oh, that'll be great even now. If you can setup a bot that builds asan-runtime for PPC32 and PPC64 and runs the test, it will be awesome! Just let the bot execute these steps in order: make -j 64 clang_rt.asan-powerpc64 make -j 64 clang_rt.asan-powerpc make -j 64 Asan-powerpc64-Test make -j 64 Asan-powerpc-Test make -j 64 check-asan The last step is red now, but we'll fix it eventually. We may even need two bots, for 44-bit and 46-bit AS. (as it's taking us away from this bug, perhaps we could continue by e-mail)
[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-24
Ever Confirmed|0 |1
--- Comment #2 from janus at gcc dot gnu.org 2013-01-24 13:50:34 UTC ---
Here is a patch to accept the test case in comment 0:
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c(revision 195411)
+++ gcc/fortran/match.c(working copy)
@@ -1830,12 +1830,14 @@ gfc_match_associate (void)
gfc_association_list* a;
/* Match the next association. */
+ gfc_matching_procptr_assignment = 1;
if (gfc_match (" %n => %e", newAssoc->name, &newAssoc->target)
!= MATCH_YES)
{
gfc_error ("Expected association at %C");
goto assocListError;
}
+ gfc_matching_procptr_assignment = 0;
newAssoc->where = gfc_current_locus;
/* Check that the current name is not yet in the list. */
I feels a bit like a hack and I'm not sure if it might break something (will
regtest now).
Also, I haven't checked yet if anything more is needed for a full runtime test,
where the associate symbol is actually used in some way.
[Bug tree-optimization/49657] array subscript warnings when building gcc with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49657 --- Comment #3 from mirimiri66 at gmail dot com 2013-01-24 13:53:18 UTC --- Created attachment 29265 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29265 gcc-4.6.3 QA Notices
[Bug tree-optimization/49657] array subscript warnings when building gcc with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49657 --- Comment #4 from mirimiri66 at gmail dot com 2013-01-24 13:54:20 UTC --- Created attachment 29266 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29266 gentoo package systeme emerge --info
[Bug tree-optimization/49657] array subscript warnings when building gcc with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49657 mirimiri66 at gmail dot com changed: What|Removed |Added CC||mirimiri66 at gmail dot com --- Comment #5 from mirimiri66 at gmail dot com 2013-01-24 13:56:54 UTC --- I get similar QA notices when compiling gcc-4.6.3 in gentoo. Gentoo package notes instructed to report this here instead of filing a gentoo bug. I've got these flags set in /etc/make.conf: CFLAGS="-fomit-frame-pointer -march=native -O2 -pipe" Is this something I need to address somehow? Added QA Notices and gentoo package system emerge --info attachments.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #4 from Jakub Jelinek 2013-01-24 14:19:17 UTC --- On a brief look, this doesn't look like using location of neighbouring statement, given: grep 66:1 pr56094.c.115t.cunroll | wc -l 0 grep 66:1 pr56094.c.119t.ivopts | wc -l 39
[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 --- Comment #3 from janus at gcc dot gnu.org 2013-01-24 14:52:48 UTC --- (In reply to comment #2) > Here is a patch to accept the test case in comment 0: It fails on: FAIL: gfortran.dg/associate_6.f03 -O (test for excess errors) associate_6.f03:30.25: ASSOCIATE (arr => func (4)) 1 Error: Expected ')' or ',' at (1) Since we're fooling the parser to believe that we're matching a proc-ptr assignment, it does not swallow the parens after the function name (but expects a 'bare' function name as a proc-ptr target). (I wonder whether we properly handle proc-ptr-valued functions as target in a proc-ptr assignment. Should check that ...)
[Bug tree-optimization/55755] Invalid VIEW_CONVERT_EXPR produced by SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55755 --- Comment #4 from Martin Jambor 2013-01-24 14:54:02 UTC --- Author: jamborm Date: Thu Jan 24 14:53:56 2013 New Revision: 195425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195425 Log: 2013-01-24 Martin Jambor Backport from mainline 2013-01-04 Martin Jambor PR tree-optimization/55755 * tree-sra.c (sra_modify_assign): Do not check that an access has no children when trying to avoid producing a VIEW_CONVERT_EXPR. testsuite/ * gcc.dg/torture/pr55755.c: New test. * gcc.dg/tree-ssa/sra-13.c: Likewise. * gcc.dg/tree-ssa/pr45144.c: Update. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55755.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/tree-ssa/sra-13.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/tree-ssa/pr45144.c branches/gcc-4_7-branch/gcc/tree-sra.c
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #40 from Jack Howarth 2013-01-24 14:54:34 UTC --- (In reply to comment #39) My understanding from Nick's comments was that the ld64/dyld behavior is now as follows. For performance reasons, weak coalescing is only done if the weak symbols occur in a library (shared or static) and those symbols that are marked weak in object files are not weak coalesced by dyld. His comments weren't explicit on that point and I've asked him to confirm that your work-around of using a static library for the weak symbols isn't exploiting a 'bug' in ld64/dyld that will disappear in a future Xcode release. I should also note that your patch does produce some regressions on darwin10 with Xcode 4.2 but this shouldn't shock anyone as we are well aware that -undefined dynamic_lookup was broken from Xcode 4.2 until it was fixed again in Xcode 4.4 (radr://10466868). I wouldn't worry about this as... 1) The Xcode 4.x series was never fully supported on darwin10 and only briefly made available to end-users. Users on darwin10 really need to stick to Xcode 3.2.6 to avoid the -undefined dynamic_lookup bug introduced at Xcode 4.2. 2) Users on darwin11/12 can use any Xcode after 4.4 which are all freely available from Apple on connect.apple.com. There is a limit to the number of linker bugs that can be worked around at the same time in FSF gcc on darwin and I would focus more on those Xcode releases which provided expected behavior rather than buggy behavior. IMHO, the current situation is unacceptable for libitm and needs to be fixed since for all modern (supported) darwin (10/11/12), the stub symbols in crttme.o are overriding those in libstdc++. ps On darwin10 with Xcode 4.2, the failures are all of the form... dyld: Symbol not found: __ZdaPv Referenced from: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libitm/.libs/libitm.1.dylib Expected in: flat namespace in /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libitm/.libs/libitm.1.dylib FAIL: libitm.c/cancel.c execution test
[Bug driver/56062] Enhance -fuse-ld= option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062 --- Comment #3 from Dmitry Gorbachev 2013-01-24 14:58:58 UTC --- Yes, it is not a very important thing, but it should not be harder to maintain then -fuse-ld=bfd, -fuse-ld=gold options. It is not like I suggest to add something completely new, just to improve already existing feature.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #5 from Jakub Jelinek 2013-01-24 15:06:28 UTC --- So, the reason seems to be: mod = build2 (INIT_EXPR, TREE_TYPE (t), t, unshare_expr (val)); SET_EXPR_LOCATION (mod, EXPR_LOC_OR_HERE (val)); in: #0 internal_get_tmp_var (val=0x71aeaaa0, pre_p=0x7fffdda8, post_p=0x0, is_formal=true) at ../../gcc/gimplify.c:636 #1 0x00832a3e in get_formal_tmp_var (val=0x71aeaaa0, pre_p=0x7fffdda8) at ../../gcc/gimplify.c:657 #2 0x0084d3b7 in gimplify_expr (expr_p=0x7fffdcf8, pre_p=0x7fffdda8, post_p=0x7fffdbb0, gimple_test_f=0x80befc , fallback=1) at ../../gcc/gimplify.c:8023 #3 0x0084f7c8 in force_gimple_operand_1 (expr=0x71aeaaa0, stmts=0x7fffdda8, gimple_test_f=0x80befc , var=0x0) at ../../gcc/gimplify.c:8633 #4 0x0084f878 in force_gimple_operand_gsi_1 (gsi=0x7fffde60, expr=0x71aeaaa0, gimple_test_f=0x80befc , var=0x0, before=true, m=GSI_SAME_STMT) at ../../gcc/gimplify.c:8669 #5 0x0084f923 in force_gimple_operand_gsi (gsi=0x7fffde60, expr=0x71aeaaa0, simple_p=true, var=0x0, before=true, m=GSI_SAME_STMT) at ../../gcc/gimplify.c:8698 #6 0x00b79414 in rewrite_use_nonlinear_expr (data=0x7fffdf70, use=0x1887f90, cand=0x1887f40) at ../../gcc/tree-ssa-loop-ivopts.c:6151 #7 0x00b79df5 in rewrite_use (data=0x7fffdf70, use=0x1887f90, cand=0x1887f40) at ../../gcc/tree-ssa-loop-ivopts.c:6358 #8 0x00b79eb7 in rewrite_uses (data=0x7fffdf70) at ../../gcc/tree-ssa-loop-ivopts.c:6391 #9 0x00b7b0a0 in tree_ssa_iv_optimize_loop (data=0x7fffdf70, loop=0x7198bb28) at ../../gcc/tree-ssa-loop-ivopts.c:6716 During original gimplification, I can understand the OR_HERE (aka input_location) part there, or in passes that maintain input_location. But generally force_gimple_operand* is often called even from passes that don't maintain reasonable input_location. So, either the above should be hack like if (gimplify_ctxp->into_ssa) SET_EXPR_LOCATION (mod, EXPR_LOCATION (val)); else SET_EXPR_LOCATION (mod, EXPR_LOC_OR_HERE (val)); (or gimplify_ctxp->use_input_location or whatever), or perhaps force_gimple_operand* should temporarily set input_location to UNKNOWN_LOCATION and restore it back from a saved copy before returning.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #41 from Jack Howarth 2013-01-24 15:23:54 UTC --- Iain, I believe the current behavior of dyld in darwin10/11/12 is clearly described in... http://developer.apple.com/library/mac/#releasenotes/DeveloperTools/RN-dyld/_index.html Specifically in the section... Faster Weak-symbol Coalescing C++ uses weak definitions to solve a number of issues. But if weak symbols are not hidden, the dynamic loader needs to make them unique at runtime. The previous algorithm for doing that was expensive. For every weak symbol in each image, the dynamic loader would look up that symbol in every other image. In OS X v10.6 the algorithm is more efficient: It assumes that weak-symbol duplicates are rare. First, all symbols are bound by their normal two-level namespace binding. Then there is as a separate pass that takes an alphabetized list of weak symbols from each image and iterates through just those weak symbols looking for duplicates. The dynamic loader updates only the duplicates. The new LINKEDIT segment format is optimized for this algorithm. This issue seems to also be described in this thread on cfe-commits... http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059752.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059755.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059793.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059796.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059799.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059803.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059807.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059819.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120625/059825.html
[Bug driver/56062] Enhance -fuse-ld= option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062 --- Comment #4 from Jonathan Wakely 2013-01-24 15:34:28 UTC --- Since you haven't provided a use case or explained why you want it, and maintainers have said they don't want it, I think the onus is on your to justify it and/or provide a tested patch, not expect other people to do it just because you want it.
[Bug tree-optimization/55755] Invalid VIEW_CONVERT_EXPR produced by SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55755 --- Comment #5 from Martin Jambor 2013-01-24 15:41:19 UTC --- Author: jamborm Date: Thu Jan 24 15:41:04 2013 New Revision: 195429 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195429 Log: 2013-01-24 Martin Jambor Backport from mainline 2013-01-04 Martin Jambor PR tree-optimization/55755 * tree-sra.c (sra_modify_assign): Do not check that an access has no children when trying to avoid producing a VIEW_CONVERT_EXPR. testsuite/ * gcc.dg/torture/pr55755.c: New test. * gcc.dg/tree-ssa/sra-13.c: Likewise. * gcc.dg/tree-ssa/pr45144.c: Update. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr55755.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/sra-13.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr45144.c branches/gcc-4_6-branch/gcc/tree-sra.c
[Bug tree-optimization/55755] Invalid VIEW_CONVERT_EXPR produced by SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55755 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Martin Jambor 2013-01-24 15:52:56 UTC --- Finally fixed everywhere.
[Bug tree-optimization/55927] FAIL: g++.dg/ipa/devirt-10.C -std=gnu++11 scan-ipa-dump-times inline "Discovered a virtual call to a known target" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-01/msg01191.htm ||l Last reconfirmed||2013-01-24 Ever Confirmed|0 |1 --- Comment #6 from Martin Jambor 2013-01-24 16:10:37 UTC --- It turns out that just disabling early inlining is enough and does not make the testcase fail anywhere I tried (x86_64, ia64 and i686). So I posted a patch disabling it in the testcase and will commit it shortly: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01191.html It is true that indirect inlining on ia64 produces purely intra-procedural opportunities for type-based devirtualization which we do not do but should. That is a different problem though, let's hope it will be done in 4.9.
[Bug other/56057] libbacktrace STILL doesn't honor --disable-werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56057 lailavrazda1979 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from lailavrazda1979 at gmail dot com 2013-01-24 16:14:29 UTC --- Seems to be fixed now.
[Bug tree-optimization/55927] FAIL: g++.dg/ipa/devirt-10.C -std=gnu++11 scan-ipa-dump-times inline "Discovered a virtual call to a known target" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927 --- Comment #7 from Martin Jambor 2013-01-24 16:18:35 UTC --- Author: jamborm Date: Thu Jan 24 16:18:26 2013 New Revision: 195430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195430 Log: 2013-01-24 Martin Jambor PR tree-optimization/55927 * g++.dg/ipa/devirt-10.C: Disable early inlining. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ipa/devirt-10.C
[Bug tree-optimization/55927] FAIL: g++.dg/ipa/devirt-10.C -std=gnu++11 scan-ipa-dump-times inline "Discovered a virtual call to a known target" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Martin Jambor 2013-01-24 16:31:33 UTC --- Fixed.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #24 from David Edelsohn 2013-01-24 16:37:23 UTC --- It does not matter if the scheduler knows that insns 17, 20, 26 and 29 really are calls. The clobbers express everything important. insn 15 produces r3. insn 16 produces r4. insn 17 consumes r3, r4 and produces r3 and clobbers r4. insn 20 consumes r3. insn 23 produces r148. insn 24 produces r3. insn 25 consumes r148 and produces r4. insn 26 consumes r3, r4 and produces r3 and clobber r4. insn 29 consumes r3. And, yes, insn 23 can be moved before insn 17. It simply requires an additional, temporary hard register not clobbered by insn 17 that will be copied to r4 in insn 25. But I am pointing out that one can track that insn 26 depends on insn 25 and insn 25 depends on insn 23 through the dataflow graph. Again, nothing says that insn 23 cannot be hoisted above insn 17. The only instructions that clobber r65 (LR) are insns 17 and 26. I do not understand your comments or what information you think is missing or what is causing the ICE. It seems more that there is something wrong with the assert causing the ICE and/or some data structure not set / updated correctly in sel-sched.
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078 --- Comment #9 from Jakub Jelinek 2013-01-24 16:59:56 UTC --- Author: jakub Date: Thu Jan 24 16:59:44 2013 New Revision: 195432 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195432 Log: PR c/56078 * c-typeck.c (set_nonincremental_init_from_string): If constructor_max_index is NULL, treat it as if tree_int_cst_lt returned false. (process_init_element): Likewise. * gcc.dg/pr56078.c: New test. * gcc.c-torture/compile/20030305-1.c: Add dg-error lines. Added: trunk/gcc/testsuite/gcc.dg/pr56078.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/20030305-1.c
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #6 from Jakub Jelinek 2013-01-24
17:26:48 UTC ---
--- gimplify.c.jj2013-01-11 09:02:55.0 +0100
+++ gimplify.c2013-01-24 18:15:54.246157569 +0100
@@ -8600,6 +8600,7 @@ force_gimple_operand_1 (tree expr, gimpl
{
enum gimplify_status ret;
struct gimplify_ctx gctx;
+ location_t saved_location;
*stmts = NULL;
@@ -8613,6 +8614,8 @@ force_gimple_operand_1 (tree expr, gimpl
push_gimplify_context (&gctx);
gimplify_ctxp->into_ssa = gimple_in_ssa_p (cfun);
gimplify_ctxp->allow_rhs_cond_expr = true;
+ saved_location = input_location;
+ input_location = UNKNOWN_LOCATION;
if (var)
{
@@ -8634,6 +8637,7 @@ force_gimple_operand_1 (tree expr, gimpl
gcc_assert (ret != GS_ERROR);
}
+ input_location = saved_location;
pop_gimplify_context (NULL);
return expr;
seems to work (there are way too many uses of input_location in gimplify.c),
alternatively we could e.g. grab input_location temporarily just in
force_gimple_operand_gsi_1, depending on gimple_location of the stmt this
should be emitted before resp. after.
[Bug c++/55856] [4.7/4.8 Regression] ICE on tuple with rvalue ref member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55856 --- Comment #6 from simonb at gcc dot gnu.org 2013-01-24 18:10:44 UTC --- Author: simonb Date: Thu Jan 24 18:10:26 2013 New Revision: 195435 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195435 Log: svn merge -c 194864 svn+ssh://sim...@gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch 2013-01-03 Jason Merrill PR c++/55856 * semantics.c (build_data_member_initialization): Handle DECL_EXPR. Added: branches/google/gcc-4_7/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor11.C - copied unchanged from r194864, branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor11.C Modified: branches/google/gcc-4_7/gcc/cp/ChangeLog branches/google/gcc-4_7/gcc/cp/semantics.c
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #36 from ian at gcc dot gnu.org 2013-01-24 18:12:41 UTC --- Author: ian Date: Thu Jan 24 18:12:23 2013 New Revision: 195436 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195436 Log: PR go/46986 libgo/Makefile, libgo/go/os/stat_atimespec.go: fix typos Modified: trunk/libgo/Makefile.am trunk/libgo/Makefile.in trunk/libgo/go/os/stat_atimespec.go
[Bug c/56098] New: conditional write through volatile pointer produces unintended read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098
Bug #: 56098
Summary: conditional write through volatile pointer produces
unintended read
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wer...@almesberger.net
If compiled with -O2 or greater and without -fno-strict-aliasing, the following
code
volatile int *ptr;
void problem(int flag)
{
*ptr = 1;
if (flag)
*ptr = 2;
}
produces an unintended read, as if the "if" statement had continued with
else
*ptr = *ptr;
Code generated by gcc 4.7.2 on Ubuntu on x86-64 when invoked with
gcc-4.7 -Wall -Wextra -O2 -S bug.c
...
problem:
.LFB0:
.cfi_startproc
movqptr(%rip), %rax
testl %edi, %edi
movl$2, %edx
movl$1, (%rax)
jne .L2
movl(%rax), %edx<<< unexpected
.L2:
movl%edx, (%rax)
ret
.cfi_endproc
...
This happens with
- gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 for x86-64,
- gcc-4.7 (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 for x86-64,
- mipsel-openwrt-linux-gcc (Linaro GCC 4.6-2012.02) 4.6.3 20120201 (prerelease)
for MIPS,
and I've had someone confirm it for an ARM target (without further details) as
well.
-Os instead of -O2 has the same effect. The unintended read disappears if
optimizing with -O1 or less, or with -fno-strict-aliasing.
This bears a striking resemblance to Bug 15456 and maybe Bug 5395, except that
these were for C++ while this is plain C.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez 2013-01-24 18:29:44 UTC --- Don't we have a EXPR_LOC_OR_UNKNOWN? That seems far nicer than overriding a global variable and restoring it back afterwards without known what else may be touching it or relying on it.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #8 from rguenther at suse dot de
2013-01-24 18:37:30 UTC ---
"jakub at gcc dot gnu.org" wrote:
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
>
>--- Comment #6 from Jakub Jelinek 2013-01-24
>17:26:48 UTC ---
>--- gimplify.c.jj2013-01-11 09:02:55.0 +0100
>+++ gimplify.c2013-01-24 18:15:54.246157569 +0100
>@@ -8600,6 +8600,7 @@ force_gimple_operand_1 (tree expr, gimpl
> {
> enum gimplify_status ret;
> struct gimplify_ctx gctx;
>+ location_t saved_location;
>
> *stmts = NULL;
>
>@@ -8613,6 +8614,8 @@ force_gimple_operand_1 (tree expr, gimpl
> push_gimplify_context (&gctx);
> gimplify_ctxp->into_ssa = gimple_in_ssa_p (cfun);
> gimplify_ctxp->allow_rhs_cond_expr = true;
>+ saved_location = input_location;
>+ input_location = UNKNOWN_LOCATION;
>
> if (var)
> {
>@@ -8634,6 +8637,7 @@ force_gimple_operand_1 (tree expr, gimpl
> gcc_assert (ret != GS_ERROR);
> }
>
>+ input_location = saved_location;
> pop_gimplify_context (NULL);
>
> return expr;
>
>seems to work (there are way too many uses of input_location in
>gimplify.c),
Eh, I thought we arrived at this somewhere
Earlier this year... Ah, I suggested input_location should be unknown_location
Anyway here and we should arrange so and
Assert in force_simple_operand.
>alternatively we could e.g. grab input_location temporarily just in
>force_gimple_operand_gsi_1, depending on gimple_location of the stmt
>this
>should be emitted before resp. after.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #9 from Manuel López-Ibáñez 2013-01-24 18:39:18 UTC --- > During original gimplification, I can understand the OR_HERE (aka > input_location) part there, or in passes that maintain input_location. I thought gimplification happens after each whole function is read, how is input_location correct in that case? Moreover, how do optimization passes try to mantain input_location accurate? > force_gimple_operand* should temporarily set input_location to > UNKNOWN_LOCATION > and restore it back from a saved copy before returning. My fear is that this is basically delaying the inevitable, which is getting rid of input_location. At some moment, the saving/restoring of input_location in random points will start conflicting in unexpected ways and the whole thing will be unfixable without breaking something else.
[Bug c/56099] New: Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
Bug #: 56099
Summary: Empty static noinline functions aren't called from
optimized code
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com
The C testcase below, when compiled with gcc-4.7.1 with flag '-O2', doesn't
contain the noinline function at all. No body and no call.
gcc-4.2.1 did leave the body of such function, but also didn't have the call.
gcc should respect noinline attribute even on the empty functions and should
leave both body and call to it.
PS: I hit this while attempting to add the DTrace probes through adding of the
empty function. However, call to this function was never placed into code so
this technique doesn't work due to this bug.
---testcase---
__attribute__((noinline))
static int func_ni() {
return 1;
}
void func_exp() {
func_ni();
}
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c |tree-optimization
Resolution||INVALID
--- Comment #1 from Andrew Pinski 2013-01-24
18:45:19 UTC ---
You want:
__attribute__((noinline, noclone))
static int func_ni() {
asm("");
return 1;
}
CUT
So the function is not considered pure/const and does not get cloned either.
[Bug libstdc++/55041] prettyprinting/shared_ptr & cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 --- Comment #16 from Tom Tromey 2013-01-24 18:50:58 UTC --- (In reply to comment #12) > In my case the issue seems to be weird debuginfo emitted by gcc; > look at what the breakpoint reports: > > Breakpoint 1, _GLOBAL__sub_I__Z4makem () at > /home/tromey/Space/Trunk/Git/gcc/lib > stdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc:81 FWIW this problem doesn't appear with a more recent trunk gcc. I tried one from Jan 17 (c1f9696864b1b8ab20a6798751eec48986a2e98a) just now. Are there still unresolved problems in this bug?
[Bug c++/55951] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 --- Comment #1 from Paul Pluzhnikov 2013-01-24 18:54:47 UTC --- Re-confirmed with: g++ (GCC) 4.8.0 20130124 (experimental)
[Bug libstdc++/55041] prettyprinting/shared_ptr & cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 Benjamin Kosnik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #17 from Benjamin Kosnik 2013-01-24 18:54:51 UTC --- Thanks for the ping Tom. Confirmed: let's go ahead and close this.
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #2 from Yuri 2013-01-24 19:06:12 UTC --- Created attachment 29267 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29267 asm of the testcase showing there is still no noinline function I am trying 'noclone' with gcc-4.7.1 but there is still no func_ni in the resulting output: /opt/gcc/4.7.1/bin/gcc -O2 -S ni.c See ni.s attached
[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 Alexandre Oliva changed: What|Removed |Added Severity|major |normal --- Comment #4 from Alexandre Oliva 2013-01-24 19:11:20 UTC --- I guess the most elegant solution is to have the RTL prologue start with a NOTE_INSN_PROLOGUE_START, and output the before-prologue profiler-call during the final scan of that note, just like we output the after-prologue profiler call at the final scan of NOTE_INSN_PROLOGUE_END.
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #3 from Andrew Pinski 2013-01-24 19:11:33 UTC --- (In reply to comment #2) > Created attachment 29267 [details] > asm of the testcase showing there is still no noinline function You need the inline-asm also to force the const/pure detection from happening.
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #4 from Yuri 2013-01-24 19:16:10 UTC --- You are saying I also need to place some __asm__ into this noinline function? Doesn't this look like working around some bugs in gcc? User doesn't need to know how gcc is doing this inside, weather it is cloning something or treats it as pure or not. noinline means do-not-inline, no matter what is inside. I originally asked for a simple basic thing, and so many gcc guts got exposed by this.
[Bug fortran/55887] [OOP][F2008] ICE with CLASS and data-target pointer association in (default) initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 Tilo Schwarz changed: What|Removed |Added CC||t...@tilo-schwarz.de --- Comment #1 from Tilo Schwarz 2013-01-24 19:16:25 UTC --- I don't know how much help this actually is, but on my machine this commit commit a90fe8299d2e635e53ab006c934154289d06ffa1 Author: pault Date: Thu Dec 20 00:15:00 2012 + 2012-12-19 Paul Thomas git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@194622 138bc75d-0d04-0410-961f-82ee72b054a4 gives an ICE, but one commit earlier commit 873f242d97571e98acad8ea1912f81682bd7a448 Author: burnus Date: Wed Dec 19 23:05:49 2012 + 2012-12-19 Tobias Burnus git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@194621 138bc75d-0d04-0410-961f-82ee72b054a4 does not. Regards, Tilo
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #5 from Andrew Pinski 2013-01-24 19:22:43 UTC --- (In reply to comment #4) > You are saying I also need to place some __asm__ into this noinline function? > Doesn't this look like working around some bugs in gcc? User doesn't need to > know how gcc is doing this inside, weather it is cloning something or treats > it > as pure or not. noinline means do-not-inline, no matter what is inside. No it is not working around a bug in GCC. You wrote the function with no side effects so GCC decided to remove the call to the function as it has no side effects. The inline-asm causes GCC to see there are side effects in the function which are unknown to GCC and does nothing to it. > > I originally asked for a simple basic thing, and so many gcc guts got exposed > by this.
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #6 from Yuri 2013-01-24 19:24:43 UTC --- I think 'noinline' flag should be factored into the removal decision.
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #7 from Andrew Pinski 2013-01-24 19:28:59 UTC --- (In reply to comment #6) > I think 'noinline' flag should be factored into the removal decision. No because this is not about inlining. This is about side effects on the function and there is none.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #10 from rguenther at suse dot de 2013-01-24 19:30:54 UTC --- "manu at gcc dot gnu.org" wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 > >--- Comment #9 from Manuel López-Ibáñez >2013-01-24 18:39:18 UTC --- >> During original gimplification, I can understand the OR_HERE (aka >> input_location) part there, or in passes that maintain >input_location. > >I thought gimplification happens after each whole function is read, how >is >input_location correct in that case? Moreover, how do optimization >passes try >to mantain input_location accurate? Input_location should only be used from parsing. Other places reuse the variable and those happen to eventually pick up stale values, such as gimplification. We should Arrange for different globals to be used there and privatize input_location. In the meantime assert that input_location is unknown when Entering or leaving passes. > >> force_gimple_operand* should temporarily set input_location to >UNKNOWN_LOCATION >> and restore it back from a saved copy before returning. > >My fear is that this is basically delaying the inevitable, which is >getting rid >of input_location. At some moment, the saving/restoring of >input_location in >random points will start conflicting in unexpected ways and the whole >thing >will be unfixable without breaking something else.
[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066 --- Comment #1 from Solomon Gibbs 2013-01-24 19:42:15 UTC --- I'm looking at the objdump -x output for the c++ object and I note that there's a separate section for the inlined function. It appears to be annotated with a COMDAT field value of 4. According to skyfree.org/linux/references/coff.pdf a value of 4 corresponds to IMAGE_COMDAT_SELECT_EXACT_MATCH: "The linker chooses an arbitrary section among the definitions for this symbol. A multiply defined symbol error is issued if all definitions don’t match exactly." The C99 symbol has no COMDAT selection field.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #37 from ian at gcc dot gnu.org 2013-01-24 19:44:31 UTC --- Author: ian Date: Thu Jan 24 19:44:23 2013 New Revision: 195438 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195438 Log: PR go/46986 all: prepend #__USER_LABEL_PREFIX__ to mangled Go symbols For old-fashioned Darwin. Modified: trunk/libgo/go/bytes/indexbyte.c trunk/libgo/go/log/syslog/syslog_c.c trunk/libgo/go/sync/atomic/atomic.c trunk/libgo/go/sync/cas.c trunk/libgo/go/syscall/errno.c trunk/libgo/go/syscall/signame.c trunk/libgo/go/syscall/wait.c trunk/libgo/runtime/chan.c trunk/libgo/runtime/cpuprof.c trunk/libgo/runtime/env_posix.c trunk/libgo/runtime/go-breakpoint.c trunk/libgo/runtime/go-caller.c trunk/libgo/runtime/go-callers.c trunk/libgo/runtime/go-cgo.c trunk/libgo/runtime/go-fieldtrack.c trunk/libgo/runtime/go-getgoroot.c trunk/libgo/runtime/go-now.c trunk/libgo/runtime/go-reflect-map.c trunk/libgo/runtime/go-setenv.c trunk/libgo/runtime/go-signal.c trunk/libgo/runtime/go-typestring.c trunk/libgo/runtime/go-unsafe-new.c trunk/libgo/runtime/go-unsafe-newarray.c trunk/libgo/runtime/go-unsafe-pointer.c trunk/libgo/runtime/goc2c.c trunk/libgo/runtime/lfstack.c trunk/libgo/runtime/malloc.goc trunk/libgo/runtime/malloc.h trunk/libgo/runtime/mgc0.c trunk/libgo/runtime/mprof.goc trunk/libgo/runtime/panic.c trunk/libgo/runtime/parfor.c trunk/libgo/runtime/proc.c trunk/libgo/runtime/runtime.c trunk/libgo/runtime/runtime.h
[Bug debug/53927] wrong value for DW_AT_static_link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #1 from Tom Tromey 2013-01-24 20:24:18 UTC --- It seems that I read the wrong frame info in my original report. However, the bug still exists. Here is a new and hopefully more correct example showing the bug. I used a relatively recent git master gcc for this. I just followed the directions in the original report. The static link info for 'nested': DW_AT_static_link : 1 byte block: 50 (DW_OP_reg0 (rax)) In the 'nested' frame this is: (gdb) p/x $rax $1 = 0x7fffe370 In the outer 'nestee' frame: (gdb) p $pc $2 = (void (*)()) 0x4004e9 The frame info as shown by readelf --debug-dump=frames-interp: 0060 0024 0064 FDE cie= pc=00400486..004004fe LOC CFA rbx rbp ra 00400486 rsp+8u u c-8 00400487 rsp+16 u c-16 c-8 0040048a rbp+16 u c-16 c-8 0040048f rbp+16 c-24 c-16 c-8 <--- this row 004004fd rsp+8c-24 c-16 c-8 So the CFA we want is $rbp + 16 in the outermost 'nestee' frame: (gdb) p/x $rbp + 16 $3 = 0x7fffe3b0 ... but this is different from $1.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #11 from Manuel López-Ibáñez 2013-01-24 20:49:33 UTC --- (In reply to comment #10) > > Input_location should only be used from parsing. Other places reuse the > variable and those happen to eventually pick up stale values, such as > gimplification. We should > Arrange for different globals to be used there and privatize input_location. > In > the meantime assert that input_location is unknown when > Entering or leaving passes. > Perhaps I didn't make myself clear. What is calling internal_get_tmp_var that is relying on input_location to be pointing to a sensible location? Is it really called during parsing?
[Bug c++/56100] New: spurious -Wshadow warning with local variable in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100 Bug #: 56100 Summary: spurious -Wshadow warning with local variable in template class Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: f.heckenb...@fh-soft.de Created attachment 29268 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29268 Test case Compiling the test case with "-Wshadow" gives: shadow.cpp: In instantiation of 'void bar::baz() [with T = int]': shadow.cpp:4:17: required from 'void bar::qux() [with T = int]' shadow.cpp:13:21: required from here shadow.cpp:6:21: warning: declaration of 'foo' shadows a global declaration [-Wshadow] shadow.cpp:9:5: warning: shadowed declaration is here [-Wshadow] Observed with 4.4.6, 4.6.1 and 4.7.2. Note: "private" is not necessary to trigger the warning, it's just there to show it occurs even with "private". The warning seems strange because the supposedly shadowed variable is declared after the shadowing one. (I assume that's because of the processing done during instantiation.) It's annoying because it means that an identifier used in a template defined in some header, even in a local scope in a private method is "poisoned" when used anywhere else with -Wshadow.
[Bug c++/56100] spurious -Wshadow warning with local variable in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100 --- Comment #1 from Andrew Pinski 2013-01-24 21:14:51 UTC --- I think this is an artifact of warning during instantiation rather than at definition time.
[Bug c++/56100] spurious -Wshadow warning with local variable in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56100
--- Comment #2 from Frank Heckenbach 2013-01-24
21:25:09 UTC ---
I guess many warnings can only be given correctly during instantiation because
they depend on the actual arguments.
But shadowing is not one of them as the set of identifiers declared doesn't
depend on the arguments. (Even in the case of partial specializations, one
would expect the warning where the specialization is defined, not when it's
instantiated.)
So perhaps a simple fix is to turn off -Wshadow temporarily during
instantiation. After all, the instantiated code has no access to currently
declared global identifiers. This code fails as it should (AFAIK), unless foo
is declared before the template:
template
struct bar
{
int qux () { return foo; }
};
int foo;
int main ()
{
bar ().qux ();
}
[Bug libgomp/56073] SPEComp2012 376.kdtree fails to complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073 --- Comment #2 from Alan Modra 2013-01-24 21:52:04 UTC --- Author: amodra Date: Thu Jan 24 21:51:58 2013 New Revision: 195444 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195444 Log: PR libgomp/51376 PR libgomp/56073 * task.c (GOMP_task): Revert 2011-12-09 change. (GOMP_taskwait): Likewise. Instead use atomic load with acquire barrier to read task->children.. (gomp_barrier_handle_tasks): ..and matching atomic store with release barrier here when setting parent->children to NULL. Added: branches/ibm/gcc-4_7-branch/libgomp/ChangeLog.ibm Modified: branches/ibm/gcc-4_7-branch/libgomp/task.c
[Bug libgomp/51376] libgomp taskwait failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51376 --- Comment #5 from Alan Modra 2013-01-24 21:52:03 UTC --- Author: amodra Date: Thu Jan 24 21:51:58 2013 New Revision: 195444 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195444 Log: PR libgomp/51376 PR libgomp/56073 * task.c (GOMP_task): Revert 2011-12-09 change. (GOMP_taskwait): Likewise. Instead use atomic load with acquire barrier to read task->children.. (gomp_barrier_handle_tasks): ..and matching atomic store with release barrier here when setting parent->children to NULL. Added: branches/ibm/gcc-4_7-branch/libgomp/ChangeLog.ibm Modified: branches/ibm/gcc-4_7-branch/libgomp/task.c
[Bug libgcc/56101] New: pthread program abort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56101 Bug #: 56101 Summary: pthread program abort Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcc AssignedTo: unassig...@gcc.gnu.org ReportedBy: ry...@synopsys.com Created attachment 29269 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29269 The preprocessed file -Compiler informations: g++ -v Using built-in specs. COLLECT_GCC=/remote/depotsrc/depotsrc/amd64-2.6/local_install/gcc-4.7.2_test2/bin/g++ COLLECT_LTO_WRAPPER=/remote/depotsrc/depotsrc/amd64-2.6/local_install/gcc-4.7.2_test2/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../../src/gcc-4.7.2/configure --prefix=/remote/depotsrc/depotsrc/amd64-2.6/local_install/gcc-4.7.2_test2 --enable-bootstrap --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran --disable-libgcj --with-cpu=generic --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 (GCC) - Command line triggers the bug: ryang@sderh7 test2> mtest Abort - compiler outout: /remote/depotsrc/depotsrc/amd64-2.6/local_install/gcc-4.7.2_test2/bin/g++ -I. -Wall -Wextra -fno-strict-aliasing -fwrapv -m64 -c -msse2 -mfpmath=sse -fno-omit-frame-pointer -fno-dollars-in-identifiers -save-temps -pthread -o tmain.o tmain.C /remote/depotsrc/depotsrc/amd64-2.6/local_install/gcc-4.7.2_test2/bin/g++ -static-libgcc -static-libstdc++ -o mtest tmain.o -pthread -lm -ldl - the preprocessed file (*.i*) see the attachment
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 --- Comment #10 from janus at gcc dot gnu.org 2013-01-24 23:58:18 UTC --- Author: janus Date: Thu Jan 24 23:58:12 2013 New Revision: 195447 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195447 Log: 2013-01-24 Janus Weil PR fortran/56081 * resolve.c (resolve_select): Add argument 'select_type', reject non-scalar expressions. (resolve_select_type,resolve_code): Pass new argument to 'resolve_select'. 2013-01-24 Janus Weil PR fortran/56081 * gfortran.dg/select_8.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/select_8.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/56081] [4.7/4.8 Regression] Seg fault ICE on select with bad case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from janus at gcc dot gnu.org 2013-01-24 23:59:27 UTC --- Fixed on trunk and 4.7. Closing. Thanks for the report!
[Bug testsuite/55994] multiple definition or memset or strlen for builtins tests with LTO options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 --- Comment #6 from Janis Johnson 2013-01-25 00:26:43 UTC --- Author: janis Date: Fri Jan 25 00:26:34 2013 New Revision: 195458 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195458 Log: Backport from mainline 2013-01-16 Janis Johnson PR testsuite/55994 * gcc.c-torture/execute/builtins/builtins.exp: Add -Wl,--allow-multiple-definition for eabi and elf targets. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
[Bug target/56102] New: Wrong rtx cost calculated for Thumb1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102
Bug #: 56102
Summary: Wrong rtx cost calculated for Thumb1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com
For below program:
double g = 1.0;
double func(int a, double d)
{
if (a > 0)
return 0.0 + g;
else
return 2.0 + d;
}
compiling with:
./arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os test.c -S -o test.S
The assembly code is:
.cpu cortex-m0
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 4
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.code16
.file"main.c"
.global__aeabi_dadd
.text
.align1
.globalfunc
.code16
.thumb_func
.typefunc, %function
func:
push{r3, lr}
cmpr0, #0
ble.L2
ldrr3, .L6+16
ldrr0, [r3]
ldrr1, [r3, #4]
ldrr3, .L6+4
ldrr2, .L6
b.L4
.L2:
movr0, r2
movr1, r3
ldrr2, .L6+8
ldrr3, .L6+12
.L4:
bl__aeabi_dadd
@ sp needed
pop{r3, pc}
.L7:
.align3
.L6:
.word0
.word0
.word0
.word1073741824
.word.LANCHOR0
.sizefunc, .-func
.globalg
.data
.align3
.set.LANCHOR0,. + 0
.typeg, %object
.sizeg, 8
g:
.word0
.word1072693248
.ident"GCC: (GNU) 4.8.0 20130122 (experimental)"
The problem is double word constant isn't split by GCC, causing bigger code
size.
[Bug target/56102] Wrong rtx cost calculated for Thumb1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102 --- Comment #1 from bin.cheng 2013-01-25 03:46:59 UTC --- I have investigated this issue. GCC uses function init_lower_subreg to initialize costs of MOVE insn with different mode, then uses this information to decompose multi-word pseudo registers into individual registers. The problem is ARM backend returns wrong rtx cost for SET insn with multi-word mode. Specifically, if you define LOG_COSTS in lower-subreg.c, GCC will dump rtx costs when compiling with: arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os/-O2 The dump is: Size costs == SI move: from zero cost 4, from reg cost 4 DI move: original cost 4, split cost 4 * 2 TI move: original cost 4, split cost 4 * 4 EI move: original cost 4, split cost 4 * 6 OI move: original cost 4, split cost 4 * 8 CI move: original cost 4, split cost 4 * 12 XI move: original cost 4, split cost 4 * 16 DQ move: original cost 4, split cost 4 * 2 TQ move: original cost 4, split cost 4 * 4 UDQ move: original cost 4, split cost 4 * 2 UTQ move: original cost 4, split cost 4 * 4 DA move: original cost 4, split cost 4 * 2 TA move: original cost 4, split cost 4 * 4 UDA move: original cost 4, split cost 4 * 2 UTA move: original cost 4, split cost 4 * 4 DF move: original cost 4, split cost 4 * 2 XF move: original cost 4, split cost 4 * 3 DD move: original cost 4, split cost 4 * 2 TD move: original cost 4, split cost 4 * 4 CSI move: original cost 4, split cost 4 * 2 CDI move: original cost 4, split cost 4 * 4 CTI move: original cost 4, split cost 4 * 8 CEI move: original cost 4, split cost 4 * 12 COI move: original cost 4, split cost 4 * 16 CCI move: original cost 4, split cost 4 * 24 CXI move: original cost 4, split cost 4 * 32 SC move: original cost 4, split cost 4 * 2 DC move: original cost 4, split cost 4 * 4 XC move: original cost 4, split cost 4 * 6 V8QI move: original cost 4, split cost 4 * 2 V4HI move: original cost 4, split cost 4 * 2 V2SI move: original cost 4, split cost 4 * 2 V16QI move: original cost 4, split cost 4 * 4 V8HI move: original cost 4, split cost 4 * 4 V4SI move: original cost 4, split cost 4 * 4 V2DI move: original cost 4, split cost 4 * 4 V4HF move: original cost 4, split cost 4 * 2 V2SF move: original cost 4, split cost 4 * 2 V8HF move: original cost 4, split cost 4 * 4 V4SF move: original cost 4, split cost 4 * 4 V2DF move: original cost 4, split cost 4 * 4 Speed costs === SI move: from zero cost 4, from reg cost 4 DI move: original cost 4, split cost 4 * 2 TI move: original cost 4, split cost 4 * 4 EI move: original cost 4, split cost 4 * 6 OI move: original cost 4, split cost 4 * 8 CI move: original cost 4, split cost 4 * 12 XI move: original cost 4, split cost 4 * 16 DQ move: original cost 4, split cost 4 * 2 TQ move: original cost 4, split cost 4 * 4 UDQ move: original cost 4, split cost 4 * 2 UTQ move: original cost 4, split cost 4 * 4 DA move: original cost 4, split cost 4 * 2 TA move: original cost 4, split cost 4 * 4 UDA move: original cost 4, split cost 4 * 2 UTA move: original cost 4, split cost 4 * 4 DF move: original cost 4, split cost 4 * 2 XF move: original cost 4, split cost 4 * 3 DD move: original cost 4, split cost 4 * 2 TD move: original cost 4, split cost 4 * 4 CSI move: original cost 4, split cost 4 * 2 CDI move: original cost 4, split cost 4 * 4 CTI move: original cost 4, split cost 4 * 8 CEI move: original cost 4, split cost 4 * 12 COI move: original cost 4, split cost 4 * 16 CCI move: original cost 4, split cost 4 * 24 CXI move: original cost 4, split cost 4 * 32 SC move: original cost 4, split cost 4 * 2 DC move: original cost 4, split cost 4 * 4 XC move: original cost 4, split cost 4 * 6 V8QI move: original cost 4, split cost 4 * 2 V4HI move: original cost 4, split cost 4 * 2 V2SI move: original cost 4, split cost 4 * 2 V16QI move: original cost 4, split cost 4 * 4 V8HI move: original cost 4, split cost 4 * 4 V4SI move: original cost 4, split cost 4 * 4 V2DI move: original cost 4, split cost 4 * 4 V4HF move: original cost 4, split cost 4 * 2 V2SF move: original cost 4, split cost 4 * 2 V8HF move: original cost 4, split cost 4 * 4 V4SF move: original cost 4, split cost 4 * 4 V2DF move: original cost 4, split cost 4 * 4 The original MOVE insn with multi-word mode has lower costs then split insns, thus preventing gcc from splitting. Root cause is that thumb1_rtx_costs/thumb1_size_rtx_costs does not handle SET/ASHIFT/ASHIFTRT/LSHIFTRT/ROTATERT patterns with multi-word mode, as rtx_cost does. I am working on this and will send a patch.
[Bug target/56102] Wrong rtx cost calculated for Thumb1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102 --- Comment #2 from bin.cheng 2013-01-25 07:25:34 UTC --- Created attachment 29270 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29270 correct test case The previous test case is not appropriate, because gcc won't split even with correct thumb1_rtx_cost. Here attaches the right test case.
