[Bug rtl-optimization/55154] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55154 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-11-09 15:33:27 UTC --- Author: vmakarov Date: Fri Nov 9 15:33:19 2012 New Revision: 193364 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193364 Log: 2012-11-09 Vladimir Makarov vmaka...@redhat.com PR tree-optimization/55154 * lra-int.h (LRA_LOSER_COST_FACTOR, LRA_MAX_REJECT): New macros. * lra.c (setup_operand_alternative): Use them. * lra-constraints.c (LOSER_COST_FACTOR, MAX_OVERALL_COST_BOUND): Remove. (process_alt_operands): Use LRA_LOSER_COST_FACTOR and LRA_MAX_REJECT. Accumulate reject instead of setting for non-const. (curr_insn_transform): Initialize best_losers and best_overall by INT_MAX. 2012-11-09 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55154 * gcc.target/i386/pr55154.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55154.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra-int.h trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-11-09 16:14:56 UTC --- Author: jason Date: Fri Nov 9 16:14:48 2012 New Revision: 193368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193368 Log: PR c++/54859 * pt.c (check_instantiated_arg): Don't complain about dependent args. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug libgomp/55251] New: inconsistent OpenMP tasks scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55251
Bug #: 55251
Summary: inconsistent OpenMP tasks scheduling
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alfredo.butt...@gmail.com
I have problems when executing a standard OpenMP tasks example from the OpenMP
3.1 API document (Example A.15.2c):
struct node {
struct node *left;
struct node *right;
};
extern void process(struct node *);
void postorder_traverse( struct node *p ) {
if (p-left)
#pragma omp task
// p is firstprivate by default
postorder_traverse(p-left);
if (p-right)
#pragma omp task
// p is firstprivate by default
postorder_traverse(p-right);
#pragma omp taskwait
process(p);
}
int main(){
...
#pragma omp parallel
{
#pragma omp master
{
postorder_traverse(root);
}
}
...
The problem is related to the scheduling of tasks. I want to count the number
of tasks executed by each OpenMP thread to check whether the workload
distribution is balanced. Now, if I use two threads then the tasks are pretty
much equally distributed. If I use 3 or 4 threads, the master thread always
executes only one task (corresponding to the root, topmost node of the tree).
With more than 4 threads the behavior is inconsistent in the sense that
sometimes the tasks are well distributed, sometimes the master does only one
task. Is this a bug? This happens with different versions of gcc from 4.4 up to
4.7 but not with the intel compiler.
Thanks
Alfredo
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-09 16:38:16 UTC --- OK, I applied it to our autotester and we will see tomorrow if it fixes the segfaults. If so, can I go ahead and commit it? Honza
[Bug c++/55252] New: Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Bug #: 55252 Summary: Caret diagnostic doesn't show useful location when macro clashes with name in system header Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org (preprocessed source doesn't show the error due to the system_header pragma) $ cat test.cc #define bar 1 #include header.h $ cat header.h #pragma GCC system_header int bar = 0; $ g++ test.cc test.cc:1:13: error: expected unqualified-id before numeric constant #define bar 1 ^ This is no help because it doesn't point you to the line in header.h that clashes with 'bar' Without the system_header pragma you get test.cc:1:13: error: expected unqualified-id before numeric constant #define bar 1 ^ header.h:2:5: note: in expansion of macro 'bar' int bar = 0; ^ Which at least shows both locations, although the first diagnostic is still confusing ... are the two locations backwards? The expected unqualified-id before numeric constant should point to int bar = 0;
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-09 18:08:40 UTC --- clang++ gets this right, printing the same thing with or without the system_header pragma, and swapping the locations of the error and the note: In file included from test.cc:2: ./header.h:1:5: error: expected unqualified-id int bar = 0; ^ test.cc:1:13: note: expanded from macro 'bar' #define bar 1 ^ 1 error generated. This makes much more sense.
[Bug tree-optimization/55253] New: [4.8 Regression] Revision 193298 miscompiles sqlite with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55253 Bug #: 55253 Summary: [4.8 Regression] Revision 193298 miscompiles sqlite with -Os Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de r193298 miscompiles sqlite with -Os (and thereby crashes Firefox during startup): Program received signal SIGSEGV, Segmentation fault. sqlite3DbRealloc (db=0x0, p=p@entry=0x0, n=n@entry=9) at sqlite3.c:19120 (gdb) bt #0 sqlite3DbRealloc (db=0x0, p=p@entry=0x0, n=n@entry=9) at sqlite3.c:19120 #1 0x77f908e5 in sqlite3StrAccumAppend (p=0x7fffcdb8, z=0x4082e9 sqlite , N=8) at sqlite3.c:19966 #2 0x77f909d9 in sqlite3VXPrintf (pAccum=0x7fffcdb8, useExtended=0, fmt=0x4082f1 , ap=0x7fffcdf8) at sqlite3.c:19449 #3 0x77f91754 in sqlite3_vsnprintf (n=0, zBuf=0x0, zFormat=0x9 Address 0x9 out of bounds, ap=ap@entry=0x7fffcdf8) at sqlite3.c:20140 #4 0x77f917e8 in sqlite3_snprintf (n=n@entry=20, zBuf=zBuf@entry=0x40b4a0 mainPrompt , zFormat=zFormat@entry=0x4082e9 sqlite ) at sqlite3.c:20147 #5 0x004063f5 in main_init (data=0x7fffcef8) at shell.c:2845 #6 main (argc=2, argv=0x7fffe558) at shell.c:2864 -O2 or -O3 are fine.
[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|jason at gcc dot gnu.org| Resolution||FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-09 18:23:57 UTC --- This is fixed then.
[Bug c++/55254] New: Warn for implicit conversion from int to char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55254
Bug #: 55254
Summary: Warn for implicit conversion from int to char
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@doublewise.net
I sometimes want to construct a string with n copies of a char c. However, I
frequently get the order of elements in the constructor mixed up. Rather than
saying std::string(80, '='), I accidentally call std::string('=', 80).
To me, it seems like the underlying issue here is that gcc does not warn for
implicit conversion from int to char. Whenever I assign a literal to a char, I
always assign something wrapped in single quotes, never an integer literal.
However, I would suggest that perhaps this warning should have two levels. The
first level would only warn for char. The second level would warn for char,
signed char, and unsigned char. The reason for this separation is that int8_t
is a typedef for signed char and uint8_t is a typedef for unsigned char (on
most platforms), and those are regularly used as small integers (I use them
extensively in space-sensitive code). My experience is that when people use a
signed / unsigned char explicitly, or one of the typedefs in cstdint /
stdint.h, they are not used as actual characters, but bytes / small numbers,
and in that case, assigning from an integer wouldn't be incorrect.
[Bug c/46480] [trans-mem] Uninstrumented code path is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46480 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-11-09 18:50:02 UTC --- Implemented on mainline. Yay yay!
[Bug other/52438] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 19:38:36 UTC --- (In reply to comment #2) FSF not (only) copyright holder (so can't change license?): * gcc/ada/s-osinte-kfreebsd-gnu.ads * gcc/ada/s-osinte-rtems.adb * gcc/ada/s-taspri-lynxos.ads * gcc/ada/s-tpopsp-rtems.adb Pure oversight, all other similar files were changed. These files still have the GPLv2 header, but with or later. All other files have the GPLv3 header now, so this is FIXED.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2012-11-09
19:42:30 UTC ---
Here is the insn in question:
(insn 26 25 27 2 (set (reg:TI 115 [orig:100 *defsym_17 ] [100])
(mem:TI (zero_extend:DI (reg:SI 98)) [7 *defsym_17+0 S16 A32])) h.i:54
61 {*movti_internal_rex64}
As I understand the first alternative has ! to strongly encourage to use SSE
instead of GENERAL registers.
(define_insn *movti_internal_rex64
[(set (match_operand:TI 0 nonimmediate_operand =!r ,o ,x,x ,m)
(match_operand:TI 1 general_operand riFo,riF,C,xm,x))]
TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1]))
For some reasons, the second alternative does not have !. I don't know why it
is different from the first alternative.
For reload it works as it already substituted hard register for the first
operand and in this case it rejects
the 2nd alternative.
(insn 26 25 27 2 (set (reg:TI 0 ax [orig:100 *defsym_17 ] [100])
(mem:TI (zero_extend:DI (reg:SI 2 cx [98])) [7 *defsym_17+0 S16 A32]))
h.i:54 61 {*movti_internal_rex64}
Adding ! for the second alternative (as I believe it should be) solves the
problem.
(define_insn *movti_internal_rex64
[(set (match_operand:TI 0 nonimmediate_operand =!r ,!o ,x,x ,m)
(match_operand:TI 1 general_operand riFo,riF,C,xm,x))]
TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1]))
Uros, is this change ok for you? If it is ok I can commit the patch only on
Wednesday (I'll be away for a few days).
[Bug tree-optimization/54916] [4.8 Regression] wrong code with -O2 -funroll-loops -fno-rerun-cse-after-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54916 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 19:43:43 UTC --- The issue here was a bad REG_EQUAL note. This was fixed some time ago.
[Bug fortran/55255] New: Compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55255 Bug #: 55255 Summary: Compiler segmentation fault Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: everettyou.inter...@gmail.com * version: 4.6.2 20111019 (prerelease) (GCC) * system type: Mac OS 10.7.4 * built command: gfortran -o BUG BUG.f90 -save-temps -J ./build * bug behavior: compiler throws internal compiler error: Segmentation fault * source files: BUG.f90 ! --- MODULE MY_ARRAY TYPE ARRAY REAL, ALLOCATABLE :: VALS(:) END TYPE ARRAY CONTAINS FUNCTION MAKE_ARRAY(X) RESULT(Y) REAL, INTENT(IN) :: X(:) TYPE(ARRAY) :: Y Y%VALS = X END FUNCTION MAKE_ARRAY SUBROUTINE PRINT_ARRAY(Y) TYPE(ARRAY), INTENT(IN) :: Y PRINT *, Y%VALS END SUBROUTINE PRINT_ARRAY END MODULE MY_ARRAY PROGRAM MAIN USE MY_ARRAY CALL PRINT_ARRAY(MAKE_ARRAY((/1.,2./))) END PROGRAM MAIN ! --
[Bug preprocessor/55242] continued lines not always merged into one long line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55242 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2012-11-09 20:23:47 UTC --- It's a feature, not a bug (see PR41748, PR45696, and PR48383). Perhaps it should be mentioned in the preprocessor documentation.
[Bug testsuite/55230] UNSUPPORTED: g++.dg/mv1.C -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55230
--- Comment #1 from Sriraman Tallam tmsriram at google dot com 2012-11-09
20:31:41 UTC ---
(In reply to comment #0)
Caused by:
http://gcc.gnu.org/viewcvs?view=revisionrevision=193204
/* { dg-do run { target i?86-*-* x86_64-*-* } } */
/* { dg-require-ifunc } */
If these tests are x86-x86_64 specific, they should be in the target-specific
directory presumably?
Thanks,
Kyrill
I dont see any C++ tests in gcc.target. I also see other C++ tests doing the
same thing in g++.dg, example:
testsuite/g++.dg/pr45788.C:// { dg-do compile { target x86_64-*-* } }
Alright?
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||dodji at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-09 21:02:20 UTC --- I think this his how the macro expansion was designed to work: It shows the location of the token that triggered the error. I also agree that the clang way makes more sense in this case.
[Bug fortran/55255] [4.6 Regression] Compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55255 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||janus at gcc dot gnu.org Summary|Compiler segmentation fault |[4.6 Regression] Compiler ||segmentation fault Ever Confirmed|0 |1 Severity|critical|normal --- Comment #1 from janus at gcc dot gnu.org 2012-11-09 21:19:45 UTC --- I can confirm the error with: gcc version 4.6.0 20110505 [gcc-4_6-branch revision 173419] (SUSE Linux) However, all other versions I tried compile the test case correctly (including 4.3, 4.5, 4.7 and trunk).
[Bug middle-end/41004] missed merge of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
Target Milestone|--- |4.8.0
Known to fail||4.8.0
--- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09
21:38:39 UTC ---
Resulting code from trunk r193358
primal_update_flow:
push{r4, r5, lr}
mov r3, #1
mov r4, #0
.L2:
cmp r0, r2
beq .L11
ldr r5, [r0]
cmp r5, #0
beq .L3
str r4, [r0, #8]
b .L4
.L3:
str r3, [r0, #8]
.L4:
ldr r0, [r0, #4]
b .L2
.L11:
mov r0, #1
.L6:
cmp r1, r2
beq .L12
ldr r3, [r1]
cmp r3, #0
beq .L7
str r0, [r1, #8]
b .L8
.L7:
str r3, [r1, #8]
.L8:
ldr r1, [r1, #4]
b .L6
.L12:
@ sp needed
pop {r4, r5, pc}
So the issue of comment #0 is fixed.
With -march=armv7 -mthumb the stores to [r0,#8] and [r0,#8] are
properly if-converted, I don't see anything that could be improved
further. So, fixed.
[Bug other/52438] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-09 21:42:06 UTC --- Author: ebotcazou Date: Fri Nov 9 21:42:02 2012 New Revision: 193375 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193375 Log: PR other/52438 * s-taspri-lynxos.ads: Delete. * s-osinte-kfreebsd-gnu.ads: Change license to GPL V3+. * s-tpopsp-rtems.adb: Likewise. * s-osinte-rtems.adb: Likewise. Removed: trunk/gcc/ada/s-taspri-lynxos.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-rtems.adb trunk/gcc/ada/s-tpopsp-rtems.adb
[Bug other/52438] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-09 21:42:25 UTC --- Author: ebotcazou Date: Fri Nov 9 21:42:21 2012 New Revision: 193376 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193376 Log: PR other/52438 * s-taspri-lynxos.ads: Delete. * s-osinte-kfreebsd-gnu.ads: Change license to GPL V3+. * s-tpopsp-rtems.adb: Likewise. * s-osinte-rtems.adb: Likewise. Removed: branches/gcc-4_7-branch/gcc/ada/s-taspri-lynxos.ads Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/s-osinte-kfreebsd-gnu.ads branches/gcc-4_7-branch/gcc/ada/s-osinte-rtems.adb branches/gcc-4_7-branch/gcc/ada/s-tpopsp-rtems.adb
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
--- Comment #26 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-09
21:44:16 UTC ---
I've tried enabling sched1 on rev 193341 and ran the test suite with
make -k -j4 check
RUNTESTFLAGS=--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
I got one failure for -m2a, -m4 -m4a (both, -ml and -mb):
FAIL: gcc.dg/pr42475.c (internal compiler error)
The error is:
sh_tmp.cpp: In function 'baz':
sh_tmp.cpp:25:1: error: unable to find a register to spill in class 'R0_REGS'
}
^
sh_tmp.cpp:25:1: error: this is the insn:
(insn 18 31 42 2 (parallel [
(set (subreg:SF (reg:SI 1 r1 [orig:174 D.1383+4 ] [174]) 0)
(mult:SF (reg:SF 171)
(reg:SF 65 fr1 [orig:170 p.c.z ] [170])))
(use (reg/v:PSI 151 ))
]) sh_tmp.cpp:24 426 {mulsf3_i}
(expr_list:REG_DEAD (reg:SF 171)
(expr_list:REG_DEAD (reg:SF 65 fr1 [orig:170 p.c.z ] [170])
(expr_list:REG_DEAD (reg/v:PSI 151 )
(nil)
sh_tmp.cpp:25:1: internal compiler error: in spill_failure, at reload1.c:2124
A GP reg is supposed to receive the result of an FP operation, which the SH
actually can't do. It has to go through FPUL.
The error occurs because sched1 hoists a load of r0 (part of the return value)
before the failing insn:
(insn 31 15 18 2 (set (reg:SI 0 r0)
(const_int 0 [0])) sh_tmp.cpp:25 244 {movsi_ie}
(nil))
(insn 18 31 42 2 (parallel [
(set (subreg:SF (reg:SI 174 [ D.1383+4 ]) 0)
(mult:SF (reg:SF 170 [ p.c.z ])
(reg:SF 171)))
The result value transfer from FP reg to GP reg (through FPUL) seems to go a
long way during reload, and one the insns that reload checks has a R0 clobber
(not sure which one, but there are a couple of reload insns with a =z
constraint).
On option to fix this is to split such insns. The patch below fixes the test
case failure, but I haven't re-tested it completely.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md(revision 193342)
+++ gcc/config/sh/sh.md(working copy)
@@ -12077,6 +12077,32 @@
[(set_attr type fp)
(set_attr fp_mode single)])
+;; If the output of a floating-point operation is to be stored in a GP reg
+;; the target GP output reg might be propagated as a subreg into floating-
+;; point insns. If we split the operation and the GP reg store
+;; (through FPUL) into separate insns before reload some trouble can be
+;; avoided during reload.
+(define_split
+ [(set (match_operand:SF 0 fp_arith_reg_operand)
+(match_operator:SF 1 float_operator
+ [(match_operand:SF 2 fp_arith_reg_operand)
+ (match_operand:SF 3 fp_arith_reg_operand)]))
+ (use (match_operand:PSI 4 fpscr_operand))]
+ TARGET_SH2E
+can_create_pseudo_p () GET_CODE (operands[0]) == SUBREG
+REG_P (SUBREG_REG (operands[0]))
+GET_MODE (SUBREG_REG (operands[0])) != SFmode
+ [(parallel [(set (match_dup 5) (match_dup 6))
+ (use (match_dup 4))])
+ (parallel [(set (match_dup 0) (match_dup 5))
+ (use (match_dup 4))
+ (clobber (reg:SI FPUL_REG))])]
+{
+ operands[5] = gen_reg_rtx (SFmode);
+ operands[6] = gen_rtx_fmt_ee (GET_CODE (operands[1]), SFmode, operands[2],
+operands[3]);
+})
+
;; FMA (fused multiply-add) patterns
(define_expand fmasf4
[(set (match_operand:SF 0 fp_arith_reg_operand )
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md(revision 193342)
+++ gcc/config/sh/predicates.md(working copy)
@@ -1156,3 +1156,9 @@
return false;
})
+
+(define_predicate float_operator
+ (ior (match_operand 0 binary_float_operator)
+ (match_operand 0 commutative_float_operator)
+ (match_operand 0 noncommutative_float_operator)
+ (match_operand 0 unary_float_operator)))
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 193342)
+++ gcc/config/sh/sh.c(working copy)
@@ -877,6 +877,7 @@
|| (TARGET_SHMEDIA !TARGET_PT_FIXED))
flag_no_function_cse = 1;
+#if 0
if (targetm.small_register_classes_for_mode_p (VOIDmode))\
{
/* Never run scheduling before reload, since that can
@@ -903,6 +904,7 @@
!global_options_set.x_flag_schedule_insns)
flag_schedule_insns = 0;
}
+#endif
/* Unwind info is not correct around the CFG unless either a frame
pointer is present or M_A_O_A is set. Fixing this requires rewriting
[Bug testsuite/55229] UNRESOLVED: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunroll Unrolled loop 1 completely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55229 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 Ever Confirmed|0 |1 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:03:51 UTC --- Fails on powerpc64 too.
[Bug fortran/55255] [4.6 Regression] Compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55255 --- Comment #2 from janus at gcc dot gnu.org 2012-11-09 22:05:20 UTC --- Slightly reduced test case: MODULE MY_ARRAY TYPE ARRAY REAL, ALLOCATABLE :: VALS END TYPE CONTAINS TYPE(ARRAY) FUNCTION MAKE_ARRAY() END FUNCTION SUBROUTINE PRINT_ARRAY(Y) TYPE(ARRAY) :: Y END SUBROUTINE END MODULE PROGRAM MAIN USE MY_ARRAY CALL PRINT_ARRAY(MAKE_ARRAY()) END PROGRAM MAIN
[Bug middle-end/54961] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |--- Summary|[4.8 Regression] FAIL: |FAIL: gfortran.dg/pr48757.f |gfortran.dg/pr48757.f -O | -O (internal compiler |(internal compiler error) |error) after revision |after revision 192440 |192440
[Bug target/28968] gcc/config/i386/winnt-stubs.c is not linked in - build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:17:30 UTC --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00011.html
[Bug bootstrap/15212] [4.6/4.7/4.8 Regression] bootstrap fails on interix3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||rupp at gnat dot com Known to fail|| --- Comment #44 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:22:35 UTC --- Douglas, could you, as the de facto interix maintainer, please have a look at the patches in comment #31, comment #36, and comment #37?
[Bug target/15184] [4.6/4.7/4.8 Regression] Direct access to byte inside word not working with -march=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Priority|P5 |P3 Last reconfirmed|2005-05-28 18:17:13 |2012-11-09 18:17:13 CC||steven at gcc dot gnu.org Known to fail|| --- Comment #20 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:32:30 UTC --- (In reply to comment #13) This is indeed pretty bad. Works with GCC 4.1, fails with GCC 4.3 and with current top-of-trunk, and for all i686 variants including relatively new CPUs based on the P6 micro-architecture, like core2 and atom. I disagree with comment #10, and I don't think this problem is minor. The code of the test case is common idiom that should be optimized properly. Please can the RMs have a new look at this.
[Bug libgcj/21714] [4.6/4.7/4.8 Regression] libjava bootstrap failure in java/lang/natConcreteProcess.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21714 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #16 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:34:33 UTC --- Let's be realistic about this: WONTFIX.
[Bug c++/22488] [4.6/4.7/4.8 Regression] push_fields_onto_fieldstack calculates offset incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||alias Status|ASSIGNED|WAITING CC|dberlin at gcc dot gnu.org, | |gcc-bugs at gcc dot | |gnu.org, mark at| |codesourcery dot com| --- Comment #55 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:37:34 UTC --- -ENOPROGRESS What is the status of this bug, Jason?
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
--- Comment #27 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-09
22:41:15 UTC ---
(In reply to comment #26)
Another way that fixes the problem mentioned above is to not allow non-float
mode operands in the first place. The patch below also fixes the failure, but
requires some more work to be complete.
A strange thing I've noticed:
(define_expand addsf3
[(set (match_operand:SF 0 arith_reg_operand )
(plus:SF (match_operand:SF 1 arith_reg_operand )
(match_operand:SF 2 arith_reg_operand )))]
TARGET_SH2E || TARGET_SHMEDIA_FPU
It seems there should be a prefix fp_ in the operand predicate names.
Anyway ..
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md(revision 193342)
+++ gcc/config/sh/predicates.md(working copy)
@@ -319,16 +319,23 @@
if (register_operand (op, mode))
{
int regno;
+ machine_mode m;
if (REG_P (op))
-regno = REGNO (op);
+{
+ regno = REGNO (op);
+ m = GET_MODE (op);
+}
else if (GET_CODE (op) == SUBREG REG_P (SUBREG_REG (op)))
-regno = REGNO (SUBREG_REG (op));
+{
+ regno = REGNO (SUBREG_REG (op));
+ m = GET_MODE (SUBREG_REG (op));
+}
else
return 1;
- return (regno = FIRST_PSEUDO_REGISTER
- || FP_REGISTER_P (regno));
+ return (regno = FIRST_PSEUDO_REGISTER || FP_REGISTER_P (regno))
+ GET_MODE_CLASS (m) == MODE_FLOAT;
}
return 0;
})
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 193342)
+++ gcc/config/sh/sh.c(working copy)
@@ -876,7 +876,7 @@
if ((flag_pic ! TARGET_PREFERGOT)
|| (TARGET_SHMEDIA !TARGET_PT_FIXED))
flag_no_function_cse = 1;
-
+#if 0
if (targetm.small_register_classes_for_mode_p (VOIDmode))\
{
/* Never run scheduling before reload, since that can
@@ -903,6 +903,7 @@
!global_options_set.x_flag_schedule_insns)
flag_schedule_insns = 0;
}
+#endif
/* Unwind info is not correct around the CFG unless either a frame
pointer is present or M_A_O_A is set. Fixing this requires rewriting
@@ -10069,6 +10070,9 @@
void
expand_sf_binop (rtx (*fun) (rtx, rtx, rtx, rtx), rtx *operands)
{
+ operands[0] = force_reg (SFmode, operands[0]);
+ operands[1] = force_reg (SFmode, operands[1]);
+ operands[2] = force_reg (SFmode, operands[2]);
emit_sf_insn ((*fun) (operands[0], operands[1], operands[2],
get_fpscr_rtx ()));
}
[Bug tree-optimization/23835] [4.6/4.7/4.8 Regression] -O3 compile takes two times longer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #35 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:46:30 UTC --- This bug is no longer relevant, the IA64 scheduler at -O3 has been replaced completely (by the selective scheduler) and the remaining non-scheduler slowdowns are all due to inherently non-linear algorithms, downsides that you just get along with the benefits of SSA. So WONTFIX.
[Bug target/24334] [4.6/4.7/4.8 regression] IRIX 6.5 bootstrap failure with SGI 7.4.6/4.7/4.8m ld: GOT overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24334 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #16 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:49:09 UTC --- IRIX support has been removed for GCC 4.8, and will not be fixed on the open release branches.
[Bug java/24698] [4.6/4.7/4.8 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #26 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 22:52:39 UTC --- No feedback since January on this really old bug - resolved (as INVALID for lack of a better option).
[Bug target/27855] [4.5/4.7/4.8 regression] reassociation causes the RA to be confused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855 --- Comment #42 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:06:18 UTC --- It'd be interesting to get some new timings, with the new register-pressure aware scheduling and with LRA. Oh, and maybe with the patch to restrain the reassoc pass a bit (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02122.html).
[Bug target/29206] [4.6/4.7/4.8 regression] gcj-dbtool segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID --- Comment #21 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:07:43 UTC --- No response.
[Bug testsuite/55229] [4.8 Regression] FAIL: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunroll Unrolled loop 1 completely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55229 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-09 23:09:58 UTC --- Universal; at least i686-, x86_64-linux and cris-elf too. I wonder where this passes...
[Bug tree-optimization/32306] [4.6/4.7/4.8 Regression] redundant || not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306 --- Comment #22 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:13:53 UTC --- (In reply to comment #19) Shorter testcase, compilable and to the point. We are not able to CSE the b1 ... b8 sequence because we produce control-flow for it during gimplification. Do you know why that is so?
[Bug target/38642] [4.6/4.7/4.8 Regression] Code with -fPIC results in segfault on ARM (old ABI)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:17:01 UTC --- Old ABI is no longer supported
[Bug libgcj/40180] [4.6/4.7/4.8 regression] regressions in libjava testsuite on ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED Known to fail|| --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:18:57 UTC --- Fixed somewhere along the way. http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00811.html
[Bug java/43302] [Regression] gcc creates dummy resources in object files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43302 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:21:02 UTC --- If it comes from ecj, it's not a gcc bug.
[Bug java/42143] [4.6/4.7/4.8 Regression] gcj creates dummy variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID Known to fail|| --- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:21:27 UTC --- If it comes from ecj, it's not a gcc bug. (see bug 43302)
[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:26:36 UTC --- .
[Bug preprocessor/55256] New: Out of memory preprocessing nested tgmath.h functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55256
Bug #: 55256
Summary: Out of memory preprocessing nested tgmath.h functions
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: net...@gmail.com
#include tgmath.h
int main(void) { sqrt(sqrt(sqrt(sqrt(1; }
cc1 runs out of memory. This problem has been observed with GCC 4.7.2 on Arch
Linux 32-bit and Linaro GCC 4.7.2 on Ubuntu 12.10 32-bit. It was started
occurring from around GCC 4.7.0.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.2 (GCC)
[Bug other/51937] [meta-bug] GCC 4.8 pending patches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51937 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:27:19 UTC --- Nothing is pending anymore.
[Bug middle-end/34226] [4.6/4.7/4.8 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||steven at gcc dot gnu.org Resolution||WORKSFORME --- Comment #21 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:32:29 UTC --- Doesn't ice for me at trunk r193358.
[Bug middle-end/21953] [4.6/4.7/4.8 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #20 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:34:39 UTC --- Tru64 v5.1 is no longer supported as of GCC 4.8.
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:40:48 UTC --- Fixed by revert.
[Bug rtl-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54942 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 23:42:48 UTC --- Fixed along the way, probably by one of Honza's many patches in this area.
[Bug target/29206] [4.6/4.7/4.8 regression] gcj-dbtool segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 --- Comment #22 from dave.anglin at bell dot net 2012-11-10 01:28:52 UTC --- If possible, I think SJLJ support should go. I can't remember the exact status of SJLJ for HP-UX 10 but a comment in hpux-unwind.h suggests that I tested dwarf2 support. I can check but it will take time. Dave -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 01:32:06 UTC --- There are 2 issues here: 1. Should we use movdqu(%eax), %xmm0# 19*movti_internal_rex64/4[length = 5] movdqa%xmm0, (%rsp)# 29*movti_internal_rex64/5[length = 5] to copy 16 bytes? 2. Should we split *movti_internal_rex64 if -mno-sse is used?
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 01:39:16
UTC ---
We don't properly handle memory operand in
(insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
(mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
{*movti_internal_rex64}
(expr_list:REG_DEAD (reg:SI 82)
(expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 sym+0 S16 A64])
[Bug debug/55257] New: [4.8 Regression]: g++.dg/debug/dwarf2/non-virtual-thunk.C scan-assembler thunk.C:30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55257 Bug #: 55257 Summary: [4.8 Regression]: g++.dg/debug/dwarf2/non-virtual-thunk.C scan-assembler thunk.C:30 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Created attachment 28649 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28649 non-virtual-thunk.s This test previously passed, now it fails. A patch in the revision range (last_known_working:first_known_failing) 19:193342 exposed or caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp ... FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 scan-assembler thunk.C:30 FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++11 scan-assembler thunk.C:30 No extra clue in g++.log. Executing on host: /tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../g++ -B/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../ /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/debug/dwarf2/non-virtual-thunk.C -fno-diagnostics-show-caret -nostdinc++ -I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/libsupc++ -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/include/backward -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -g2 -dA -ffat-lto-objects -S -isystem /tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc0/gcc/newlib/libc/include -o non-virtual-thunk.s (timeout = 300) PASS: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 scan-assembler thunk.C:30 (same for -std=gnu++11) There's no thunk.C:30 in the assembly file, just lots of: TAB;# /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/debug/dwarf2/non-virtual-thunk.C:33 See the attached non-virtual-thunk.s. Author of suspect patch in revision range CC:ed.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 01:58:31 UTC --- We fail to see (mem:TI (zero_extend:DI (reg:SI 82))) is offsettable.
[Bug target/55258] New: SSE register isn't used for 16byte copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55258
Bug #: 55258
Summary: SSE register isn't used for 16byte copy
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
[hjl@gnu-tools-1 pr55247]$ cat x.i
typedef unsigned int uint32_t;
typedef uint32_t Elf32_Word;
typedef uint32_t Elf32_Addr;
typedef struct {
Elf32_Word st_name;
Elf32_Addr st_value;
Elf32_Word st_size;
unsigned char st_other;
} Elf32_Sym;
typedef struct {
Elf32_Word r_info;
}
Elf32_Rela;
typedef struct {
union {
Elf32_Addr d_ptr;
}
d_un;
} Elf32_Dyn;
struct link_map {
Elf32_Dyn *l_info[34];
};
extern void symbind32 (Elf32_Sym *);
void
_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
{
const Elf32_Sym *const symtab = (const void *) l-l_info[6]-d_un.d_ptr;
const Elf32_Rela *const reloc = (const void *) (l-l_info[23]-d_un.d_ptr +
reloc_arg * sizeof (Elf32_Rela));
Elf32_Sym sym = symtab[(reloc-r_info) 8];
symbind32 (sym);
}
[hjl@gnu-tools-1 pr55247]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -Wall -mx32
-maddress-mode=short -S x.i -o short.asm
[hjl@gnu-tools-1 pr55247]$ cat short.asm
.filex.i
.text
.globl_dl_profile_fixup
.type_dl_profile_fixup, @function
_dl_profile_fixup:
.LFB0:
.cfi_startproc
subl$24, %esp
.cfi_def_cfa_offset 32
movl24(%edi), %edx
movl92(%edi), %eax
movl(%eax), %eax
movl(%eax,%esi,4), %eax
shrl$8, %eax
sall$4, %eax
addl(%edx), %eax
movq8(%eax), %rdx
movq(%eax), %rax
movq%rax, (%esp)
movq%rdx, 8(%esp)
movl%esp, %edi
callsymbind32
addl$24, %esp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size_dl_profile_fixup, .-_dl_profile_fixup
.identGCC: (GNU) 4.8.0 20121110 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-tools-1 pr55247]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -Wall -mx32
-maddress-mode=long -S x.i -o long.asm
[hjl@gnu-tools-1 pr55247]$ cat long.asm
.filex.i
.text
.globl_dl_profile_fixup
.type_dl_profile_fixup, @function
_dl_profile_fixup:
.LFB0:
.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movl24(%rdi), %edx
movl92(%rdi), %eax
movl(%rax), %eax
movl(%eax,%esi,4), %eax
shrl$8, %eax
sall$4, %eax
addl(%rdx), %eax
movdqu(%eax), %xmm0
movdqa%xmm0, (%rsp)
movq(%rsp), %rax
movq8(%rsp), %rdx
movq%rax, 16(%rsp)
movq%rdx, 24(%rsp)
leaq16(%rsp), %rdi
callsymbind32
addq$40, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size_dl_profile_fixup, .-_dl_profile_fixup
.identGCC: (GNU) 4.8.0 20121110 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-tools-1 pr55247]$
For TARGET_SSE_UNALIGNED_LOAD_OPTIMAL/TARGET_SSE_UNALIGNED_STORE_OPTIMAL,
we should always generate
movdqu(%eax), %xmm0
movdqa%xmm0, (%rsp)
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 02:30:16
UTC ---
Something like this:
diff --git a/gcc/explow.c b/gcc/explow.c
index 6109832..9ec38f9 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -84,12 +84,22 @@ plus_constant (enum machine_mode mode, rtx x, HOST_WIDE_INT
c)
rtx y;
rtx tem;
int all_constant = 0;
+ enum machine_mode zero_extend_mode;
gcc_assert (GET_MODE (x) == VOIDmode || GET_MODE (x) == mode);
if (c == 0)
return x;
+ if (GET_CODE (x) == ZERO_EXTEND)
+{
+ zero_extend_mode = GET_MODE (x);
+ x = XEXP (x, 0);
+ mode = GET_MODE (x);
+}
+ else
+zero_extend_mode = VOIDmode;
+
restart:
code = GET_CODE (x);
@@ -195,7 +205,11 @@ plus_constant (enum machine_mode mode, rtx x,
HOST_WIDE_INT
c)
else if (all_constant)
return gen_rtx_CONST (mode, x);
else
-return x;
+{
+ if (zero_extend_mode != VOIDmode)
+x = gen_rtx_ZERO_EXTEND (zero_extend_mode, x);
+ return x;
+}
}
^L
/* If X is a sum, return a new sum like X but lacking any constant terms.
diff --git a/gcc/recog.c b/gcc/recog.c
index ee68e30..d3dd591 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -1934,15 +1934,21 @@ int
offsettable_address_addr_space_p (int strictp, enum machine_mode mode, rtx y,
addr_space_t as)
{
- enum rtx_code ycode = GET_CODE (y);
+ enum rtx_code ycode;
rtx z;
- rtx y1 = y;
+ rtx y1;
rtx *y2;
int (*addressp) (enum machine_mode, rtx, addr_space_t) =
(strictp ? strict_memory_address_addr_space_p
: memory_address_addr_space_p);
unsigned int mode_sz = GET_MODE_SIZE (mode);
+ if (GET_CODE (y) == ZERO_EXTEND)
+y = XEXP (y, 0);
+
+ ycode = GET_CODE (y);
+ y1 = y;
+
if (CONSTANT_ADDRESS_P (y))
return 1;
[Bug middle-end/55259] New: plus_constant doesn't handle zero-extended address properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55259 Bug #: 55259 Summary: plus_constant doesn't handle zero-extended address properly Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com For address, #0 plus_constant (mode=SImode, x=0x70fadf40, c=8) at /export/gnu/import/git/gcc/gcc/explow.c:211 #1 0x006f9b04 in adjust_address_1 (memref=0x70fff2e8, mode=DImode, offset=8, validate=1, adjust_address=1, adjust_object=0) at /export/gnu/import/git/gcc/gcc/emit-rtl.c:2113 #2 0x00cdd259 in split_double_mode (mode=TImode, operands=0x7fffd828, num=0, lo_half=0x7fffd8f0, hi_half=0x7fffd8f8) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:14721 #3 0x00ceafe7 in ix86_split_to_parts (operand=0x70fff2e8, parts=0x7fffd8f0, mode=TImode) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:20695 #4 0x00ceb4ad in ix86_split_long_move ( operands=0x17a5fa0 recog_data) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:20794 Breakpoint 2, plus_constant (mode=DImode, x=0x70fadf30, c=8) at /export/gnu/import/git/gcc/gcc/explow.c:96 96 zero_extend_mode = GET_MODE (x); (gdb) call debug_rtx (x) (zero_extend:DI (reg:SI 0 ax [82])) (gdb) it should generate (gdb) call debug_rtx (x) (zero_extend:DI (plus:SI (reg:SI 0 ax [82]) (const_int 8 [0x8]))) (gdb) Instead, plus_constant generates (gdb) call debug_rtx (addr) (plus:DI (zero_extend:DI (reg:SI 0 ax [82])) (const_int 8 [0x8]))
[Bug c++/55249] [4.6/4.7/4.8 Regression] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.5 Target Milestone|--- |4.6.4 Known to fail||4.7.0 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10 03:59:08 UTC --- Note with the reduced testcase to compile in C++98 mode, you have to do s// /.
[Bug middle-end/55259] plus_constant doesn't handle zero-extended address properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55259
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 04:13:32
UTC ---
A potential fix:
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 95bbfa7..d7c454c 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2109,6 +2109,12 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOS
T_WIDE_INT offset,
addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
plus_constant (address_mode,
XEXP (addr, 1), offset));
+ else if (GET_CODE (addr) == ZERO_EXTEND)
+{
+ addr = XEXP (addr, 0);
+ addr = plus_constant (GET_MODE (addr), addr, offset);
+ addr = gen_rtx_ZERO_EXTEND (address_mode, addr);
+}
else
addr = plus_constant (address_mode, addr, offset);
}
[Bug middle-end/54242] [4.8 Regression] FAIL: gcc.target/i386/pad-10.c scan-assembler-not nop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54242 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-09 08:43:00 UTC --- Fixed by 2012-09-30 Uros Bizjak ubiz...@gmail.com * gcc.target/i386/pad-10.c (foo2): Return x - z.
[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling the small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|Compiler segfault when |[4.6/4.7/4.8 Regression] |compiling the small test|Compiler segfault when |case|compiling the small test ||case Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-09 09:06:25 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=170853 aka PR48029 fix.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #31 from Tobias Schlüter tobi at gcc dot gnu.org 2012-11-09 09:43:56 UTC --- (In reply to comment #30) (In reply to comment #29) I committed the C-only version of the patch as the issues mentioned in comment #27 couldn't be addressed before stage3. Thanks Tobi! I have been using your C-only patch for a couple of weeks now for the 4.7 branch, and it is greatly improving our edit/compile-cycles. For one of my students, it yields an effective 10x speedup in building CP2K after a typical code change, greatly facilitating the programming project he is on. I would suggest that after a couple of weeks on trunk, this should be reconsidered again for backporting to 4.7. Good to hear that. If you can use the additional free time to walk over to my brother's office, then please say 'Hi' to him. Otherwise the faculty meeting will have to do :-) As for the backport, I think the patch is absolutely risk-free, and it should have been approved for 4.7 even though it doesn't fulfill the formal requirements. I think it's worth another try once it's not only saved ethz.ch a lot of electricity but also survived for some time on the 4.8 branch. Please ping the patch in a few weeks so it's not forgotten. I also put a note into my calendar.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #32 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-11-09 10:05:18 UTC --- If you can use the additional free time to walk over to my brother's office, then please say 'Hi' to him. Otherwise the faculty meeting will have to do :-) Let's call it a small world... I will meet him next week.
[Bug target/55246] Define a macro for 16*1024*1024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55246 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-09 10:07:01 UTC --- This occurred to me as well.
[Bug c++/55249] New: Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249
Bug #: 55249
Summary: Multiple copy constructors for template class lead to
link errors
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antosh...@gmail.com
Created attachment 28647
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28647
gcc -v -save-temps -std=c++0x -Wall -Wextra main.cpp 1output.txt 21
Following code leads to linker errors in C++11 mode and in default mode
(requires replacement of std::array with boost::array):
#include array
#include vector
template class TypeT
struct inner_type {
inner_type() {}
inner_type(inner_type ) {}
inner_type(const inner_type ) {}
~inner_type() {}
};
// Uncomment typedef to get undefined reference to
// __uninitialized_copyILb0EE13__uninit_copy
// Can be workaround by marking inner_type copy constructors with noexcept
//typedef std::vectorstd::arrayinner_typeint, 3 type;
// Uncomment typedef to get undefined reference to
// `inner_typeint::inner_type(inner_typeint const)'
//typedef std::arrayinner_typeint, 3 type;
int main()
{
type t1;
type t2 = t1;
return 0;
}
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 --- Comment #1 from Antony Polukhin antoshkka at gmail dot com 2012-11-09 10:24:49 UTC --- Created attachment 28648 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28648 Preprocessed file that triggers the bug
[Bug rtl-optimization/55221] [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221 --- Comment #2 from Anton Shterenlikht mexas at bristol dot ac.uk 2012-11-09 10:40:41 UTC --- On the same system I can build gcc-4.8.0.20121014
[Bug rtl-optimization/55221] [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221 --- Comment #3 from Anton Shterenlikht mexas at bristol dot ac.uk 2012-11-09 10:47:22 UTC --- forgot to add, all these builds are with a patch to unwind-ia64.h. For example, for 4.8 branch, the patch is (credit to ger...@freebsd.org): Index: libgcc/config/ia64/unwind-ia64.h === --- libgcc/config/ia64/unwind-ia64.h +++ libgcc/config/ia64/unwind-ia64.h(working copy) @@ -49,4 +49,7 @@ extern struct unw_table_entry * _Unwind_FindTableEntry (void *pc, unw_word *segment_base, unw_word *gp, struct unw_table_entry *ent) - __attribute__ ((__visibility__ (hidden))); +#ifndef __FreeBSD__ + __attribute__ ((__visibility__ (hidden))) +#endif + ;
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #26 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-09 10:48:17 UTC --- (In reply to comment #25) Maybe the better solution would indeed be to add a arith - logical shift conversion pass before combine, or try to convert arith shifts in the split pass after combine by looking at the data flow of the shifted values. Another idea would be to extend the combine pass, so that whenever it internally converts arith - logical shifts, it always checks the costs of the shift op, and if the logical shift is cheaper, always split out the logical shift.
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-09 CC|antoshkka at gmail dot com | Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-09 10:53:06 UTC --- We need a self contained reduced testcase for this.
[Bug lto/54966] Does LTO requires a larger inline-unit-growth?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966 --- Comment #10 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-11-09 11:33:37 UTC --- I've repeated the tests again on a different machine and the result are the same gcc version 4.8.0 20121108 (experimental) [trunk revision 19] (GCC) at O3 lto degrades the performances in two cases, improves in another… at O2 lto just degrades performance for two cases (different than O3) and does not improve for the others with Ofast the differences are even more dramatic [innocent@vinavx0 bugs48]$ c++ -Ofast smatrix.ii -march=native -flto ; taskset -c 2 ./a.out size 5. v1: time in cycles 14255.6 size 5. v2: time in cycles 3699.28 size 5. v3: time in cycles 3715.55 size 6. v1: time in cycles 9179.85 size 6. v2: time in cycles 1906.91 size 6. v3: time in cycles 1812.73 [innocent@vinavx0 bugs48]$ c++ -Ofast smatrix.ii -march=native ; taskset -c 2 ./a.out size 5. v1: time in cycles 13933.9 size 5. v2: time in cycles 2125.56 size 5. v3: time in cycles 1028.43 size 6. v1: time in cycles 28168 size 6. v2: time in cycles 3528.72 size 6. v3: time in cycles 2533.5 c++ -O3 smatrix.ii -march=native; taskset -c 2 ./a.out size 5. v1: time in cycles 13896.1 size 5. v2: time in cycles 2107.25 size 5. v3: time in cycles 1647.42 size 6. v1: time in cycles 31095.6 size 6. v2: time in cycles 3862.43 size 6. v3: time in cycles 3510.14 c++ -O3 smatrix.ii -march=native -flto; ./a.out size 5. v1: time in cycles 16183.5 size 5. v2: time in cycles 3696.15 size 5. v3: time in cycles 3698.27 size 6. v1: time in cycles 36323.5 size 6. v2: time in cycles 2799.47 size 6. v3: time in cycles 2705.73 [innocent@vinavx0 bugs48]$ taskset -c 2 ./a.out size 5. v1: time in cycles 16150.1 size 5. v2: time in cycles 3718.54 size 5. v3: time in cycles 3784.38 size 6. v1: time in cycles 36326.3 size 6. v2: time in cycles 2785.33 size 6. v3: time in cycles 2714.69 c++ -O2 smatrix.ii -march=native -flto ; taskset -c 2 ./a.out size 5. v1: time in cycles 13809.2 size 5. v2: time in cycles 3999.39 size 5. v3: time in cycles 4186.2 size 6. v1: time in cycles 35057.3 size 6. v2: time in cycles 4657.59 size 6. v3: time in cycles 4766.62 c++ -O2 smatrix.ii -march=native; taskset -c 2 ./a.out size 5. v1: time in cycles 11300.6 size 5. v2: time in cycles 2877.27 size 5. v3: time in cycles 2947.01 size 6. v1: time in cycles 30520 size 6. v2: time in cycles 4623.54 size 6. v3: time in cycles 5287.95
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-09 12:19:52 UTC --- Why is this marked [4.8 Regression]? From what I can see, gcc has been using OImode in this testcase since it was changed to pass 32-byte vectors in ymm registers (somewhen during 4.4 development, and 4.3 didn't have avx support at all). Thus this doesn't look any kind of regression to me. We risk ABI regressions if we change this though.
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-11-09 12:21:20 UTC ---
template typename _Tp struct A
{
typedef _Tp value_type;
value_type _M_instance[1];
};
template class struct inner_type
{
inner_type () {}
inner_type (inner_type );
inner_type (const inner_type ) {}
};
int
main ()
{
A inner_type int a, b = a;
}
[Bug c++/55250] New: [C++0x][constexpr] enum declarations within constexpr function are allowed, constexpr declarations are not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250
Bug #: 55250
Summary: [C++0x][constexpr] enum declarations within constexpr
function are allowed, constexpr declarations are not
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
The following code compiles in GCC without warnings on -Wall -W -pedantic:
constexpr int Test1(int x) { enum { y = 1 }; return x+y; }
The following one does not:
constexpr int Test2(int x) { constexpr int y = 1; return x+y; }
For the second code, GCC gives error: body of constexpr function 'constexpr
int Test2(int)' not a return-statement
In comparison, Clang++ gives an error for Test1: error: types cannot be
defined in a constexpr function, and for Test2: error: variables cannot be
declared in a constexpr function for Test2.
Now, reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf
, it is not entirely unambiguous which behavior is correct.
While I would like that both samples worked without warnings, I suggest that
attempting to declare an enum within a constexpr function will be made a
-pedantic warning.
[Tested on GCC 4.6.3 through 4.7.2. On GCC 4.5.3, both functions compiled
without warnings.]
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 --- Comment #4 from Antony Polukhin antoshkka at gmail dot com 2012-11-09 12:28:11 UTC --- (In reply to comment #3) Yes, thanks. `output.txt` will be the same. Also, reproduced this bug on GCC 4.7.2: [cc@ontos-soa-01 ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/cc/dev/gcc-4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../downloads/gcc-4.7.2/configure --prefix=/home/cc/dev/gcc-4.7.2 --disable-multilib --enable-languages=c,c++ Thread model: posix gcc version 4.7.2 (GCC)
[Bug rtl-optimization/54472] ICE (spill_failure): unable to find a register to spill in class 'AREG' with -O -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54472 --- Comment #8 from Andrey Belevantsev abel at gcc dot gnu.org 2012-11-09 12:28:30 UTC --- Author: abel Date: Fri Nov 9 12:28:21 2012 New Revision: 193358 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193358 Log: PR rtl-optimization/54472 * sel-sched-ir.c (has_dependence_note_reg_set): Handle implicit sets. (has_dependence_note_reg_clobber, has_dependence_note_reg_use): Likewise. * gcc.dg/pr54472.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr54472.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385 --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 12:31:40 UTC --- Author: steven Date: Fri Nov 9 12:31:32 2012 New Revision: 193359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193359 Log: PR middle-end/54385 * postreload.c (reload_cse_simplify): Return a bool indicating whether the CFG was changed. (reload_cse_regs_1): Traverse the CFG instead of the insns chain. Cleanup the CFG if edges may have been removed. (reload_cse_regs): Update. Modified: trunk/gcc/ChangeLog trunk/gcc/postreload.c
[Bug middle-end/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-11-09 12:33:08 UTC --- .
[Bug rtl-optimization/54472] ICE (spill_failure): unable to find a register to spill in class 'AREG' with -O -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54472 --- Comment #9 from Andrey Belevantsev abel at gcc dot gnu.org 2012-11-09 12:33:33 UTC --- Fixed on trunk, backports to 4.7/4.6 are needed.
[Bug c++/55250] [C++0x][constexpr] enum declarations within constexpr function are allowed, constexpr declarations are not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-09 12:51:52 UTC --- (In reply to comment #0) Now, reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf , it is not entirely unambiguous which behavior is correct. That paper is five years old, so not relevant to what C++11 allows. The standard says: The definition of a constexpr function shall satisfy the following constraints: [...] — its function-body shall be = delete, = default, or a compound-statement that contains only — null statements, — static_assert-declarations — typedef declarations and alias-declarations that do not define classes or enumerations, [...] so it's ill-formed to declare an enumeration.
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW CC||jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-09 12:54:17 UTC --- Thanks Markus, the issue doesn't seem a regression but seems interesting enough to add Jason in CC.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #27 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org
2012-11-09 13:29:10 UTC ---
(In reply to comment #26)
(In reply to comment #25)
Maybe the better solution would indeed be to add a
arith - logical shift conversion pass before combine, or try to convert
arith
shifts in the split pass after combine by looking at the data flow of the
shifted values.
FWIW, while the ARC600/700 have a full set up static and dynamic shifts,
the ARC 601 with the swap option has similar issues with shifts that should
be stitched together from multiple instructions, and preferences of unsigned
over signed shifts.
Another idea would be to extend the combine pass, so that whenever it
internally converts arith - logical shifts, it always checks the costs of the
shift op, and if the logical shift is cheaper, always split out the logical
shift.
Indeed, combine's insistence that a computation has just one canonical
form, which depends on how much it known about the input/output data,
is in want of some correction. We got define_split for things that
should become multiple instructions, but nothing for things that should
just be differently-shaped instructions, and there are no predicates available
to get to know about the (non)zero / signbits that combine knows about.
E.g. the following peephole in arc.md is only necessary because combine
does some unwanted 'simplifications' with known-zero bits:
;; -
;; Pattern 1 : r0 = r1 {i}
;; r3 = r4/INT + r0 ;;and commutative
;; ||
;; \/
;; add{i} r3,r4/INT,r1
;; -
;; ??? This should be covered by combine, alas, at times combine gets
;; too clever for it's own good: when the shifted input is known to be
;; either 0 or 1, the operation will be made into an if-then-else, and
;; thus fail to match the add_n pattern. Example: _mktm_r, line 85 in
;; newlib/libc/time/mktm_r.c .
(define_peephole2
[(set (match_operand:SI 0 dest_reg_operand )
(ashift:SI (match_operand:SI 1 register_operand )
(match_operand:SI 2 const_int_operand )))
(set (match_operand:SI 3 dest_reg_operand )
(plus:SI (match_operand:SI 4 nonmemory_operand )
(match_operand:SI 5 nonmemory_operand )))]
(INTVAL (operands[2]) == 1
|| INTVAL (operands[2]) == 2
|| INTVAL (operands[2]) == 3)
(true_regnum (operands[4]) == true_regnum (operands[0])
|| true_regnum (operands[5]) == true_regnum (operands[0]))
(peep2_reg_dead_p (2, operands[0]) || (true_regnum (operands[3]) ==
true_regnum (operands[0])))
;; the preparation statements take care to put proper operand in operands[4]
;; operands[4] will always contain the correct operand. This is added to
satisfy commutativity
[(set (match_dup 3)
(plus:SI (mult:SI (match_dup 1)
(match_dup 2))
(match_dup 4)))]
if (true_regnum (operands[4]) == true_regnum (operands[0]))
operands[4] = operands[5];
operands[2] = GEN_INT (1 INTVAL (operands[2]));
)
[Bug c++/55249] [4.6/4.7/4.8 Regression] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|Multiple copy constructors |[4.6/4.7/4.8 Regression] |for template class lead to |Multiple copy constructors |link errors |for template class lead to ||link errors --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-09 13:42:14 UTC --- Ah! 4.5 was fine.
[Bug target/55139] __atomic store does not support __ATOMIC_HLE_RELEASE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139 --- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-09 14:06:20 UTC --- My earlier analysis was not correct. I was chasing the wrong warning. Rather the problem is in c-common.c, where the atomic models are checked again. I'm sending a patch for that.
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-09 14:22:55 UTC --- Hmm, this bug currently breaks half IA-64 bencharking in our autotester. http://gcc.opensuse.org/ (terbium) Bernd, you seem to be last who touched this area. Does the patch look OK for you? (probably these structures should be turned into VECtors). Honza
[Bug rtl-optimization/55151] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1217 with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55151 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-11-09 14:28:49 UTC --- Author: vmakarov Date: Fri Nov 9 14:28:40 2012 New Revision: 193361 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193361 Log: 2012-11-09 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55151 * gcc.dg/pr55151.c: Move ... * gcc.target/i386/pr55151.c: ... here. Added: trunk/gcc/testsuite/gcc.target/i386/pr55151.c - copied unchanged from r193349, trunk/gcc/testsuite/gcc.dg/pr55151.c Removed: trunk/gcc/testsuite/gcc.dg/pr55151.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/54546] SH: Enable -fshrink-wrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54546 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.7.0 |4.8.0 Resolution||FIXED --- Comment #5 from chrbr at gcc dot gnu.org 2012-11-09 14:40:15 UTC --- Remaining partitioning issue fixed with http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00630.html. Fixed in 4.8
[Bug target/55139] __atomic store does not support __ATOMIC_HLE_RELEASE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139 --- Comment #5 from ak at gcc dot gnu.org 2012-11-09 15:24:32 UTC --- Author: ak Date: Fri Nov 9 15:24:25 2012 New Revision: 193363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193363 Log: Handle target specific memory models in C frontend get_atomic_generic_size would error out for __atomic_store(...,__ATOMIC_HLE_RELEASE) Just mask it out. All the memory orders are checked completely in builtins.c anyways. I'm not sure what that check is for, it could be removed in theory. Passed bootstrap and test suite on x86-64 gcc/c-family/: 2012-11-09 Andi Kleen a...@linux.intel.com PR 55139 * c-common.c (get_atomic_generic_size): Mask with MEMMODEL_MASK Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #8 from Gary Funck gary at intrepid dot com 2012-11-09 15:26:46 UTC --- (In reply to comment #5) Completely untested patch for someone else to foster-parent: + } + } f = find_fallthru_edge (last_bb-succs); if (f f-probability * 100 / REG_BR_PROB_BASE = PARAM_VALUE (PARAM_SCHED_STATE_EDGE_PROB_CUTOFF)) I could not apply the patch cleanly. Perhaps it was garbled by line wraps, etc. Can you post the patch as an attachment?
