[Bug tree-optimization/55016] New: request for specific builtins for rcp and rsqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55016
Bug #: 55016
Summary: request for specific builtins for rcp and rsqrt
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
There are cases where the use of approximate rcp and rsqrt suffice.
I wonder if it would be possible to introduce specific generic builtins for
rcp and rsqrt that produce the proper instruction depending on the target
architecture (see,avx etc) and eventually generate vector instruction in a loop
at the moment anything like this is target specific, inefficient and does not
vectorize!
#include x86intrin.h
float v0[1024];
float v1[1024];
inline
float rsqrtf( float x ) {
return _mm_cvtss_f32( _mm_rsqrt_ss( _mm_set_ss( x ) ) );
}
void v() {
for(int i=0; i!=1024; ++i)
v0[i] = rsqrtf(v1[i]);
}
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-22 07:27:28 UTC --- Author: ebotcazou Date: Mon Oct 22 07:27:21 2012 New Revision: 192666 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192666 Log: PR bootstrap/54820 * Makefile.tpl (STAGE1_FLAGS_TO_PASS): New variable. (all-[+prefix+][+module+]): Pass stage1_args to sub-makes. (all-stage[+id+]-[+prefix+][+module+]): Likewise, if prev is false. (clean-stage[+id+]-[+prefix+][+module+]): Likewise, if prev is false. (host_modules): Set stage1_args to STAGE1_FLAGS_TO_PASS. * Makefile.in: Regenerate. * configure.ac (have_static_libs): New variable and associated check. (stage1-ldflags): Move to after stage1_libs and set to -static-libstdc++ -static-libgcc if stage1_libs is empty and have_static_libs is yes. * configure: Regenerate. ada/ * gcc-interface/Make-lang.in (GCC_LINK): Remove hardcoded options. Modified: trunk/ChangeLog trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Make-lang.in
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-22 07:41:22 UTC --- Patch applied.
[Bug c++/55017] New: [C++11] Rvalue-reference member should cause copy constructor not deleted, but still declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55017
Bug #: 55017
Summary: [C++11] Rvalue-reference member should cause copy
constructor not deleted, but still declared
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
Using gcc 4.8.0 20121014 (experimental) with the compiler flags
-Wall -pedantic -std=c++11
the following code is incorrectly accepted:
//--
struct S {
int rr;
S(int rr) : rr(static_castint(rr)) {}
};
S s1(13);
S s2 = s1; // Should be rejected
//--
This code should be rejected, because a non-static rvalue-reference member
causes the copy-constructor to be deleted as of 12.8 p11 b5. (Note: Even though
12.8 is currently under investigation bei CWG, there are no intentions to
change this part of the wording)
[Bug c++/55017] [C++11] Rvalue-reference member should cause copy constructor to be deleted, but still declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55017 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-22 Summary|[C++11] Rvalue-reference|[C++11] Rvalue-reference |member should cause copy|member should cause copy |constructor not deleted,|constructor to be deleted, |but still declared |but still declared Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-22 08:28:26 UTC --- Confirmed, not a regression
[Bug tree-optimization/55018] New: CDDCE phase is too aggressive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 Bug #: 55018 Summary: CDDCE phase is too aggressive Classification: Unclassified Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: nmo...@kalray.eu Created attachment 28502 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28502 Source code to reproduce the bug When compiling the attached source file with gcc -O3 tmp.c -c All the code from Sender_Signal function is removed during cddce2 phase. The generated code only contains an empty infinite loop which is wrong. Seen on: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)
[Bug tree-optimization/55018] CDDCE phase is too aggressive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Version|tree-ssa|4.7.2 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-22 08:39:24 UTC --- So it is removing an empty infinite loop? Are you saying that is wrong?
[Bug tree-optimization/55018] CDDCE phase is too aggressive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 --- Comment #2 from Nicolas Morey-Chaisemartin nmorey at kalray dot eu 2012-10-22 08:41:12 UTC --- The loop is infinite but should not be empty as it calls printf in the middle.
[Bug rtl-optimization/54991] [LRA] internal compiler error: in lra_assign, at lra-assigns.c:1361
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54991 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-10-22 08:43:07 UTC --- verified with several full CP2K builds as fixed.
[Bug tree-optimization/55018] CDDCE pass is too aggressive sometimes with infinite loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|CDDCE phase is too |CDDCE pass is too |aggressive |aggressive sometimes with ||infinite loops --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-22 08:43:22 UTC --- Or rather it is removing code from an infinite loop.
[Bug tree-optimization/55018] CDDCE pass is too aggressive sometimes with infinite loops and with some builtin functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|CDDCE pass is too |CDDCE pass is too |aggressive sometimes with |aggressive sometimes with |infinite loops |infinite loops and with ||some builtin functions --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-22 08:45:39 UTC --- If I change the printf to a just a normal function, CDDCE does not remove the loop.
[Bug tree-optimization/55018] CDDCE pass is too aggressive sometimes with infinite loops and with some builtin functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018
--- Comment #5 from Nicolas Morey-Chaisemartin nmorey at kalray dot eu
2012-10-22 08:48:52 UTC ---
It does if it takes occurrence as a parameter:
#include stdio.h
extern void myFunc(int);
void Sender_signal(int Connect)
{
int State = 3;
int occurrence = 0;
if (Connect) {
State = 0;
}
start:
if (Connect) {
goto start;
}
occurrence++;
if(State != 2){
myFunc(occurrence);
}
goto start;
}
[Bug rtl-optimization/55010] Internal consistency failure : invalid rtl sharing found in the insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55010 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-22 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 08:51:19 UTC --- Created attachment 28503 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28503 gcc48-pr55010.patch Untested fix.
[Bug tree-optimization/55018] [4.7/4.8 Regression] CDDCE pass is too aggressive sometimes with infinite loops and with some functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.4.5
Keywords||wrong-code
Last reconfirmed||2012-10-22
CC||pinskia at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|CDDCE pass is too |[4.7/4.8 Regression] CDDCE
|aggressive sometimes with |pass is too aggressive
|infinite loops and with |sometimes with infinite
|some builtin functions |loops and with some
||functions
Target Milestone|--- |4.7.3
Known to fail||4.7.0, 4.8.0
--- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-22
08:54:43 UTC ---
(In reply to comment #5)
It does if it takes occurrence as a parameter:
ok, I can now make a testcase which should exit but currently does not.
A Runtime testcase which works at -O1, -O2, and -O0 but goes into an infinite
loop at -O3:
void myFunc(int) __attribute__((noinline,noclone));
void myFunc(int a)
{
if (a==100)
__builtin_exit(0);
}
void Sender_signal(int Connect) __attribute__((noinline,noclone));
void Sender_signal(int Connect)
{
int State = 3;
int occurrence = 0;
if (Connect) {
State = 0;
}
start:
if (Connect) {
goto start;
}
occurrence++;
if(State != 2){
myFunc(occurrence);
}
goto start;
}
int main(void)
{
Sender_signal(0);
return 0;
}
[Bug tree-optimization/55018] [4.7/4.8 Regression] CDDCE pass is too aggressive sometimes with infinite loops and with some functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22
09:00:55 UTC ---
It's simple - you basically have
bb 2:
if (Connect_5(D) != 0)
goto bb 4;
else
goto bb 5;
bb 3:
# occurrence_3 = PHI 0(5), occurrence_1(3)
# .MEM_17 = PHI .MEM_9(D)(5), .MEM_2(3)
occurrence_1 = occurrence_3 + 1;
# .MEM_2 = VDEF .MEM_17
printf (Sender_Signal occurrence %d \n, occurrence_1);
goto bb 3;
and this invokes undefined behavior because occurrence_1 = occurrence_3 + 1
overflows. Thus GCC is free to do anything. Fixing the testcase doesn't
fix the code though:
void Sender_signal(int Connect)
{
unsigned int occurrence = 0;
int State = 3;
if (Connect)
State = 0;
start:
if (Connect)
goto start;
occurrence++;
if (State != 2)
__builtin_printf(Sender_Signal occurrence %u\n, occurrence);
goto start;
}
[Bug tree-optimization/55018] [4.6/4.7/4.8 Regression] CDDCE pass is too aggressive sometimes with infinite loops and with some functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.4 Target Milestone|4.7.3 |4.6.4 Summary|[4.7/4.8 Regression] CDDCE |[4.6/4.7/4.8 Regression] |pass is too aggressive |CDDCE pass is too |sometimes with infinite |aggressive sometimes with |loops and with some |infinite loops and with |functions |some functions Known to fail||4.6.3
[Bug tree-optimization/55011] [4.8 Regression] GCC in an infinite loop at -O2 in VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55011 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-22 Component|middle-end |tree-optimization Known to work||4.7.2 Target Milestone|--- |4.8.0 Summary|GCC in an infinite loop at |[4.8 Regression] GCC in an |-O2 |infinite loop at -O2 in VRP Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 09:04:42 UTC --- Confirmed. Iterating in VRP.
[Bug tree-optimization/55005] [4.8 Regression] gcc.c-torture/execute/loop-3.c FAILs with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55005 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/55001] Handle VEC_COND_EXPR in tree-vect-generic.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55001 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-22 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 09:05:42 UTC --- Confirmed.
[Bug tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/55008] [4.8 Regression] Internal compiler error : verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|Internal compiler error : |[4.8 Regression] Internal |verify_ssa failed |compiler error : verify_ssa ||failed
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/54990] [4.8 Regression] [OOP] ICE in tree_operand_check on SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54990 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/54988] fpmath=sse target pragma causes inlining failure because of target specific option mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-22 Component|target |c++ Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 09:15:19 UTC --- It's interesting to note that this only fails when using the C++ frontend, and only when optimizing(!). b does not have target specific optimization assigned for C++ while a has. Thus this is a C++ frontend issue.
[Bug tree-optimization/55011] [4.8 Regression] GCC in an infinite loop at -O2 in VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55011
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22
09:26:26 UTC ---
I bet this regressed with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=189885
together with one of r188728, r188776 or r188780 (in between r188700 and
r188800
it started to ICE, and with r189885 it started to loop infinitely instead of
ICEing).
If you want to iterate one more time, I think it would be better to ensure you
iterate just one more time and not infinitely.
Perhaps we could abuse for that the vr_phi_edge_counts array, if
if (edges 0
gimple_phi_num_args (phi) 1
lhs_vr-type == VR_UNDEFINED)
{
if (edges == old_edges)
/* Iterate one more time, but ensure next time we drop to varying
instead of looping forever. */
vr_phi_edge_counts[SSA_NAME_VERSION (lhs)] = -edges;
else if (edges == -old_edges)
goto varying;
}
before the
if (edges 0
gimple_phi_num_args (phi) 1
edges == old_edges
lhs_vr-type != VR_UNDEFINED)
[Bug target/55019] New: Incorrectly use live argument register to save high register in thumb1 prologue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019
Bug #: 55019
Summary: Incorrectly use live argument register to save high
register in thumb1 prologue
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: terry@arm.com
When run 4.7 regression test on cortex-m0 with options -mthumb -mcpu=cortex-m0
-O1 -funroll-loops, case gcc.dg/torture/builtin-complex-1.c will fail due to
the corruption of argument register as shown in below:
compare:
push{r3, r4, r6, lr}
movr6, fp
movr4, sl
movr3, r9-- r3 is clobbered
push{r3, r4, r6}
movr6, r8
push{r6}
movfp, r0
movsl, r1
movr9, r2
movr8, r3 -- wrong value is used
[Bug tree-optimization/55011] [4.8 Regression] GCC in an infinite loop at -O2 in VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55011
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22
09:44:18 UTC ---
(In reply to comment #2)
I bet this regressed with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=189885
together with one of r188728, r188776 or r188780 (in between r188700 and
r188800
it started to ICE, and with r189885 it started to loop infinitely instead of
ICEing).
If you want to iterate one more time, I think it would be better to ensure you
iterate just one more time and not infinitely.
Perhaps we could abuse for that the vr_phi_edge_counts array, if
if (edges 0
gimple_phi_num_args (phi) 1
lhs_vr-type == VR_UNDEFINED)
{
if (edges == old_edges)
/* Iterate one more time, but ensure next time we drop to varying
instead of looping forever. */
vr_phi_edge_counts[SSA_NAME_VERSION (lhs)] = -edges;
else if (edges == -old_edges)
goto varying;
}
before the
if (edges 0
gimple_phi_num_args (phi) 1
edges == old_edges
lhs_vr-type != VR_UNDEFINED)
It was supposed to be iterate one more time as then it will become not
VR_UNDEFINED. I'll investigate.
[Bug target/55019] Incorrectly use live argument register to save high register in thumb1 prologue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target||arm-eabi Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-22 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-10-22 09:53:40 UTC --- Testcase?
[Bug tree-optimization/55008] [4.8 Regression] Internal compiler error : verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008
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 2012-10-22
09:55:21 UTC ---
The typedef there is essential, without stdint.h can be reproduced e.g. on
typedef unsigned long int T;
void
foo (int a, int *p)
{
T b = 6309343725;
if (*p ? (b = 1) : 0)
if (b - (a = b /= 0) ? : (a + b))
while (1)
;
}
but not when b is unsigned long long int directly. slsr decides to change _12
= _9 + b_7; stmt to _12 = _12;, which is of course wrong.
[Bug tree-optimization/55011] [4.8 Regression] GCC in an infinite loop at -O2 in VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55011
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22
10:03:56 UTC ---
We are iterating between
Visiting PHI node: s_56 = PHI _53(3), _12(12)
Argument #0 (3 - 4 executable)
_53
Value: [63740, +INF] EQUIVALENCES: { _19 } (1 elements)
Argument #1 (12 - 4 executable)
_12
Value: UNDEFINED
Meeting
[63740, +INF] EQUIVALENCES: { _19 } (1 elements)
and
UNDEFINED
to
[63740, +INF] EQUIVALENCES: { } (0 elements)
Found new range for s_56: [63740, +INF]
Simulating statement (from ssa_edges): s_56 = PHI _53(3), _12(12)
Visiting PHI node: s_56 = PHI _53(3), _12(12)
Argument #0 (3 - 4 executable)
_53
Value: UNDEFINED
Argument #1 (12 - 4 executable)
_12
Value: UNDEFINED
Meeting
UNDEFINED
and
UNDEFINED
to
UNDEFINED
Found new range for s_56: UNDEFINED
Simulating statement (from ssa_edges): s_56 = PHI _53(3), _12(12)
Visiting PHI node: s_56 = PHI _53(3), _12(12)
Argument #0 (3 - 4 executable)
_53
Value: [63740, +INF] EQUIVALENCES: { _19 } (1 elements)
Argument #1 (12 - 4 executable)
_12
Value: UNDEFINED
Meeting
[63740, +INF] EQUIVALENCES: { _19 } (1 elements)
and
UNDEFINED
to
[63740, +INF] EQUIVALENCES: { } (0 elements)
Found new range for s_56: [63740, +INF]
which means _53 has bogus transitions:
Visiting statement:
_53 = ASSERT_EXPR _19, _19 63739;
Intersecting
[63740, +INF] EQUIVALENCES: { _19 } (1 elements)
and
[0, +INF]
to
[63740, +INF] EQUIVALENCES: { _19 } (1 elements)
Found new range for _53: [63740, +INF]
Visiting statement:
_53 = ASSERT_EXPR _19, _19 63739;
Intersecting
[63740, +INF] EQUIVALENCES: { _19 } (1 elements)
and
[15935, 32767]
to
UNDEFINED
Found new range for _53: UNDEFINED
I have a patch.
[Bug c++/54988] fpmath=sse target pragma causes inlining failure because of target specific option mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 10:54:25 UTC --- Created attachment 28504 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28504 gcc48-pr54988.patch Untested fix. Apparently the C++ FE assumes that if attributes is NULL, decl_attributes does nothing, which isn't true for FUNCTION_DECLs.
[Bug tree-optimization/54889] [4.8 Regression] Revision 191983 gives compfail for 465.tonto in SPEC CPU 2006 when use -O3 -mavx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54889 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 11:05:51 UTC --- Fixed.
[Bug target/55019] Incorrectly use live argument register to save high register in thumb1 prologue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55019 --- Comment #2 from Terry Guo terry.guo at arm dot com 2012-10-22 11:23:16 UTC --- Created attachment 28505 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28505 case to reproduce this bug
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 --- Comment #10 from Wolfgang Bangerth bangerth at gmail dot com 2012-10-22 11:58:58 UTC --- Given that this bug has been found 3 times already (and I extracted my testcase from the widely used BOOST library), is there an ETA for a fix? W.
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 12:03:45 UTC --- It has been fixed a week ago: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01538.html but the patch hasn't been reviewed yet. I'll ping it today.
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856 zerotype at yahoo dot com changed: What|Removed |Added CC||zerotype at yahoo dot com --- Comment #10 from zerotype at yahoo dot com 2012-10-22 12:21:22 UTC --- Are there any plans to backport this fix to any versions earlier than 4.7? Ubuntu 12.04 LTS, which only has version 4.6, is likely to be around for quite a long time due to its support lifespan.
[Bug c++/55020] New: 4.7.2 allow array init wih non-const argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55020
Bug #: 55020
Summary: 4.7.2 allow array init wih non-const argument
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marktbreme...@gmail.com
Created attachment 28506
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28506
g++ -v --version e.lis 21
int main() {
int sz = 13; // not a constant expression
int arr[sz]; // should not compile, but does so
}
compiles, but should not.
Array even works at runtime with int arg; cin arg; int arr[arg]; !
System: Suse Linux 12.2
g++ -v yields:
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper
Ziel: i686-pc-linux-gnu
Konfiguriert mit: ../gcc-4.7.2/configure --enable-languages=c++
Thread-Modell: posix
gcc-Version 4.7.2 (GCC)
g++ -v --version : see attachment:
[Bug c++/55020] 4.7.2 allow array init wih non-const argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55020 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-22 12:34:20 UTC --- This is a GNU extension and works by design, use -pedantic or -pedantic-errors to get a diagnostic f.cc:3:14: warning: ISO C++ forbids variable length array 'arr' [-Wvla]
[Bug c++/55020] 4.7.2 allow array init wih non-const argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55020 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-22 12:36:04 UTC --- Documented at http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 --- Comment #3 from mojo at world3 dot net 2012-10-22 12:40:57 UTC --- (In reply to comment #2) And I actually don't understand teh issue: Optimizing for size does not require to produce slow code. The code may run fast. -O3 is supposed to produce the fastest possible code, but it doesn't. -Os is faster. At the very least the two should be equal. In other words -O3 is broken.
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856 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 2012-10-22 12:41:32 UTC --- That is not possible, it requires new exports from a shared library, which isn't possible without backporting also all other symbols added to libstdc++.so for GCC 4.7.
[Bug c++/54922] [C++11][DR 1359] constexpr constructors require initialization of all union members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 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 Target Milestone|--- |4.8.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-22 12:42:32 UTC --- On it.
[Bug tree-optimization/55005] [4.8 Regression] gcc.c-torture/execute/loop-3.c FAILs with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55005 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-22 12:53:47 UTC --- $ gcc -O2 -funroll-loops -fPIC testcase.c ./a.out $ gcc -O2 -fpeel-loops -fPIC testcase.c ./a.out seem to be fine with current trunk. The others are failing though.
[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 12:56:23 UTC --- (In reply to comment #3) (In reply to comment #2) And I actually don't understand teh issue: Optimizing for size does not require to produce slow code. The code may run fast. -O3 is supposed to produce the fastest possible code, but it doesn't. -Os is faster. At the very least the two should be equal. Supposed to? Where in the documentation is that specified? I remember a sentence that -O3 enables optimization that might not always be profitable (but that sentence seems to be gone from latest docs). In other words -O3 is broken. It's behavior is certainly undesirable, but broken? For certain targets -Os might be a win because that's what it is tuned for or icache behavior is simply more important than anything else.
[Bug fortran/54997] [4.8 Regression] -Wunused-function gives false warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997 janus at gcc dot gnu.org changed: What|Removed |Added Summary|-Wunused-function gives |[4.8 Regression] |false warnings for |-Wunused-function gives |procedures passed as actual |false warnings |argument| --- Comment #6 from janus at gcc dot gnu.org 2012-10-22 12:58:48 UTC --- First, I forgot to mention that the behavior described in comment 0 is a 4.8 regression. Second, there is another case which still gives bogus warnings (also a regression), and that is ENTRY: subroutine sub entry en end subroutine Compiling this with -Wunused-function yields: warning: ‘master.0.sub’ defined but not used [-Wunused-function] subroutine sub ^
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 --- Comment #12 from Wolfgang Bangerth bangerth at gmail dot com 2012-10-22 13:05:36 UTC --- Thanks, Jakub!
[Bug tree-optimization/55005] [4.8 Regression] gcc.c-torture/execute/loop-3.c FAILs with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55005 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-22 13:08:40 UTC --- In .jump there's ;; Function main (main, funcdef_no=2, decl_uid=1727, cgraph_uid=2) (executed once) Deleted 22 trivially dead insns 3 basic blocks, 1 edges. (note 5 0 4 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (note 4 5 0 2 NOTE_INSN_FUNCTION_BEG) Doesn't look right.
[Bug lto/55021] New: [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 Bug #: 55021 Summary: [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: rgue...@gcc.gnu.org The tests gfortran.dg/integer_exponentiation_5.F90 (with -O1) and masklr_1.F90 are miscompiled with -flto after revision 192529 (r192528 is OK): [macbook] f90/bug% /opt/gcc/gcc4.8p-192559/bin/gfortran /opt/gcc/work/gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90 -fno-range-check -O1 -flto [macbook] f90/bug% a.out Backtrace for this error: #0 0x141ae #1 0x14536 #2 0x1000d6108 #3 0x10c19 #4 0x10cd5 Abort [macbook] f90/bug% /opt/gcc/gcc4.8p-192559/bin/gfortran /opt/gcc/work/gcc/testsuite/gfortran.dg/masklr_1.F90 -ffree-line-length-none -flto [macbook] f90/bug% a.out Backtrace for this error: #0 0x151ae #1 0x15536 #2 0x1000d7108 #3 0x11b33 #4 0x11cff Abort Reduced test case module mod_check implicit none contains subroutine check_i8 (a, b) integer(kind=8), intent(in) :: a, b if (a /= b) call abort() end subroutine check_i8 end module mod_check program test use mod_check implicit none integer(kind=8) :: i8 i8 = 3_8 call check_i8(i8**43_8,3_8**43_8) end program test
[Bug tree-optimization/55011] [4.8 Regression] GCC in an infinite loop at -O2 in VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55011 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 13:26:52 UTC --- Author: rguenth Date: Mon Oct 22 13:26:48 2012 New Revision: 192689 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192689 Log: 2012-10-22 Richard Biener rguent...@suse.de PR tree-optimization/55011 * tree-vrp.c (update_value_range): For invalid lattice transitions drop to VARYING. * gcc.dg/torture/pr55011.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55011.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/55011] [4.8 Regression] GCC in an infinite loop at -O2 in VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55011 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 2012-10-22 13:27:16 UTC --- Fixed.
[Bug middle-end/54921] [4.8 Regression] wrong code with -Os -fno-omit-frame-pointer -fsched2-use-superblocks -fstack-protector -ftree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54921 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-22 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-22 13:38:20 UTC --- Confirmed.
[Bug lto/55021] [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-22 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 13:42:33 UTC --- I get ./gfortran -B. -B ../x86_64-unknown-linux-gnu/libgfortran/.libs t.f90 -ffree-line-length-none t.f90:20.28: call check_i8(i8**43_8,3_8**43_8) 1 Error: Arithmetic overflow at (1)
[Bug tree-optimization/55008] [4.8 Regression] Internal compiler error : verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org |gnu.org | --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-10-22 13:48:26 UTC --- Mine. Just unburying myself after vacation, but will take a look as soon as I can.
[Bug lto/55021] [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-22 13:48:27 UTC --- I get ./gfortran -B. -B ../x86_64-unknown-linux-gnu/libgfortran/.libs t.f90 -ffree-line-length-none t.f90:20.28: call check_i8(i8**43_8,3_8**43_8) 1 Error: Arithmetic overflow at (1) If t.f90 is the reduced test in comment #0 (reduced from integer_exponentiation_5.F90), you need -fno-range-check (no need for -ffree-line-length-none).
[Bug tree-optimization/55022] New: [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Bug #: 55022 Summary: [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: gros...@gcc.gnu.org, rgue...@gcc.gnu.org The test air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619 (r188694 is OK): ... ITERATION# TIME FINAL MASS RESIDUAL 90.45757110 0.01000.597638 170.91473627 0.01000.448609 250.000137176442 0.01000.608353 330.000182824593 0.01000.619686 410.000228306169 0.01000.628800 490.000273480245 0.01000.813862 580.000323343055 0.01001.026950 670.000371631805 0.01001.238993 770.000422628642 0.01001.474307 880.000474256730 0.01001.679987 1000.000524089193 0.01001.789565 1140.000575138355 0.01001.834548 1290.000625547555 0.01001.945421 1440.000674419139 0.01002.198194 1660.000728576510 0.0100 NaN 168 100.000735868323 0.0100 NaN deltat, final t, iterations 100.00100.00073586832266 168 9 0.59763770273003503 17 0.44860912267491976 25 0.60835306073381645 33 0.61968645389575716 41 0.62879989012582926 49 0.81386186515901682 58 1.0269501832675307 67 1.2389929088800784 77 1.4743070523641029 88 1.6799869908106582 100 1.7895645561305713 114 1.8345478482485826 129 1.9454206794378737 144 2.1981944269573130 166 NaN 168 NaN The miscompiled subroutines are botwall and topwall.
[Bug lto/55021] [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 14:05:36 UTC --- Confirmed. Note that due to a Frontend issue (wrong decls for check_i8?) without LTO no inlining takes place. As soon as we inline we have _gfortran_set_options (7, options.0[0]); _10 = 0x565d7b7b; _7 = _10; _8 = -3784425932234851461; if (_7 != _8) goto bb 3; from D.1880 = -3784425932234851461; check_i8 (D.1880, C.1881); With the simplified subroutine check_i8 (a, b) integer(kind=8), intent(in) :: a, b if (a /= b) call abort() end subroutine check_i8 program test implicit none integer(kind=8) :: i8 i8 = 3_8 call check_i8(i8**43_8,3_8**43_8) end program test I can get non-LTO to inline check_i8 with -fwhole-prgram. I think your bisection is wrong and 2012-10-18 Richard Guenther rguent...@suse.de * lto-streamer.h (enum LTO_tags): Add LTO_integer_cst. * lto-streamer-in.c (lto_input_tree): Use it. * lto-streamer-out.c (lto_output_tree): Likewise, for !TREE_OVERFLOW integer constants only. * tree-streamer-in.c (unpack_ts_int_cst_value_fields): New function. (unpack_value_fields): Call it. (streamer_read_integer_cst): Simplify. * tree-streamer-out.c (pack_ts_int_cst_value_fields): New function. (streamer_pack_tree_bitfields): Call it. (streamer_write_integer_cst): Adjust. must be the issue. Very likely we have an INTEGER_CST with TREE_OVERFLOW flag set.
[Bug lto/55021] [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 14:07:37 UTC --- I have an obvious patch.
[Bug lto/55021] [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-10-22 14:10:31 UTC --- Author: rguenth Date: Mon Oct 22 14:10:06 2012 New Revision: 192691 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192691 Log: 2012-10-22 Richard Biener rguent...@suse.de PR lto/55021 * tree-streamer-in.c (unpack_ts_int_cst_value_fields): Remove bogus truncations. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-streamer-in.c
[Bug lto/55021] [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 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 2012-10-22 14:10:49 UTC --- Fixed.
[Bug lto/55021] [4.8 Regression] The tests gfortran.dg/integer_exponentiation_5.F90 and masklr_1.F90 are miscompiled with -flto after revision 192529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55021 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-22 14:14:19 UTC --- I think your bisection is wrong ... Indeed I meant r192559 (see /opt/gcc/gcc4.8p-192559/bin/gfortran in comment#0). Thanks for the quick fix.
[Bug c++/55020] 4.7.2 allow array init wih non-const argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55020 --- Comment #3 from marktbremen45 at gmail dot com 2012-10-22 14:20:39 UTC --- ok - no bug thanks for the hint
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-22 14:24:51 UTC --- Created attachment 28507 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28507 compressed archive for the test The attachment contains the original source air_main.f90 without the subroutines botwall and topwall which are in the files botwall.f90 and topwall.f90, and the files datax.inp and datay.inp needed to run the test. It can be used as gfc -c -O2 -fgraphite-identity air_main.f90 gfortran -c -O2 -fgraphite-identity botwall.f90 topwall.f90 gfc air_main.o botwall.o topwall.o With gfc any post r190619 gfortran and gfortran any version pre r188694, this will give a working executable. If botwall.f90 and/or topwall.f90 is compiled with a post r190619 gfortran, the executable will give NANs.
[Bug tree-optimization/55018] [4.6/4.7/4.8 Regression] CDDCE pass is too aggressive sometimes with infinite loops and with some functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 14:30:42 UTC --- Yeah, I think this is a CDDCE bug, in particular incorrect assumption about post-dominators in presence of infinite loops. The problem is that with infinite loops, worst case all basic blocks on a path from a conditional to an infinite loop that is control dependent on the conditional can have fake edge to exit and therefore find_control_dependence stops on those.
[Bug target/55023] New: hppa: wrong code generated with tail call optimisation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023
Bug #: 55023
Summary: hppa: wrong code generated with tail call optimisation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@mansr.com
The following code is compiled incorrectly with flags -O2 -fno-inline: the
third argument to the tail called function is not computed at all. This
problem is present in all versions since 4.3. 4.1 and 4.2 compile it
correctly.
The error -fno-inline flag is needed to suppress inlining of the called
function; when inlined it is compiled correctly. Providing only an external
declaration for foo() also gives correct results.
---8---
typedef long long int64_t;
struct foo {
int x;
int y;
};
int64_t foo(int64_t a, int64_t b, int64_t c)
{
return a + b + c;
}
int64_t bar(int64_t a, struct foo bq, struct foo cq)
{
int64_t b = bq.x + bq.y;
int64_t c = cq.x + cq.y;
return foo(a, b, c);
}
---8---
This is the generated code:
.align 4
.globl bar
.typebar, @function
bar:
.PROC
.CALLINFO FRAME=0,NO_CALLS,SAVE_RP
.ENTRY
stw %r23,-48(%r30)
stw %r24,-44(%r30)
ldw -44(%r30),%r28
stw %r2,-20(%r30)
ldw -48(%r30),%r24
addl %r24,%r28,%r24
extrs %r24,0,1,%r23
ldw -20(%r30),%r2
bl foo,%r0
nop
nop
.EXIT
.PROCEND
[Bug c++/54988] fpmath=sse target pragma causes inlining failure because of target specific option mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988 --- Comment #3 from Thiago Macieira thiago at kde dot org 2012-10-22 14:43:11 UTC --- This might be as I pointed out in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231: (Node Function attributes): On the 386/x86_64 and PowerPC backends, the inliner will not inline a function that has different target options than the caller, unless the callee has a subset of the target options of the caller. For example a function declared with `target(sse3)' can inline a function with `target(sse2)', since `-msse3' implies `-msse2'. My guess was that we were forcing the inlining (via always_inline) of a function that has different target options. But I guess that doesn't explain why it happens only in C++ and only in optimising mode. Does always_inline inline on -O0 too?
[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2012-10-22 14:55:35 UTC --- Unfortunately, the patch causes -fcompare-debug issues. The problem is that with it we create some declarations only when producing debug info which can affect UIDs which then changes other stuff. I tried producing DEBUG_EXPR_DECLs instead of regular decls but SET_DECL_DEBUG_EXPR does not accept DEBUG_EXPR_DECLs as an argument, it insists on VAR_DECLs. I tried removing the checking restriction but it turned out that using DEBUG_EXPR_DECLs does not fix the testcase. Jakub, do you think that can be fixed or are DEBUG_EXPR_DECLs a completely different thing that principally canno be used for this purpose? Another alternative is to build full-fledged replacement decls even when not producing debug info, even though we'd never use it. That seems slightly wasteful but can be done. (Some reworking of replacement building would be probably required so that we get rid of lazy replacement building which is no longer necessary).
[Bug tree-optimization/55018] [4.6/4.7/4.8 Regression] CDDCE pass is too aggressive sometimes with infinite loops and with some functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55018 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 15:03:34 UTC --- Created attachment 28508 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28508 gcc48-pr55018.patch Untested fix. If such a bb has more than one succ edge, I think it ought to have either a control stmt in it, or throwing stmt, so I think a bb with high index (because calc_dfs_tree uses FOR_EACH_BB_REVERSE to find the still unconnected bbs), on a path from a conditional to an infinite loop, that doesn't contain any stmts marked already as necessary (on the testcase none at all) is the only problem.
[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 15:09:05 UTC --- Can you say what -fcompare-debug failures you saw (or was it a bootstrap problem already)? Generally, differences in DECL_UIDs between -g and -g0 should be ok as long as the decls corresponding to decls built at -g0 sort by DECL_UID the same with -g0 and -g, and there should be no differences in between SSA_NAME_VERSION values between -g0 and -g.
[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2012-10-22 15:14:13 UTC --- (In reply to comment #5) Can you say what -fcompare-debug failures you saw (or was it a bootstrap problem already)? Bootstrap actually passes. I's gcc.dg/pr46571.c that fails. If I just emit the decl without using it, it passes too.
[Bug middle-end/55024] New: cse_process_notes_1/equiv_constant: missing mode check for hardware registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55024
Bug #: 55024
Summary: cse_process_notes_1/equiv_constant: missing mode check
for hardware registers
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aurelien.buhrig@gmail.com
Created attachment 28509
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28509
cse_process_notes_1/equiv_constant
It seems there is a bug in cse_process_notes_1 (gcc 4.6.3, but should occurs on
trunk), for a private backend. The testcase is pr27364.c, compiled with -Os.
In the following RTL, the hardware register (reg:HI r2), whose natural mode is
HImode, is set to 0, but when analysing the REG_EQUAL notes of the MULT
insn during CSE pass, the (reg:SI r2) is computed to be equivalent to
(const_int 0), which is wrong (the target is big endian).
(insn 51 9 52 3 (set (reg:HI 2 r2)
(const_int 0 [0])) gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
(expr_list:REG_DEAD (reg:HI 31)
(expr_list:REG_EQUAL (const_int 0 [0])
(nil
(insn 52 51 12 3 (set (reg:HI 3 r3 [orig:2+2 ] [2])
(reg/v:HI 20 [ number_of_digits_to_use ]))
gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
(expr_list:REG_DEAD (reg/v:HI 20 [ number_of_digits_to_use ])
(nil)))
(insn 12 52 13 3 (set (reg:SI 0 r0)
(const_int 3321928 [0x32b048]))
gcc.c-torture/execute/pr27364.c:5 19 {movsi}
(nil))
(insn 13 12 16 3 (parallel [
(set (reg:SI 0 r0)
(mult:SI (reg:SI 2 r2)
(reg:SI 0 r0)))
(clobber (reg:SI 2 r2))
]) gcc.c-torture/execute/pr27364.c:5 54 {*mulsi3_call}
(expr_list:REG_EQUAL (mult:SI (reg:SI 2 r2)
(const_int 3321928 [0x32b048]))
(expr_list:REG_DEAD (reg:HI 3 r3)
(expr_list:REG_UNUSED (reg:SI 2 r2)
(nil)
I think a mode size check is missing when processing REG code in
cse_process_notes_1. Adding such a check prevents the CSE pass from
elimintating the MULT instruction.
The attached patch fixes this issue.
I added the same check in equiv_constant as suggested by Eric Botcazou:
http://gcc.gnu.org/ml/gcc/2012-10/msg00263.html
Not yet bootstraped on trunk.
[Bug tree-optimization/55008] [4.8 Regression] Internal compiler error : verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008 --- Comment #4 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-10-22 15:41:41 UTC --- Simple enough. The statement has two interpretations and one looks like a basis for the other. Surprised this never came up before. Adding a check to avoid letting a statement treat itself as a basis should take care of this.
[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #11 from Pat Haugen pthaugen at gcc dot gnu.org 2012-10-22 15:50:06 UTC --- (In reply to comment #9) Created attachment 28482 [details] Candidate patch. Could you both please test this patch? The patch fixes the issue for me too, on both the reduced testcase and the full benchmark.
[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 16:19:18 UTC --- Created attachment 28510 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28510 gcc48-pr54971-incremental.patch Incremental patch that makes the pr46571.c testcase pass. The primary problem was passing non-NULL prefix to create_tmp_var* for something that is called solely if MAY_HAVE_DEBUG_STMTS, because create_tmp_var_name uses a global counter for all temp variables, thus if it is incremented with -g and not with -g0, it resulted e.g. in ivopts creating different var names, which, unlike DECL_UIDs, should be the same. I guess the SR.NUM names are still useful for debugging of SRA and later passes (in the unlikely case where a fancy name isn't assigned, if there is fancy name, there is no point in creating a SR.* name), but if we do that, it is better to create it only for replacements used in non-debug code (which is why I've moved the assignment of DECL_NAME if it doesn't have fancy name). And I've moved also the dump_file printout, because otherwise it would be confusing if we printed we've created a D.12345 replacement and subsequently immediately used SR.123 for it's name instead. I think we shouldn't be using create_tmp_var at all for the debug only replacements, as it calls gimple_add_tmp_var and preferrably the local decls should be the same between -g and -g0 too.
[Bug rtl-optimization/55025] New: reg_nonzero_bits_for_combine/get_last_value: missing mode check for hardware registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55025
Bug #: 55025
Summary: reg_nonzero_bits_for_combine/get_last_value: missing
mode check for hardware registers
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aurelien.buhrig@gmail.com
Created attachment 28511
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28511
patch
This bug occurs with gcc 4.6.3 for a private backend (big endian), but should
occurs on trunk. The testcase is pr27364.c, compiled with -Os.
In the following RTL, the hardware register (reg:HI r2), whose natural mode is
HImode, is set to 0, but when combining insn 12 and insn 13 insn (during
combine pass), the (reg:SI r2) is computed to be equivalent to
(const_int 0), which is wrong (it is (reg:HI r2) which is (const_int 0)).
(insn 51 9 52 3 (set (reg:HI 2 r2)
(const_int 0 [0])) gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
(expr_list:REG_DEAD (reg:HI 31)
(expr_list:REG_EQUAL (const_int 0 [0])
(nil
(insn 52 51 12 3 (set (reg:HI 3 r3 [orig:2+2 ] [2])
(reg/v:HI 20 [ number_of_digits_to_use ]))
gcc.c-torture/execute/pr27364.c:5 18 {*movhi1}
(expr_list:REG_DEAD (reg/v:HI 20 [ number_of_digits_to_use ])
(nil)))
(insn 12 52 13 3 (set (reg:SI 0 r0)
(const_int 3321928 [0x32b048]))
gcc.c-torture/execute/pr27364.c:5 19 {movsi}
(nil))
(insn 13 12 16 3 (parallel [
(set (reg:SI 0 r0)
(mult:SI (reg:SI 2 r2)
(reg:SI 0 r0)))
(clobber (reg:SI 2 r2))
]) gcc.c-torture/execute/pr27364.c:5 54 {*mulsi3_call}
(expr_list:REG_EQUAL (mult:SI (reg:SI 2 r2)
(const_int 3321928 [0x32b048]))
(expr_list:REG_DEAD (reg:HI 3 r3)
(expr_list:REG_UNUSED (reg:SI 2 r2)
(nil)
The problem comes from a missing mode check in both
reg_nonzero_bits_for_combine and get_last_value.
See http://gcc.gnu.org/ml/gcc/2012-10/msg00263.html for more information.
Note that the problem in get_last_value has already been reported (bug 49884).
The attached patch fixes the issue in gcc-4.6.3. Not yet boostraped on trunk.
[Bug target/55026] New: [Multiple targets] Inefficient code with structs passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55026
Bug #: 55026
Summary: [Multiple targets] Inefficient code with structs
passed by value
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@mansr.com
Multiple targets (including ARM, HPPA, and MIPS) generate inefficient code in
functions taking struct arguments by value. Consider this code:
struct foo {
int a;
int b;
};
int f(struct foo x)
{
return x.a + x.b;
}
On ARM, this compiles to the following at -O3 optimisation:
f:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
add r3, sp, #8
stmdb r3, {r0, r1}
ldmia sp, {r0, r3}
add r0, r0, r3
add sp, sp, #8
@ sp needed
bx lr
Note the entirely unnecessary (and inefficiently done to boot) storing and
loading of the argument registers to/from the stack.
The x86_64 and SH4 targets do not show this behaviour.
[Bug target/55026] [Multiple targets] Inefficient code with structs passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55026 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-22 16:41:09 UTC --- I think I already filed this bug about 4 years ago or so.
[Bug tree-optimization/55016] request for specific builtins for rcp and rsqrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55016
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-10-22 18:56:42
UTC ---
(In reply to comment #0)
void v() {
for(int i=0; i!=1024; ++i)
v0[i] = rsqrtf(v1[i]);
}
Doesn't writing
v0[i] = 1 / sqrtf(v1[i])
work with suitable fast-math flags? It still produces an extra iteration to
refine the result, do we want a -ffaster-math?
[Bug middle-end/55027] New: simplify vector multiplication by 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55027
Bug #: 55027
Summary: simplify vector multiplication by 1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Hello,
vector multiplication by 1 is not simplified at the tree level.
#include x86intrin.h
__m128d f(__m128d x){
__m128d y={1,1};
return x*y;
}
Worse, gcc can actually create such multiplies. In this modified version of
PR55016:
#include math.h
float v0[1024];
float v1[1024];
void v() {
for(int i=0; i!=1024; ++i)
v0[i] = 1/sqrtf(v1[i]);
}
compiled on x86_64 with gcc -O3 -ffast-math e.c -S -std=gnu99
*.optimized still shows:
vect_var_.9_23 = vect_var_.8_21 * { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 };
The back-end later removes it, but it should also be handled at tree level.
[Bug target/55026] Useless stores generated for structures passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55026
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-10-22
CC||ebotcazou at gcc dot
||gnu.org
Summary|[Multiple targets] |Useless stores generated
|Inefficient code with |for structures passed by
|structs passed by value |value
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-22
19:08:10 UTC ---
This depends on the internal argument passing mechanism (BLKmode registers vs
PARALLEL) and on the strict-alignment requirements of the architecture. Try:
struct __attribute__((aligned (8))) foo {
int a;
int b;
};
int f(struct foo x)
{
return x.a + x.b;
}
to watch the effects of the latter.
[Bug target/55026] Useless stores generated for structures passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55026
--- Comment #3 from Mans Rullgard mans at mansr dot com 2012-10-22 19:34:25
UTC ---
It has actually got worse over time. With 4.3 I get this:
f:
sub sp, sp, #8
mov r2, r0
stmia sp, {r0, r1}
add r0, r1, r2
add sp, sp, #8
bx lr
Here it's only doing the stores, not the loads, and it does them using sp
directly.
With 4.4 and 4.5 it gets slightly worse:
f:
sub sp, sp, #8
mov r3, sp
stmia r3, {r0, r1}
mov r3, r0
add r0, r1, r3
add sp, sp, #8
bx lr
Now it's copying sp to another register used as base address in the store. The
load is still absent.
4.6 and later produce the code I quoted originally. I can't say I like the
trend.
[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 --- Comment #10 from Andrey Belevantsev abel at gcc dot gnu.org 2012-10-22 19:34:41 UTC --- Author: abel Date: Mon Oct 22 19:34:35 2012 New Revision: 192693 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192693 Log: Backport from mainline 2012-08-09 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/53701 * sel-sched.c (vinsn_vec_has_expr_p): Clarify function comment. Process not only expr's vinsns but all old vinsns from expr's history of changes. * gcc.dg/pr53701.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr53701.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/sel-sched.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/55026] Useless stores generated for structures passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55026 --- Comment #4 from Mans Rullgard mans at mansr dot com 2012-10-22 19:37:58 UTC --- For the record, clang/llvm gets this right.
[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Andrey Belevantsev abel at gcc dot gnu.org 2012-10-22 19:40:17 UTC --- Fixed.
[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-22 19:59:44 UTC --- With your patch and my incremental patch on top of it bootstrap/regtest passed on both x86_64-linux and i686-linux btw.
[Bug target/54888] GCC with -Os is faster than -O3 on some AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-10-22 20:10:44 UTC --- As a start, you could try to enable us to reproduce your problem. First of all, it is clear that we don't have your hardware (oscilloscope) to measure things and even if, it is very unlikely someone will start research to find out exactly were you lost the ticks. Second, notice that it is ulikely anybody is inclined to pick up buch of code you dumped above. It's 3800 lines and around 30 functions. And it fails to compile. Maybe you can be more descriptive and point out what /exactly/ goes wrong and work out a small example and limit to a critical spot or function and throw away unneeded stuff. Third, please notice that 4.3 is no more supported since several years now. Please supply code that compiles with a supported version of the compiler which implies at least 4.7 (because you use -mmcu=atxmega128d3). Fourth, you use inline assembler that is not correct because of missing memory barrier and might show malfunction in corner cases. Thus, you may want to fix at least 3. and 4. and rerun your benchmarks to see if the problem still exists. Very likely, that is not the case.
[Bug target/32381] m68k undefined symbol __cmpsf2_internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32381 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 Known to fail|| --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2012-10-22 20:11:13 UTC --- Fixed in 4.4.0.
[Bug target/37680] ICE: unable to generate reloads for: (insn:QI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37680 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2012-10-22 20:20:33 UTC --- 4.3 branch is closed.
[Bug c++/54560] g++ with --sysroot and -save-temps don't play nicely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54560 Etienne Le Sueur elesueur at vmware dot com changed: What|Removed |Added CC||elesueur at vmware dot com --- Comment #2 from Etienne Le Sueur elesueur at vmware dot com 2012-10-22 20:24:44 UTC --- (In reply to comment #0) Another option might be to add a %I to the spec where this gets emitted [1] so that a valid -isysroot value gets passed? [1] http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/lang-specs.h;h=a73aba3cdc0dd970b068ce9172acdfeb20fbe7f5;hb=HEAD That seems to work. Paolo, any chance this would get into 4.6.4 (if there is such a release planned)?
[Bug rtl-optimization/28925] problem with zero_extract during gcse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28925 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.6 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2012-10-22 20:34:36 UTC --- No longer reproducable since 4.2, assuming fixed.
[Bug target/28882] Use more register name macros in m68k port
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28882 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2012-10-22 20:40:11 UTC --- Fixed in 4.3.
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 Martin Cracauer cracauer at cons dot org changed: What|Removed |Added CC||cracauer at cons dot org --- Comment #26 from Martin Cracauer cracauer at cons dot org 2012-10-22 20:50:25 UTC --- I'm afraid this doesn't quite do it. I still observe a 60% slowdown going from gcc-4.4 to gcc-4.7, with this fix already in, specifically for insert(). It's a 320,000 member table I am dealing with here. I can make 4.7 be as fast as 4.4 by preemptively setting the reserve to what I know (for this test) to be the maximum size I need, but measured resident memory shoots up (not unexpected). And resident memory of the 4.7 build was already higher than 4.4 so I don't think this can be the answer here. Playing with the load factor resulted in a minor speedup with 0.4 (from 1.0), but not reaching 4.4 performance. Other load factors (lower than 0.4 and higher than 1.0) are even slower. Is there more specific information available about the tradeoff numbers that made GNU pick this new implementation?
[Bug c++/55028] New: _GLIBCXX_DEBUG is broken when using v7 namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
Bug #: 55028
Summary: _GLIBCXX_DEBUG is broken when using v7 namespace
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o...@smolsky.net
I've just hit an issue when using _GLIBCXX_DEBUG together with gcc 4.7.2 built
using --enable-symvers=gnu-versioned-namespace flag. The issue is specific to
unordered_mulimap and can be reproduced using the following:
struct MyType
{
};
#if 1
using MyMap = std::multimapstd::string, MyType *;// works
#else
using MyMap = std::unordered_multimapstd::string, MyType *; // fails to link
#endif
MyMap m;
m.insert({blah}, new MyType});
The latter variant fails to link with the following message:
misc/libmisc.a(statmgr.o): In function
`__gnu_debug::_Safe_unordered_container_base::~_Safe_unordered_container_base()':
statmgr.cc:(.text._ZN11__gnu_debug30_Safe_unordered_container_baseD2Ev[_ZN11__gnu_debug30_Safe_unordered_container_baseD5Ev]+0x15):
undefined reference to
`__gnu_debug::_Safe_unordered_container_base::_M_detach_all()'
The compiler was configured as follows:
Configured with: ../gcc-4.7.2/configure --prefix=/opt/gcc-4.7-v7
--enable-languages=c,c++,lto --with-mpfr=/opt/gcc-4.6-rbt
--with-cloog=/opt/gcc-4.6-rbt --with-mpc=/opt/gcc-4.6-rbt
--with-gmp=/opt/gcc-4.6-rbt --with-system-zlib --disable-multilib --enable-lto
--with-build-config=bootstrap-lto --with-fpmath=sse --enable-build-with-cxx
--enable-gold=yes --enable-cloog-backend=isl --disable-cloog-version-check
--enable-symvers=gnu-versioned-namespace CFLAGS=-O3 CXXFLAGS=-O3
Thread model: posix
gcc version 4.7.2 (GCC)
[Bug c++/55028] _GLIBCXX_DEBUG is broken when using v7 namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-22 21:04:54 UTC --- Benjamin, can you have a look?
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #27 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-22 21:05:41 UTC --- I can only recommend profiling (by gprof or other means).
[Bug target/36772] GCC generates impossible BRANCH instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36772 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2012-10-22 21:08:47 UTC --- Fixed in 4.6.
[Bug c++/55028] _GLIBCXX_DEBUG is broken when using v7 namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-22 21:12:07 UTC --- Looks like some debug mode symbols need exporting, nothing particularly complex.
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #28 from Martin Cracauer cracauer at cons dot org 2012-10-22 22:04:27 UTC --- I should clarify that I was pointed to this problem (with insert) by profiling and for us nothing pops up as faster (or smaller for that matter). Hence the question.
[Bug tree-optimization/55008] [4.8 Regression] Internal compiler error : verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008 --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-10-22 22:09:29 UTC --- Author: wschmidt Date: Mon Oct 22 22:09:22 2012 New Revision: 192696 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192696 Log: gcc: 2012-10-22 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/55008 * gimple-ssa-strength-reduction.c (find_basis_for_candidate): Don't allow a candidate to be a basis for itself under another interpretation. gcc/testsuite: 2012-10-22 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/55008 * gcc.dg/tree-ssa/pr55008.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr55008.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/55008] [4.8 Regression] Internal compiler error : verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-10-22 22:19:06 UTC --- Fixed.
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #29 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-22 22:47:31 UTC --- Indeed, if we have to do something about that, we need to know those profiles. That's my point. Otherwise, blindly, it could be anything, ie, not necessarily rehashes which are the topic of this specific PR.
