[Bug target/56199] New: strcpy/strcat builtins generates suboptimal code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56199 Bug #: 56199 Summary: strcpy/strcat builtins generates suboptimal code. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: nel...@seznam.cz Current strcpy/strcat generates code in form movabsq $7954893459765158241, %r11 movq %r11,(%rax) ... Which is slower than copying string from memory using movq (%rdx),%r11 movq %r11,(%rax) ... Attached benchmark is 50% faster on sandy bridge for 70 byte string. Note that icc also translates strcpy into this form(but not strcat for some reason.)
[Bug target/56199] strcpy/strcat builtins generates suboptimal code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56199 --- Comment #1 from Ondrej Bilka neleai at seznam dot cz 2013-02-04 08:42:32 UTC --- Created attachment 29344 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29344 benchmark
[Bug rtl-optimization/56175] Issue with combine phase on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175 --- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-02-04 08:55:12 UTC --- Created attachment 29345 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29345 real test-case Need to be compiled with proposed options.
[Bug ada/56178] [4.8 Regression] Conversion of Long_Float to Integer triggers CONSTRAINT_ERROR overflow check failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56178 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 09:15:49 UTC --- bisected to ada/urealp.o, if this comes from -fprofile-use build, even if all other ada/*.o come from stage1, it still fails, if ada/urealp.o is from stage1, even if all other ada/*.o come from -fprofile-use build, it works fine. Not familiar enough with Ada to know where to look at though.
[Bug middle-end/56113] out of memory when compiling a function with many goto labels (50k )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 09:30:19 UTC --- Author: rguenth Date: Mon Feb 4 09:30:12 2013 New Revision: 195707 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195707 Log: 2013-02-04 Richard Biener rguent...@suse.de PR tree-optimization/56113 * tree-ssa-structalias.c (equiv_class_lookup, equiv_class_add): Merge into ... (equiv_class_lookup_or_add): ... this. (label_visit): Adjust and fix error in previous patch. (perform_var_substitution): Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug target/56199] strcpy/strcat builtins for constant strings generates suboptimal code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56199 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 09:39:31 UTC --- It should be faster if the string is not in the cache. Which of course it is for your testcase (because you have an artificial loop here). So the benchmark does not show that the transform is bad but instead it shows that if repeatedly initializing sth from the same (large) constants then it's profitable to use a smaller instruction encoding. But of course that's again likely only true when 'cpy' is not inlined - in which case we cannot distinguish the cases. Highly suspicious testing method in the end.
[Bug tree-optimization/56195] [4.8 Regression] Error: incorrect register `%rdi' used with `l' suffix (at -O2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56195 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-04 Ever Confirmed|0 |1
[Bug testsuite/56194] FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56194 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-04 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 09:41:58 UTC --- Or rather made be more specific in some way ...
[Bug c++/56192] global operator new() vs member operator new()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56192 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-04 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 09:43:14 UTC --- Confirmed.
[Bug testsuite/56194] FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56194 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 2013-02-04 09:46:49 UTC --- Or if not easily possible, just disable the dg-final test on targets where it won't work. xfail is wrong here, there is no error that is expected, due to the fn descriptor it might simply be not (easily) testable on that target.
[Bug middle-end/56188] [4.8 regression] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { (ESCAPED )?(NONLOCAL )?}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56188 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-04 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 09:49:15 UTC --- Mine. Any know revision this worked properly?
[Bug target/56186] [4.8 regression] function return ABI change for 128-bit types on Win64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56186 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Keywords||ABI Last reconfirmed||2013-02-04 Ever Confirmed|0 |1 Target Milestone|--- |4.8.0
[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-02-04 Target Milestone|--- |4.7.3 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 09:56:12 UTC --- The exception happens inside a library (ppl I suppose?). I cannot reproduce this on x86_64-linux with GCC 4.6, nor with GCC 4.7 (both using PPL 0.11.2 but cloog 0.15.10 as from the GCC infrastructure). So I suppose the issue might be related to the cloog version used. You mark the bug as a regression - please fill out at least one known-to-work version and the library versions used for bootstrapping it.
[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|Internal compiler error in |[4.8 Regression] Internal |push_reload during |compiler error in |bootstrap stage 2 |push_reload during ||bootstrap stage 2
[Bug bootstrap/56182] [4.6 Regression] gcc/config/i386/t-linux64:29: recipe commences before first target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56182 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-pc-linux-gnu Priority|P3 |P1 Known to work||4.6.3 Target Milestone|--- |4.6.4 Known to fail||4.6.4 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 10:00:24 UTC --- Matthias - did you properly test your patches on the branches (I seriously think they were not appropriate there). P1.
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking Priority|P3 |P1
[Bug c++/56179] ERROR: Internal error: Killed (program cc1plus)recevied while installing gnuradio.git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 10:03:07 UTC --- Note also that GCC 4.5.x is no longer supported. GCC 4.6.3 is the oldest still supported release.
[Bug ada/56178] [4.8 Regression] Conversion of Long_Float to Integer triggers CONSTRAINT_ERROR overflow check failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56178 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/56177] [4.8 Regression] ICE when used forward for 'auto f();'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56177 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-04 Known to work||4.7.2 Target Milestone|--- |4.8.0 Summary|ICE when used forward for |[4.8 Regression] ICE when |'auto f();' |used forward for 'auto ||f();' Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 10:05:28 UTC --- Confirmed. With 4.7: t.C:2:8: error: 'f' function uses 'auto' type specifier without trailing return type t.C:3:8: error: 'f' function uses 'auto' type specifier without trailing return type t.C: In function 'int main()': t.C:5:23: error: 'f' was not declared in this scope
[Bug tree-optimization/56175] Issue with combine phase on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-04 Component|rtl-optimization|tree-optimization Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 10:10:31 UTC --- This should be fixed on the GIMPLE level by simplify_bitwise_binary. That is, (A C) ^ (B C) - (A ^ B) C for all code combinations and C's that this is valid for. fold doesn't seem to have this complex pattern.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #48 from Alexander Potapenko glider at google dot com 2013-02-04 10:11:32 UTC --- (In reply to comment #40) if (ctor_recA-position ctor_recB-position) return -1; if (ctor_recA-position ctor_recB-position) return 1; This is wrong. I think we want this reversed as well. We want original order. A testcase with two ctors, should in the end have the one with the lower original position first. So, for me to approve it, I need to know if sorting just inside 1 translation unit is enough to make -fsanitize=address work. I fear the answer to that is no, and without cross translation unit support, this is just bug pushing (obscuring a bug with a non-fix that just makes fixing it even harder). I won't approve it if it is bug pushing. If cross has to work, then cross shared libraries I suspect has to work as well. In LLVM this is done without cross-TU: we just emit a call to __asan_init per TU and append it to the list of global constructors for the current module (note that the constructors' priorities on Darwin do not work across modules at all: http://llvm.org/bugs/show_bug.cgi?id=12556
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #49 from Alexander Potapenko glider at google dot com 2013-02-04 10:13:49 UTC --- I agree with Jakub: it's better to return back to the qsort version of the patch, since it fixes ASan as well, but also provides better support for priorities in general.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #31 from Rainer Orth ro at gcc dot gnu.org 2013-02-04 10:16:18 UTC --- The patch seems to have broken many testcases on platforms like Solaris 9 with Sun as that lack visibility support: FAIL: g++.dg/abi/covariant2.C -std=c++98 (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/abi/covariant2.C:31:20: warning : visibility attribute not supported in this configuration; ignored [-Wattribute s] /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/abi/covariant2.C:31:20: warning : visibility attribute not supported in this configuration; ignored [-Wattribute s] Rainer
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 10:22:36 UTC --- (In reply to comment #31) The patch seems to have broken many testcases on platforms like Solaris 9 with Sun as that lack visibility support: FAIL: g++.dg/abi/covariant2.C -std=c++98 (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/abi/covariant2.C:31:20: warning : visibility attribute not supported in this configuration; ignored [-Wattribute s] /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/abi/covariant2.C:31:20: warning : visibility attribute not supported in this configuration; ignored [-Wattribute s] That's very weird, because build_vtable marks the vtable decl as DECL_ARTIFICIAL and thus it shouldn't be warned about. Or is it some other decl that copies the visibility from the construction vtable decl?
[Bug c++/56177] [4.8 Regression] ICE when used forward for 'auto f();'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56177 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 10:25:07 UTC --- Started (not unexpectedly) with the C++1y return type deduction changes: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185768
[Bug c++/56177] [4.8 Regression] ICE when used forward for 'auto f();'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56177
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04
10:26:52 UTC ---
auto f ();
auto f () { return 33; }
is enough to reproduce it, ICEs also with -std=c++1y.
[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||gnu.org
--- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-02-04
10:34:25 UTC ---
Patch to help explain the problem:
Index: optabs.c
===
--- optabs.c(revision 195687)
+++ optabs.c(working copy)
@@ -1452,8 +1452,13 @@ expand_binop_directly (enum machine_mode
{
/* If PAT is composed of more than one insn, try to add an appropriate
REG_EQUAL note to it. If we can't because TEMP conflicts with an
-operand, call expand_binop again, this time without a target. */
+operand, call expand_binop again, this time without a target.
+
+However, if target is a MEM, just accept the lossage of not having
+a REG_EQUAL note. This avoids splitting up insns of the form
+MEM=MEM op X, a form we may not be able to reconstruct later. */
if (INSN_P (pat) NEXT_INSN (pat) != NULL_RTX
+ ! (target MEM_P (target))
! add_equal_note (pat, ops[0].value, optab_to_code (binoptab),
ops[1].value, ops[2].value))
{
I agree that we should try to do something like that. Generating inferior code
to be able to add a REG_EQUAL that doesn't help in the end isn't very clever.
There is also the same pattern in expand_unop_direct.
Is that the maximal test that can be added to catch this case or could it be
made more precise?
[Bug target/56200] New: queens benchmark is faster with -O0 than with any other optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200 Bug #: 56200 Summary: queens benchmark is faster with -O0 than with any other optimization level Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: a...@gcc.gnu.org CC: amona...@gcc.gnu.org Target: x86_64-unknown-linux-gnu Created attachment 29346 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29346 queens benchmark While preparing some teaching slides I have noticed that the queens benchmark from Aburto generates slower code with -O1/O2/O3 than with plain -O0. I've removed all timing routines from the attached file, compile and run it with ./a.out 30. For 4.7.1 of OpenSUSE 12.2, we have: $ time ./o0 30 /dev/null user0m10.017s $ time ./o1 30 /dev/null user0m11.824s $ time ./o2 30 /dev/null user0m10.388s $ time ./o3 30 /dev/null //this one is with -march=native user0m11.065s For today's 4.8, $ time ./o048 30 /dev/null user0m9.780s $ time ./o148 30 /dev/null user0m12.590s $ time ./o248 30 /dev/null //this one is with -march=native user0m10.487s $ time ./o348 30 /dev/null //this one is with -march=native user0m10.850s Perf shows that in the -O1 versions of above we have the new lea that has a lot of counter hits and lots more of branch mispredictions.
[Bug ada/56178] [4.8 Regression] Conversion of Long_Float to Integer triggers CONSTRAINT_ERROR overflow check failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56178 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ebotcazou at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-02-04 10:42:15 UTC --- Thanks for the analysis, Jakub, I'll take it from there.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 10:44:19 UTC --- Created attachment 29347 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29347 gcc48-pr54314.patch Ah, I see, solaris and mingw/cygwin have their own assemble_visibility target hooks that warn on their own, so need the same adjustment as the default hook.
[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-02-04
11:15:15 UTC ---
You could use a wrapper function to guarantee order of evaluation. The one here
seems a bit too complex:
http://stackoverflow.com/questions/14058592/how-to-guarantee-order-of-argument-evaluation-when-calling-a-function-object
Or you could build a gcc plugin that adds a wrapper around each function call
in order to evaluate arguments left-to-right.
GCC should definitely warn about this, isn't there a bug open?
Another testcase is:
void f(int, int);
void test() {
int i = 0;
int v[1] = {0};
f(v[i], i++); // warn
}
This one doesn't involve function calls in the arguments.
[Bug middle-end/56188] [4.8 regression] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { (ESCAPED )?(NONLOCAL )?}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56188 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 11:58:50 UTC --- ok, the difference is that in the working case we have Equivalence classes for Direct node node id 28:_10 are pointer: 11, location:0 Equivalence classes for Direct node node id 34:derefaddrtmp are pointer: 18, location:0 while in the non-working case Equivalence classes for Direct node node id 28:_10 are pointer: 18, location:0 Equivalence classes for Direct node node id 34:derefaddrtmp are pointer: 18, location:0 Bisecting points to rev. 195646. I have a fix.
[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04
12:03:52 UTC ---
Well, we already have peephole2s for MEM op= ARG (the TARGET_READ_MODIFY_WRITE
guarded peephole2s), the reason why it doesn't trigger in this case is that ARG
in this case ends up being a MEM, and
MEM op= MEM2 isn't a valid insn:
(insn 95 94 96 11 (set (reg:SI 3 bx [orig:135 D.1801 ] [135])
(mem:SI (reg/f:SI 4 si [orig:86 D.1803 ] [86]) [2 *_41+0 S4 A32]))
pr56151.c:32 89 {*movsi_internal}
(nil))
(insn 96 95 97 11 (parallel [
(set (reg:SI 3 bx [orig:135 D.1801 ] [135])
(ior:SI (reg:SI 3 bx [orig:135 D.1801 ] [135])
(mem:SI (plus:SI (mult:SI (reg:SI 6 bp [orig:132 D.1801 ]
[132])
(const_int 4 [0x4]))
(symbol_ref:SI (setmask) var_decl
0x7f587927a390 setmask)) [2 setmask S4 A32])))
(clobber (reg:CC 17 flags))
]) pr56151.c:32 421 {*iorsi_1}
(expr_list:REG_DEAD (reg:SI 6 bp [orig:132 D.1801 ] [132])
(nil)))
(insn 97 96 98 11 (set (mem:SI (reg/f:SI 4 si [orig:86 D.1803 ] [86]) [2 *_41+0
S4 A32])
(reg:SI 3 bx [orig:135 D.1801 ] [135])) pr56151.c:32 89
{*movsi_internal}
(expr_list:REG_DEAD (reg:SI 3 bx [orig:135 D.1801 ] [135])
(expr_list:REG_DEAD (reg/f:SI 4 si [orig:86 D.1803 ] [86])
(nil
I guess for temp = MEM; temp op= MEM2; MEM = temp; for temp dead afterwards
(this case), we could as well just add another set of the (up to 3?)
peephole2's, that would transform that into
temp = MEM2;
MEM op= temp;
instead.
[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:04:41 UTC --- Author: rguenth Date: Mon Feb 4 12:04:35 2013 New Revision: 195708 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195708 Log: 2013-02-04 Richard Biener rguent...@suse.de Backport from mainline 2012-07-04 Richard Guenther rguent...@suse.de PR tree-optimization/53844 * tree-ssa-dse.c (dse_possible_dead_store_p): Properly handle the loop virtual PHI. * g++.dg/tree-ssa/pr53844.C: New testcase. 2012-12-13 Richard Biener rguent...@suse.de PR lto/55660 * tree-streamer.c (record_common_node): Check that we are not recursively pre-loading nodes we want to skip. Handle char_type_node appearing as part of va_list_type_node. * gcc.dg/lto/pr55660_0.c: New testcase. * gcc.dg/lto/pr55660_1.c: Likewise. 2013-02-04 Richard Biener rguent...@suse.de PR middle-end/55890 * gimple.h (gimple_call_builtin_class_p): New function. * gimple.c (validate_call): New function. (gimple_call_builtin_class_p): Likewise. * tree-ssa-structalias.c (find_func_aliases_for_builtin_call): Use gimple_call_builtin_class_p. (find_func_clobbers): Likewise. * tree-ssa-strlen.c (adjust_last_stmt): Likewise. (strlen_optimize_stmt): Likewise. * gcc.dg/torture/pr55890-1.c: New testcase. * gcc.dg/torture/pr55890-2.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/tree-ssa/pr53844.C branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/lto/pr55660_0.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/lto/pr55660_1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-2.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gimple.c branches/gcc-4_7-branch/gcc/gimple.h branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-dse.c branches/gcc-4_7-branch/gcc/tree-ssa-strlen.c branches/gcc-4_7-branch/gcc/tree-ssa-structalias.c branches/gcc-4_7-branch/gcc/tree-streamer.c
[Bug middle-end/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:04:42 UTC --- Author: rguenth Date: Mon Feb 4 12:04:35 2013 New Revision: 195708 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195708 Log: 2013-02-04 Richard Biener rguent...@suse.de Backport from mainline 2012-07-04 Richard Guenther rguent...@suse.de PR tree-optimization/53844 * tree-ssa-dse.c (dse_possible_dead_store_p): Properly handle the loop virtual PHI. * g++.dg/tree-ssa/pr53844.C: New testcase. 2012-12-13 Richard Biener rguent...@suse.de PR lto/55660 * tree-streamer.c (record_common_node): Check that we are not recursively pre-loading nodes we want to skip. Handle char_type_node appearing as part of va_list_type_node. * gcc.dg/lto/pr55660_0.c: New testcase. * gcc.dg/lto/pr55660_1.c: Likewise. 2013-02-04 Richard Biener rguent...@suse.de PR middle-end/55890 * gimple.h (gimple_call_builtin_class_p): New function. * gimple.c (validate_call): New function. (gimple_call_builtin_class_p): Likewise. * tree-ssa-structalias.c (find_func_aliases_for_builtin_call): Use gimple_call_builtin_class_p. (find_func_clobbers): Likewise. * tree-ssa-strlen.c (adjust_last_stmt): Likewise. (strlen_optimize_stmt): Likewise. * gcc.dg/torture/pr55890-1.c: New testcase. * gcc.dg/torture/pr55890-2.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/tree-ssa/pr53844.C branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/lto/pr55660_0.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/lto/pr55660_1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-2.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gimple.c branches/gcc-4_7-branch/gcc/gimple.h branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-dse.c branches/gcc-4_7-branch/gcc/tree-ssa-strlen.c branches/gcc-4_7-branch/gcc/tree-ssa-structalias.c branches/gcc-4_7-branch/gcc/tree-streamer.c
[Bug lto/55660] [4.7 Regression] ICE instead of some warning during lto build with supplied different options (-funsigned-char vs none)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55660 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:04:43 UTC --- Author: rguenth Date: Mon Feb 4 12:04:35 2013 New Revision: 195708 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195708 Log: 2013-02-04 Richard Biener rguent...@suse.de Backport from mainline 2012-07-04 Richard Guenther rguent...@suse.de PR tree-optimization/53844 * tree-ssa-dse.c (dse_possible_dead_store_p): Properly handle the loop virtual PHI. * g++.dg/tree-ssa/pr53844.C: New testcase. 2012-12-13 Richard Biener rguent...@suse.de PR lto/55660 * tree-streamer.c (record_common_node): Check that we are not recursively pre-loading nodes we want to skip. Handle char_type_node appearing as part of va_list_type_node. * gcc.dg/lto/pr55660_0.c: New testcase. * gcc.dg/lto/pr55660_1.c: Likewise. 2013-02-04 Richard Biener rguent...@suse.de PR middle-end/55890 * gimple.h (gimple_call_builtin_class_p): New function. * gimple.c (validate_call): New function. (gimple_call_builtin_class_p): Likewise. * tree-ssa-structalias.c (find_func_aliases_for_builtin_call): Use gimple_call_builtin_class_p. (find_func_clobbers): Likewise. * tree-ssa-strlen.c (adjust_last_stmt): Likewise. (strlen_optimize_stmt): Likewise. * gcc.dg/torture/pr55890-1.c: New testcase. * gcc.dg/torture/pr55890-2.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/tree-ssa/pr53844.C branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/lto/pr55660_0.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/lto/pr55660_1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-2.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gimple.c branches/gcc-4_7-branch/gcc/gimple.h branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-dse.c branches/gcc-4_7-branch/gcc/tree-ssa-strlen.c branches/gcc-4_7-branch/gcc/tree-ssa-structalias.c branches/gcc-4_7-branch/gcc/tree-streamer.c
[Bug middle-end/53844] [4.6 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53844 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.3 Resolution||FIXED Target Milestone|4.6.4 |4.7.3 Summary|[4.6/4.7 Regression] GCC|[4.6 Regression] GCC |generates suboptimal code |generates suboptimal code |for unused members of |for unused members of |classes in some cases on|classes in some cases on |multiple targets. |multiple targets. --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:06:13 UTC --- And 4.7.3. Not considering to backport further, thus, FIXED.
[Bug lto/55660] [4.7 Regression] ICE instead of some warning during lto build with supplied different options (-funsigned-char vs none)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55660 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.3 Resolution||FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:06:46 UTC --- Fixed.
[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:08:17 UTC --- Initial patch now backported, avoiding the C++ function overloading by using gimple_call_builtin_class_p.
[Bug fortran/56201] New: Realloc on assignment: Wrong code when assigning a zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56201 Bug #: 56201 Summary: Realloc on assignment: Wrong code when assigning a zero-sized array Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org Reported by Vladimír Fuka at https://groups.google.com/d/topic/comp.lang.fortran/Qhrw1XU7U8o/discussion Assigning a zero-sized array to an *unallocated* allocatable works; re-assigning to a zero-sized array works as well. But: Assigning a zero-sized array to an allocated non-zero-size array wrongly deallocates the array. real, allocatable :: r(:) r = [real :: ] ! Zero-sized array print *, allocated(r) ! OK: Allocated print *, size(r) if (.not.allocated(r) .or. size(r) /= 0) call abort() r = [real :: ] ! Zero-sized array print *, allocated(r) ! OK: Allocated print *, size(r) deallocate(r) ! REALLOCATE to nonzero sized allocate(r(5)) ! r = [real :: ] ! Zero-sized array print *, allocated(r) ! ERROR: Not allocated print *, size(r) if (.not.allocated(r) .or. size(r) /= 0) call abort() end
[Bug lto/56168] [4.8 Regression] GCC seems to disregard -fno-builtin when compiling with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56168 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:19:34 UTC --- Author: rguenth Date: Mon Feb 4 12:19:25 2013 New Revision: 195709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195709 Log: 2013-02-04 Richard Guenther rguent...@suse.de PR lto/56168 * lto-symtab.c (lto_symtab_merge_decls_1): Make non-builtin node prevail as last resort. (lto_symtab_merge_decls): Remove guard on LTRANS here. (lto_symtab_prevailing_decl): Builtins are their own prevailing decl. lto/ * lto.c (read_cgraph_and_symbols): Do not call lto_symtab_merge_decls or lto_fixup_decls at LTRANS time. * gcc.dg/lto/pr56168_0.c: New testcase. * gcc.dg/lto/pr56168_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/pr56168_0.c trunk/gcc/testsuite/gcc.dg/lto/pr56168_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-symtab.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog
[Bug lto/56168] [4.8 Regression] GCC seems to disregard -fno-builtin when compiling with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56168 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 12:20:06 UTC --- Fixed.
[Bug go/56172] net FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56172 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-04 13:00:59 UTC --- Thanks for the analysis. Since you can recreate the bug, I guess the next step is to check the mp-waitsema field in the runtime_semawakeup frame. My prediction is that it is 0. But I'm not sure where to go from there since I don't see how it could be 0. In my case, mp-waitsema is 8. In case you want to have a look yourself (which will be way faster), you can find the build in apoc:/var/gcc/regression/trunk/11-gcc-gas/build/sparc-sun-solaris2.11/libgo/net-check/test. Rainer
[Bug libstdc++/56202] New: SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 Bug #: 56202 Summary: SIGFPE (division by zero) in std::binomial_distribution Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: adam.ciga...@gmail.com Created attachment 29348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29348 minimal program to expose the bug in std::binomial_distribution Hello, When I explicitly enable floating point exceptions in my code, the program crashes on SIGFPE inside the std::binomial_distribution. The program works fine when fp exceptions are not enabled, however, I want them enabled during development, to help me track errors in my code. I'm attaching minimal program to reproduce the crash. Compile and run it with: g++ -std=c++11 -Wall -Wextra -g -o scratch scratch.cpp ./scratch This is the output of gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|sparc-linux |sparc-*-* CC||ro at gcc dot gnu.org --- Comment #7 from Rainer Orth ro at gcc dot gnu.org 2013-02-04 13:08:35 UTC --- Same on 32-bit Solaris/SPARC only, 64-bit is fine. Rainer
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #10 from Rainer Orth ro at gcc dot gnu.org 2013-02-04 13:10:56 UTC --- On 32-bit sparc-sun-solaris2.* at -O2 and -O3.
[Bug fortran/56203] New: gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203 Bug #: 56203 Summary: gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: sparc*-*-solaris2.* Target: sparc*-*-solaris2.* Build: sparc*-*-solaris2.* I often see the gfortran.dg/minlocval_3.f90 test time out on slower SPARC machines (like 1.2 GHz UltraSPARC-T2) at -O3. On an otherwise idle machine, compilation takes real2:25.18 user2:16.64 sys1.28 which is already half the default timeout. If the machine becomes loaded, this easily gets above the limit. Maybe the testcase can be stripped down a bit or split to avoid this. Rainer
[Bug middle-end/56188] [4.8 regression] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { (ESCAPED )?(NONLOCAL )?}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56188 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 13:31:35 UTC --- Author: rguenth Date: Mon Feb 4 13:31:28 2013 New Revision: 195713 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195713 Log: 2013-02-04 Richard Biener rguent...@suse.de PR tree-optimization/56188 * tree-ssa-structalias.c (label_visit): Consider case with initially non-empty points-to set. (perform_var_substitution): Dump node mapping and clean up. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug fortran/56204] New: [4.8 regression] gfortran.dg/quad_[23].f90 FAIL on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56204 Bug #: 56204 Summary: [4.8 regression] gfortran.dg/quad_[23].f90 FAIL on Solaris 9/x86 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.9 Target: i386-pc-solaris2.9 Build: i386-pc-solaris2.9 Since about 20121205, the quad_[23].f90 execution tests started to FAIL on Solaris 9/x86: FAIL: gfortran.dg/quad_2.f90 -O0 execution test FAIL: gfortran.dg/quad_2.f90 -O1 execution test FAIL: gfortran.dg/quad_2.f90 -O2 execution test FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/quad_2.f90 -O3 -g execution test FAIL: gfortran.dg/quad_2.f90 -Os execution test FAIL: gfortran.dg/quad_3.f90 -O0 execution test FAIL: gfortran.dg/quad_3.f90 -O1 execution test FAIL: gfortran.dg/quad_3.f90 -O2 execution test FAIL: gfortran.dg/quad_3.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/quad_3.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/quad_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/quad_3.f90 -O3 -g execution test FAIL: gfortran.dg/quad_3.f90 -Os execution test It aborts here: Program received signal SIGABRT, Aborted. 0xb5b23b96 in _libc_kill () from /usr/lib/libc.so.1 (gdb) where #0 0xb5b23b96 in _libc_kill () from /usr/lib/libc.so.1 #1 0xb5ad7dbe in raise () from /usr/lib/libc.so.1 #2 0xb5ac03fe in abort () from /usr/lib/libc.so.1 #3 0xb5c54714 in _gfortrani_sys_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:173 #4 0xb5d0f3b8 in _gfortran_abort () at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33 #5 0x080511b2 in test_qp () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/quad_2.f90:34 #6 0x08051662 in main (argc=1, argv=0x8047a28) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/quad_2.f90:78 #7 0x08050a1d in _start () The test is l.34: 34 if (fp2 /= fp4) call abort() but unfortunately gdb 7.5 can read neither variable. (gdb) p fp2 $1 = error reading variable (gdb) p fp4 $2 = error reading variable The quad_2.f90 is a regression from 4.7, the quad_3.f90 test wasn't present there. Rainer
[Bug middle-end/56188] [4.8 regression] FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { (ESCAPED )?(NONLOCAL )?}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56188 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 13:32:11 UTC --- Fixed.
[Bug target/56186] [4.8 regression] function return ABI change for 128-bit types on Win64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56186 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 13:44:21 UTC --- It doesn't matter at which -O* levels it fails on what targets, the code uses uninitialized fields and therefore it is pretty much random when it fails and when it succeeds. Worse yet is that this makes regression testing harder, because this test behaves like the completely random mudflap tests.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-04 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-02-04 14:07:31 UTC --- confirmed Program received signal SIGFPE, Arithmetic exception. 0x00401e49 in std::binomial_distributionint::_M_waitingstd::linear_congruential_engineunsigned long, 16807ul, 0ul, 2147483647ul ( this=0x7fffe3f0, __urng=..., __t=2) at /home/redi/gcc/4.x/include/c++/4.8.0/bits/random.tcc:1661 1661__sum += __e / (__t - __x); (gdb) p __t $1 = 2 (gdb) p __x $2 = 2
[Bug target/38134] [4.6/4.7/4.8 Regression] speed regression with many loop invariants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 14:47:31 UTC --- Ok, the goal would be to have all !targetm.legitimate_constant_p () constants assigned to a pseudo (and in GIMPLE to an SSA name). One piece of code that defeats that purpose is replace_uses_in called from tree CCP for example. But in this case already fold () does it's job and expands all static const initializers inline. Of course that then suggests to move initial constant pool creation to the gimple level instead.
[Bug target/56199] strcpy/strcat builtins for constant strings generates suboptimal code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56199 --- Comment #3 from Ondrej Bilka neleai at seznam dot cz 2013-02-04 15:15:12 UTC --- Created attachment 29349 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29349 icatche stressing benchmark
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #8 from vries at gcc dot gnu.org 2013-02-04 15:18:50 UTC --- Mikael, I tested this on x86_64-linux and sparc64-linux. On x86_64 there were no test suite changes, Thanks for testing this patch. Was the run on x86_64 a bootstrap-and-test? If not, I'll start one now. Thanks, - Tom
[Bug target/56199] strcpy/strcat builtins for constant strings generates suboptimal code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56199 Ondrej Bilka neleai at seznam dot cz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #4 from Ondrej Bilka neleai at seznam dot cz 2013-02-04 15:19:22 UTC --- It should be faster if the string is not in the cache. Which of course it is for your testcase (because you have an artificial loop here). And also expected case because you did expansion. It should be on hot path and string will be in case. Otherwise not doing expansion at all is faster. As you mentioned cache behaviour it includes also instruction cache. And current implementation is quite hostile to instruction cache (see another benchmark). Cases where So the benchmark does not show that the transform is bad but instead it shows that if repeatedly initializing sth from the same (large) constants then it's profitable to use a smaller instruction encoding. One property of benchmark is minimality. I could write benchmark strcpy called at five places with different strings and more complex control flow if that is your point. But of course that's again likely only true when 'cpy' is not inlined - in which case we cannot distinguish the cases. Please explain. And for strings larger that 128 bytes you inline repne strcpy variant that is slower than calling strcpy.
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se 2013-02-04 15:39:09 UTC --- (In reply to comment #8) Mikael, I tested this on x86_64-linux and sparc64-linux. On x86_64 there were no test suite changes, Thanks for testing this patch. Was the run on x86_64 a bootstrap-and-test? If not, I'll start one now. Both of them were full bootstrap-and-test runs.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-02-04
15:46:39 UTC ---
Hum, this seems to be the second waiting method described in page 41 of
http://luc.devroye.org/chapter_ten.pdf
which specifically says that sum can be infinite. So I think it should be
enough to check that __t == __x and return __x in that case.
do
{
const double __e = -std::log(1.0 - __aurng());
if(__t == __x) return __x;
__sum += __e / (__t - __x);
__x += 1;
}
while (__sum = _M_param._M_q);
No?
[Bug tree-optimization/44061] [4.6/4.7 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44061 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 15:49:29 UTC --- Author: rguenth Date: Mon Feb 4 15:49:18 2013 New Revision: 195718 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195718 Log: 2013-02-04 Richard Biener rguent...@suse.de Backport from mainline 2012-01-11 Richard Guenther rguent...@suse.de PR tree-optimization/44061 * tree-vrp.c (extract_range_basic): Compute zero as value-range for __builtin_constant_p of function parameters. * gcc.dg/pr44061.c: New testcase. 2013-01-08 Jakub Jelinek ja...@redhat.com PR middle-end/55890 * tree-ssa-ccp.c (evaluate_stmt): Use gimple_call_builtin_class_p. * gcc.dg/torture/pr55890-3.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr44061.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-3.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-ccp.c branches/gcc-4_7-branch/gcc/tree-vrp.c
[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 15:49:29 UTC --- Author: rguenth Date: Mon Feb 4 15:49:18 2013 New Revision: 195718 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195718 Log: 2013-02-04 Richard Biener rguent...@suse.de Backport from mainline 2012-01-11 Richard Guenther rguent...@suse.de PR tree-optimization/44061 * tree-vrp.c (extract_range_basic): Compute zero as value-range for __builtin_constant_p of function parameters. * gcc.dg/pr44061.c: New testcase. 2013-01-08 Jakub Jelinek ja...@redhat.com PR middle-end/55890 * tree-ssa-ccp.c (evaluate_stmt): Use gimple_call_builtin_class_p. * gcc.dg/torture/pr55890-3.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr44061.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55890-3.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-ccp.c branches/gcc-4_7-branch/gcc/tree-vrp.c
[Bug tree-optimization/44061] [4.6 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44061 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.3 Resolution||FIXED Target Milestone|4.6.4 |4.7.3 Summary|[4.6/4.7 Regression] Warns |[4.6 Regression] Warns |about out-of-bounds array |about out-of-bounds array |access inside |access inside |__builtin_constant_p|__builtin_constant_p |guarded section |guarded section --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 15:50:21 UTC --- And 4.7. Not backporting further.
[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.3 Resolution||FIXED --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-02-04 15:50:53 UTC --- Fixed. The calls.c hunk doesn't apply anywhere and did not come with a testcase.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-04 15:55:43 UTC --- Indeed, what Manuel suggested seems right to me. Let me handle this.
[Bug testsuite/56194] FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56194 --- Comment #3 from dave.anglin at bell dot net 2013-02-04 16:03:08 UTC --- One thought I had is to add the -fpic option. This should push the function descriptor into .data.
[Bug target/47333] [4.6, 4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6 regression]|[4.6, 4.8 regression] |g++.dg/lto/20091219 FAILs |g++.dg/lto/20091219 FAILs |on Solaris 2 with SUN as|on Solaris 2 with SUN as --- Comment #28 from Rainer Orth ro at gcc dot gnu.org 2013-02-04 16:06:37 UTC --- Still failing on trunk.
[Bug tree-optimization/56205] New: [4.8 Regression] stdarg pass confused by jump threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56205
Bug #: 56205
Summary: [4.8 Regression] stdarg pass confused by jump
threading
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
#include stdarg.h
int a, b;
char c[128];
static void
foo (int x, char const *y, va_list z)
{
__builtin_printf (%s %d %s, x ? : foo, ++a, (y *y) ? bar : );
if (y *y)
__builtin_vprintf (y, z);
}
void
bar (int x, char const *y, ...)
{
va_list z;
va_start (z, y);
if (!x *c == '\0')
++b;
foo (x, y, z);
va_end (z);
}
at -O3 (distilled from MariaDB testcase framework) fails on ppc64, only
floating point registers are saved, but not GPRs needed for varargs.
bar: va_list escapes 0, needs to save 0 GPR units and all FPR units.
from stdarg pass is wrong, va_list escapes in this case.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-04 16:21:54 UTC --- Note: I think we want also to consider the possibility that __e is zero at the same time and in that case simply discard the iteration completely.
[Bug target/56186] [4.8 regression] function return ABI change for 128-bit types on Win64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56186 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-04 16:37:51 UTC --- Author: ktietz Date: Mon Feb 4 16:37:44 2013 New Revision: 195721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195721 Log: PR target/56186 * config/i386/i386.c (function_value_ms_64): Add additional valtype argument and improve checking of return-argument types for 16-byte modes. (ix86_function_value_1): Add additional valtype argument on call of function_value_64. (return_in_memory_ms_64): Sync 16-byte sized mode handling with handling infunction_value_64 function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/56186] [4.8 regression] function return ABI change for 128-bit types on Win64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56186 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-04 16:39:48 UTC --- Fixed.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-02-04 17:11:15 UTC --- Author: paolo Date: Mon Feb 4 17:10:59 2013 New Revision: 195722 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195722 Log: 2013-02-04 Manuel López-Ibáñez m...@gcc.gnu.org Paolo Carlini paolo.carl...@oracle.com PR libstdc++/56202 * include/bits/random.tcc (binomial_distribution:: _M_waiting(_UniformRandomNumberGenerator, _IntType)): Avoid division by zero. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-04 17:11:38 UTC --- Fixed.
[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 17:13:52 UTC --- Created attachment 29350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29350 gcc48-pr56151.patch Untested patch for the peephole mentioned in previous comment.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 17:20:05 UTC --- Author: jakub Date: Mon Feb 4 17:19:56 2013 New Revision: 195723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195723 Log: PR libstdc++/54314 * config/i386/winnt.c (i386_pe_assemble_visibility): Don't warn about visibility on artificial decls. * config/sol2.c (solaris_assemble_visibility): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt.c trunk/gcc/config/sol2.c
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #50 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-04 17:24:40 UTC --- (In reply to comment #49) I agree with Jakub: it's better to return back to the qsort version of the patch, since it fixes ASan as well, but also provides better support for priorities in general. Posted final qsort version of the patch to gcc-patches. http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00120.html
[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 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #8 from Alexander Monakov amonakov at gcc dot gnu.org 2013-02-04 17:25:05 UTC --- The difference in behaviour is due to this change in sched_analyze_insn, inside if (reg_pending_barrier): + /* Flush pending lists on jumps, but not on speculative checks. */ + if (JUMP_P (insn) !(sel_sched_p () + sel_insn_is_speculation_check (insn))) flush_pending_lists (deps, insn, true, true); The JUMP_P (insn) part in the condition seems to be an unintended change.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-02-04 17:29:41 UTC --- I don't understand the check for __e. If you continue, then neither __t nor __x change, the only difference is that you sample a new __e. But __e doesn't have any effect in the value of __x, so if(__t == __x), then __x is always returned, no matter the value of __e. I maybe missing something, so take my words with suspicion.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
--- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-02-04
17:35:00 UTC ---
I would understand something like:
const double __e = -std::log(1.0 - __aurng());
if (__t == __x)
{
return __x;
}
else if (__e) continue;
__sum += __e / (__t - __x);
__x += 1;
}
but the possibility that __e is zero is so small that the time wasted in the
test doesn't compensate for the micro-optimization of skipping one iteration.
Also, can't we use unlikely() here like if (unlikely(_t == __x))?
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code, patch --- Comment #10 from vries at gcc dot gnu.org 2013-02-04 17:35:13 UTC --- submitted patch: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00122.html
[Bug testsuite/56206] New: [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56206 Bug #: 56206 Summary: [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Running the test suite from recent gcc-4.7 snapshots on armv5tel-linux-gnueabi shows the following new test suite failures: ERROR: gcc.target/arm/aapcs/neon-vect1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect2.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect2.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect3.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect3.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect4.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect4.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect5.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect5.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect6.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect6.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect7.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect7.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect8.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect8.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp10.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp10.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp11.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp11.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp12.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp12.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp13.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp13.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp14.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp14.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR:
[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151 --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2013-02-04 17:59:22 UTC --- (In reply to comment #7) Created attachment 29350 [details] gcc48-pr56151.patch Untested patch for the peephole mentioned in previous comment. I don't think a new set of peepholes is an appropriate solution for this problem, because the same issue can show up on any CISC-like target. Before my patch, the code was good after 'expand' by optabs, perhaps the code your peephole tries to create, can be emitted from there instead. And perhaps, longer term, combine should be changed to try the more profitable combination before the one it performs now.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-04 18:01:52 UTC --- You are right, but then I don't understand why we should compute __e *before* checking __t == __x, per your first patch (I think I managed to confuse myself exactly when I started wondering why...). Also __t == __x doesn't seem *so* unlikely to me to warrant a __builtin_expect (we have very few of in general, in the library). I think we could simply have: if (__t == __x) return __x; const double __e = -std::log(1.0 - __aurng()); __sum += __e / (__t - __x); __x += 1;
[Bug testsuite/56207] New: 'make check-mpc' fails to build tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56207 Bug #: 56207 Summary: 'make check-mpc' fails to build tests Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: si...@pushface.org This is with r195682, on Mac OS X 12.2.1. I have the SVN source tree in $source, and I have GMP 5.1.0, MPFR 3.1.1, and MPC 1.0.1 symlinked to $source/gmp, mpfr and mpc respectively. Having built the compiler in $build (a parallel directory), make check-gmp and make check-mpfr run successfully. However, make check-mpc fails to build with /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -no-install -o tabs tabs.o libmpc-tests.la ../src/libmpc.la -lmpfr -lgmp libtool: link: warning: `-no-install' is ignored for x86_64-apple-darwin12 libtool: link: warning: assuming `-no-fast-install' instead libtool: link: gcc -g -O2 -o tabs tabs.o ./.libs/libmpc-tests.a ../src/.libs/libmpc.a -lmpfr /Users/simon/tmp/gcc-build-195682-patched/./gmp/.libs/libgmp.a ld: library not found for -lmpfr If I cd $build/mpc/test and make check, it runs successfully. I believe that the problem is that the LDFLAGS set in $build/mpc/test/Makefile is being overridden.
[Bug testsuite/56206] [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56206 --- Comment #1 from Janis Johnson janis at gcc dot gnu.org 2013-02-04 18:07:12 UTC --- Author: janis Date: Mon Feb 4 18:07:06 2013 New Revision: 195725 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195725 Log: PR testsuite/56206 * lib/target-supports.exp (check_effective_target_arm_hard_vfp_ok): Fix typo. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/lib/target-supports.exp
[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-04 18:20:09 UTC --- (In reply to comment #8) (In reply to comment #7) Created attachment 29350 [details] gcc48-pr56151.patch Untested patch for the peephole mentioned in previous comment. I don't think a new set of peepholes is an appropriate solution for this problem, because the same issue can show up on any CISC-like target. Before my patch, the code was good after 'expand' by optabs, perhaps the code your peephole tries to create, can be emitted from there instead. And perhaps, longer term, combine should be changed to try the more profitable combination before the one it performs now. My patch wasn't meant as a replacement of the optabs.c change, but as a complement. As the sequence into which it attempts to peephole is shorter and supposedly faster on some CPUs at least, if such an insn sequence appears in the IL anywhere during RTL optimizations, it can optimize it.
[Bug bootstrap/56182] [4.6 Regression] gcc/config/i386/t-linux64:29: recipe commences before first target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56182 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||vapier at gentoo dot org --- Comment #4 from Matthias Klose doko at gcc dot gnu.org 2013-02-04 18:28:59 UTC --- back from travelling. yes, I did check that before checking in, builds from the branch, and builds as a package. $ md5sum gcc/config/i386/t-linux64 7d88364e4013e7259e8e856b0d778c24 gcc/config/i386/t-linux64 this shows me that line 39 ends with a backslash. this doesn't seem to be a build from the fsf branch, but a gentoo build: Unpacked to /mnt/md3/cache/portage/sys-devel/gcc-4.6.4_pre/work/gcc-4.6.4- [32;01m*[0m updating multilib directories to be: ../lib64 ../lib32 [32;01m*[0m Running elibtoolize in: gcc-4.6.4-/ [32;01m*[0m Applying portage/2.2 patch ... [32;01m*[0m Applying sed/1.5.6 patch ... [32;01m*[0m Applying as-needed/2.2.6 patch ... and updating multilib directories looks suspicious.
[Bug testsuite/56206] [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56206 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-02-04 18:33:05 UTC --- Thanks, my test machine is busy currently but I'll check this on Wednesday.
[Bug fortran/54107] [4.8 Regression] [F03] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 --- Comment #32 from Mikael Morin mikael at gcc dot gnu.org 2013-02-04 18:34:41 UTC --- Author: mikael Date: Mon Feb 4 18:34:30 2013 New Revision: 195729 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195729 Log: fortran/ PR fortran/54107 PR fortran/54195 * gfortran.h (struct gfc_symbol): New field 'resolved'. * resolve.c (resolve_fl_var_and_proc): Don't skip result symbols. (resolve_symbol): Skip duplicate calls. Don't check the current namespace. testsuite/ PR fortran/54107 * gfortran.dg/recursive_interface_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_interface_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: is already present in the interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #16 from Mikael Morin mikael at gcc dot gnu.org 2013-02-04 18:34:42 UTC --- Author: mikael Date: Mon Feb 4 18:34:30 2013 New Revision: 195729 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195729 Log: fortran/ PR fortran/54107 PR fortran/54195 * gfortran.h (struct gfc_symbol): New field 'resolved'. * resolve.c (resolve_fl_var_and_proc): Don't skip result symbols. (resolve_symbol): Skip duplicate calls. Don't check the current namespace. testsuite/ PR fortran/54107 * gfortran.dg/recursive_interface_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_interface_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/56182] [4.6 Regression] gcc/config/i386/t-linux64:29: recipe commences before first target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56182 wbrana wbrana at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from wbrana wbrana at gmail dot com 2013-02-04 18:50:24 UTC --- It seems Gentoo build is modifying t-linux64. Change in GCC broke Gentoo build.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-02-04 18:58:18 UTC --- (In reply to comment #9) You are right, but then I don't understand why we should compute __e *before* checking __t == __x, per your first patch (I think I managed to confuse myself Indeed.
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-02-04 19:00:22 UTC --- (In reply to comment #10) (In reply to comment #9) You are right, but then I don't understand why we should compute __e *before* checking __t == __x, per your first patch (I think I managed to confuse myself Indeed. Actually, the way I quoted the paragraph is unfortunate. I just want to say, that you are right and we should compute __e *before* checking __t == __x. I didn't realise this earlier and that probably helped to confuse things.
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: is already present in the interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #17 from Mikael Morin mikael at gcc dot gnu.org 2013-02-04 19:06:15 UTC --- Author: mikael Date: Mon Feb 4 19:06:06 2013 New Revision: 195730 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195730 Log: fortran/ PR fortran/54195 * resolve.c (resolve_typebound_procedures): Recurse through resolve_symbol. testsuite/ PR fortran/54195 * gfortran.dg/typebound_operator_19.f90: New test. * gfortran.dg/typebound_assignment_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/typebound_assignment_4.f90 trunk/gcc/testsuite/gfortran.dg/typebound_operator_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-04
19:23:38 UTC ---
Ok, thanks Manuel. Let's go with this follow up then, mainline only. If nothing
bad is reported may be suited for the branch too:
Index: include/bits/random.h
===
--- include/bits/random.h(revision 195721)
+++ include/bits/random.h(working copy)
@@ -3770,7 +3770,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @brief A discrete binomial random number distribution.
*
* The formula for the binomial probability density function is
- * @f$p(i|t,p) = \binom{n}{i} p^i (1 - p)^{t - i}@f$ where @f$t@f$
+ * @f$p(i|t,p) = \binom{t}{i} p^i (1 - p)^{t - i}@f$ where @f$t@f$
* and @f$p@f$ are the parameters of the distribution.
*/
templatetypename _IntType = int
Index: include/bits/random.tcc
===
--- include/bits/random.tcc(revision 195722)
+++ include/bits/random.tcc(working copy)
@@ -1657,13 +1657,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
do
{
+if (__t == __x)
+ return __x;
const double __e = -std::log(1.0 - __aurng());
-if (__t == __x)
- {
-if (__e)
- return __x;
-continue;
- }
__sum += __e / (__t - __x);
__x += 1;
}
[Bug libstdc++/56202] SIGFPE (division by zero) in std::binomial_distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56202 --- Comment #13 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-02-04 19:28:47 UTC --- Author: paolo Date: Mon Feb 4 19:28:40 2013 New Revision: 195732 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195732 Log: 2013-02-04 Manuel López-Ibáñez m...@gcc.gnu.org Paolo Carlini paolo.carl...@oracle.com PR libstdc++/56202 (again) * include/bits/random.tcc (binomial_distribution:: _M_waiting(_UniformRandomNumberGenerator, _IntType)): Fix thinko in previous commit. * include/bits/random.h: Fix comment typo. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc
[Bug c++/56208] New: sizeof sfinae fails to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208
Bug #: 56208
Summary: sizeof sfinae fails to work
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following program becomes rejected when compiled with gcc 4.8.0 trunk using
the flags:
-Wall -pedantic
(with or without -std=c++11)
//
struct ostream {
ostream operator(int);
};
struct sfinae_base {
typedef char one;
typedef char (two)[2];
templateclass T
static T make();
templateunsigned struct ok { typedef int type; };
templateclass U, class T
static one test(typename oksizeof(
makeU() makeT()
)::type);
templateclass, class
static two test(...);
};
templateclass T
struct is_printable : private sfinae_base
{
enum { value = sizeof(testostream, T(0)) == sizeof(one) };
};
typedef int ok[is_printableint::value ? 1 : -1];
int main() {}
//
Compilation finished with errors:
source.cpp:31:49: error: size of array 'ok' is negative
typedef int ok[is_printableint::value ? 1 : -1];
^
It worked with gcc 4.7.2 (also with Clang 3.2 or Intel-13), so this looks like
a regression to me. Operator is not the only one, I also noted problems with
other operators (such as binary plus).
[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148 --- Comment #4 from Sérgio Basto sergio at serjux dot com 2013-02-04 19:46:55 UTC --- Created attachment 29351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29351 the questionable code hi, send in attach the code , (that in think) that is in discussion. To see if we can fix it , to avoid this compile error .
[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 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #43 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2013-02-04 19:51:13 UTC --- So, I think we're at the point where the patch from #37 is the right way forward. If people agree, I'll approve that.
[Bug c++/56208] sizeof sfinae fails to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-02-04 19:54:47 UTC --- I just notice that the problem is not restricted to sizeof sfinae. In fact if we define the first test overload as follows: templateclass U, class T static one test(decltype( (makeU() makeT()), 0 )); the same regression problem occurs. I'm confused.
[Bug c++/56208] sizeof sfinae fails to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56208 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-02-04 19:57:18 UTC --- The actually tested gcc version was 4.8.0 20130127 (experimental)
