[Bug target/47133] New: code size opportunity for boolean expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47133
Summary: code size opportunity for boolean expression
evaluation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-eabi
Compile the following code with options -march=armv7-a -mthumb -Os
struct S
{
int f1, f2;
};
int t04(int x, struct S* p)
{
return p->f1 == 9 && p->f2 == 0;
}
GCC 4.6 generates:
t04:
ldrr3, [r1, #0]
cmpr3, #9 // A
bne.L3
ldrr0, [r1, #4]
rsbsr0, r0, #1
itcc
movccr0, #0
bxlr // C
.L3:
movsr0, #0 // B
bxlr
Instruction B can be moved before instruction A, and instruction C can be
removed.
t04:
ldrr3, [r1, #0]
movsr0, #0
cmpr3, #9
bne.L3
ldrr0, [r1, #4]
rsbsr0, r0, #1
itcc
movccr0, #0
.L3:
bxlr
When compiled to arm instructions, it has the same problem.
It should be enabled for code size optimization only because it may execute one
more instruction run time.
Looks like an if-conversion opportunity.
[Bug fortran/46971] [4.6 Regression] [OOP] ICE on long class names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46971 --- Comment #5 from janus at gcc dot gnu.org 2010-12-31 10:08:22 UTC --- Author: janus Date: Fri Dec 31 10:08:17 2010 New Revision: 168363 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168363 Log: 2010-12-31 Janus Weil PR fortran/46971 * gfortran.h (gfc_hash_value): Add prototype. * class.c (get_unique_type_string): Check if proc_name is present and make sure string contains an underscore. (get_unique_hashed_string): New function which creates a hashed string if the given unique string is too long. (gfc_hash_value): Moved here from decl.c, renamed and simplified. (gfc_build_class_symbol, gfc_find_derived_vtab): Use hashed strings. * decl.c (hash_value): Moved to class.c. (gfc_match_derived_decl): Renamed 'hash_value'. 2010-12-31 Janus Weil PR fortran/46971 * gfortran.dg/class_33.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_33.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/46971] [4.6 Regression] [OOP] ICE on long class names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46971 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2010-12-31 10:18:00 UTC --- Fixed with r168363. Closing. Thanks to Andrew for reporting this!
[Bug target/47111] mips-rtems: redefinition of NO_IMPLICIT_EXTERN_C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47111 --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 10:29:32 UTC --- Author: amylaar Date: Fri Dec 31 10:29:30 2010 New Revision: 168365 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168365 Log: PR target/47111 * config/rtems.h (NO_IMPLICIT_EXTERN_C): Undef before defining. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rtems.h
[Bug target/47111] mips-rtems: redefinition of NO_IMPLICIT_EXTERN_C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47111 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jorn Wolfgang Rennecke 2010-12-31 10:33:53 UTC --- Patch has been committed to trunk.
[Bug target/47134] New: pdp11_asm_output_var: unused parameter ‘global’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47134 Summary: pdp11_asm_output_var: unused parameter ‘global’ Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 44756 Host: x86_64-pc-linux-gnu Target: pdp11-aout ../../../gcc/gcc/config/pdp11/pdp11.c: In function ‘pdp11_asm_output_var’: ../../../gcc/gcc/config/pdp11/pdp11.c:720:25: error: unused parameter ‘global’ [-Werror=unused-parameter] cc1: all warnings being treated as errors make[2]: *** [pdp11.o] Error 1
[Bug c++/47022] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11682
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47022 --- Comment #5 from Jakub Jelinek 2010-12-31 11:01:05 UTC --- Created attachment 22874 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22874 gcc46-pr47022.patch I think we can either handle the bunch of missing types in tsubst_copy as done in this patch, or in the default: case of tsubst_copy if t is a type just call tsubst instead of gcc_unreachable, or call tsubst instead of tsubst_copy on the second argument of VA_ARG_EXPR (which is a type, not expression), or any combination of these.
[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek 2010-12-31 11:18:55 UTC --- Can't reproduce with neither 20101217 trunk nor current trunk on x86_64-linux either, can the reporter and/or hjl double check current trunk? Thanks.
[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338 --- Comment #3 from Thomas Koenig 2010-12-31 11:20:26 UTC --- Author: tkoenig Date: Fri Dec 31 11:20:22 2010 New Revision: 168366 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168366 Log: 2010-12-31 Thomas Koenig PR fortran/45338 * resolve.c (resolve_operator): Mark function for user-defined operator as referenced. 2010-12-31 Thomas Koenig PR fortran/45338 * gfortran.dg/userdef_operator_2.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/userdef_operator_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug fortran/47065] Replace trim(a) by a(1:len_trim(a))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47065 --- Comment #2 from Thomas Koenig 2010-12-31 11:32:20 UTC --- Author: tkoenig Date: Fri Dec 31 11:32:16 2010 New Revision: 168367 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168367 Log: 2010-12-31 Thomas Koenig PR fortran/47065 * frontend-passes.c (count_arglist): Static variable to count the nesting of argument lists. (optimize_code): Set count_arglist to 1 if within a call statement, to 0 otherwise. (optimize_trim): New function. (optimize_expr): Adjust count_arglist. Call optimize_trim. 2010-12-31 Thomas Koenig PR fortran/47065 * gfortran.dg/trim_optimize_3.f90: New test. * gfortran.dg/trim_optimize_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/trim_optimize_3.f90 trunk/gcc/testsuite/gfortran.dg/trim_optimize_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338 Thomas Koenig changed: What|Removed |Added Known to work||4.6.0 Known to fail|4.6.0 | --- Comment #4 from Thomas Koenig 2010-12-31 11:34:45 UTC --- Fixed on trunk, backport to 4.5 pending.
[Bug fortran/47065] Replace trim(a) by a(1:len_trim(a))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47065 --- Comment #3 from Thomas Koenig 2010-12-31 11:38:03 UTC --- The most common cases are handled now. Still to do: - Handle substring references, for example trim(a(3:5)). Here, we have to watch out for trim(a(function(x):5)), not to evaluate the function twice. - Right now, the optimization is not applied in argument lists. This can be relaxed for PURE functions and subroutines, or if dependency analysis shows that it cannot hurt. The latter point is probably not worth it.
[Bug target/47112] mipstx39-*-elf*: Redefined target macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47112 --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 11:48:06 UTC --- Author: amylaar Date: Fri Dec 31 11:48:03 2010 New Revision: 168369 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168369 Log: PR target/47112 * config/mips/r3900.h: Update Copyright years. (MIPS_CPU_STRING_DEFAULT): Undef before defining. (MULTILIB_DEFAULTS, MIPS_ABI_DEFAULT, SUBTARGET_CC1_SPEC): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/r3900.h
[Bug target/47112] mipstx39-*-elf*: Redefined target macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47112 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jorn Wolfgang Rennecke 2010-12-31 11:54:17 UTC --- Patch has been applied to trunk.
[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||spop at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek 2010-12-31
12:01:51 UTC ---
This shouldn't be parallelized, the loop clearly is not parallelizable. But we
have:
(Data Dep:
#(Data Ref:
# stmt: D.2709_5 = a[i_16];
# ref: a[i_16];
# base_object: a
# Access function 0: {0, +, 1}_1
#)
#(Data Ref:
# stmt: a[j_20] = D.2710_6;
# ref: a[j_20];
# base_object: a
# Access function 0: {0, +, 1}_2
#)
access_fn_A: {0, +, 1}_1
access_fn_B: {0, +, 1}_2
(subscript
iterations_that_access_an_element_twice_in_A: [0 + 1 * x_1]
last_conflict: 1000
iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
last_conflict: 1000
(Subscript distance: 0
)
)
inner loop index: 0
loop nest: (1 2 )
distance_vector: 0 0
direction_vector: ==
)
(Data Dep:
#(Data Ref:
# stmt: D.2709_5 = a[i_16];
# ref: a[i_16];
# base_object: a
# Access function 0: {0, +, 1}_1
#)
#(Data Ref:
# stmt: D.2709_5 = a[i_16];
# ref: a[i_16];
# base_object: a
# Access function 0: {0, +, 1}_1
#)
inner loop index: 0
loop nest: (1 2 )
distance_vector: 0 0
direction_vector: ++
)
(Data Dep:
#(Data Ref:
# stmt: a[j_20] = D.2710_6;
# ref: a[j_20];
# base_object: a
# Access function 0: {0, +, 1}_2
#)
#(Data Ref:
# stmt: a[j_20] = D.2710_6;
# ref: a[j_20];
# base_object: a
# Access function 0: {0, +, 1}_2
#)
inner loop index: 0
loop nest: (1 2 )
distance_vector: 0 0
direction_vector: ++
)
SUCCESS: may be parallelized
[Bug go/47113] go_field_alignment: field set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47113 --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 12:24:15 UTC --- Author: amylaar Date: Fri Dec 31 12:24:12 2010 New Revision: 168373 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168373 Log: PR go/47113 * go-backend.c: (go_field_alignment): Add ATTRIBUTE_UNUSED to variable ‘field’ . Modified: trunk/gcc/go/ChangeLog trunk/gcc/go/go-backend.c
[Bug go/47113] go_field_alignment: field set but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47113 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jorn Wolfgang Rennecke 2010-12-31 12:29:54 UTC --- Patch has been applied to trunk.
[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002 --- Comment #7 from dcb 2010-12-31 12:43:27 UTC --- (In reply to comment #6) > Can't reproduce with neither 20101217 trunk nor current trunk on x86_64-linux > either, can the reporter and/or hjl double check current trunk? > Thanks. I rechecked, and the problem seems to have gone away as of snapshot 20101225. I am not quite clear if SP's patch is for the memory leaks only or has fixed the original problem as well.
[Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194 --- Comment #4 from Zdenek Sojka 2010-12-31 13:09:08 UTC --- When -fcheck-data-deps is added, the testcase doesn't fail (r168358, x86_64-linux): $ gcc -O -ftree-parallelize-loops=2 block-0.c -fcheck-data-deps $ ./a.out $ echo $? 0
[Bug target/47134] pdp11_asm_output_var: unused parameter ‘global’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47134 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 13:18:02 UTC --- Fixed by revision 168368: http://gcc.gnu.org/viewcvs?view=revision&revision=168368
[Bug target/47135] New: pdp11.c: incompatible type for TARGET_PRINT_OPERAND_PUNCT_VALID_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47135 Summary: pdp11.c: incompatible type for TARGET_PRINT_OPERAND_PUNCT_VALID_P Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Blocks: 44756 Host: x86_64-pc-linux-gnu Target: pdp11-aout pdp11_asm_print_operand_punct_valid_p takes a char parameter, but it should be unsigned char.
[Bug target/47135] pdp11.c: incompatible type for TARGET_PRINT_OPERAND_PUNCT_VALID_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47135 --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 13:42:24 UTC --- Author: amylaar Date: Fri Dec 31 13:42:20 2010 New Revision: 168376 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168376 Log: PR target/47135 * config/pdp11/pdp11.c (pdp11_asm_print_operand_punct_valid_p): Change type to match target.def . Modified: trunk/gcc/ChangeLog trunk/gcc/config/pdp11/pdp11.c
[Bug target/47135] pdp11.c: incompatible type for TARGET_PRINT_OPERAND_PUNCT_VALID_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47135 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jorn Wolfgang Rennecke 2010-12-31 13:55:47 UTC --- Patch has been applied to trunk.
[Bug target/47114] powerpc-wrs-vxworks: rs6000_elf_asm_out_{con,de}structor defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47114 --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 14:07:36 UTC --- Author: amylaar Date: Fri Dec 31 14:07:32 2010 New Revision: 168377 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168377 Log: PR target/47114 * config/rs6000/rs6000.c (rs6000_elf_asm_out_constructor): Add ATTRIBUTE_UNUSED to declaration. (rs6000_elf_asm_out_destructor): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek 2010-12-31 14:13:02 UTC --- Assuming it is fixed then.
[Bug target/47114] powerpc-wrs-vxworks: rs6000_elf_asm_out_{con,de}structor defined but not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47114 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jorn Wolfgang Rennecke 2010-12-31 14:17:13 UTC --- Patch has been applied to trunk.
[Bug target/47084] am33_2.0-linux fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47084 --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 14:34:30 UTC --- Author: amylaar Date: Fri Dec 31 14:34:26 2010 New Revision: 168378 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168378 Log: PR target/47084 * config/mn10300/linux.h (PRINT_OPERAND): Update for name changes to mn10300_print_operand / mn10300_print_operand_address. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mn10300/linux.h
[Bug target/47084] am33_2.0-linux fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47084 Jorn Wolfgang Rennecke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jorn Wolfgang Rennecke 2010-12-31 14:38:49 UTC --- Patch has been applied to trunk.
[Bug c++/47132] decltype can't deduce some operator return types when defining an auto function's return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47132 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.31 14:40:05 Ever Confirmed|0 |1 Build|168358 (patched, see specs) | --- Comment #1 from Jonathan Wakely 2010-12-31 14:40:05 UTC --- confirmed, not a regression N.B. the Build field is for the value used for --build at configure time, e.g. --build=i686-unknown-linux-gnu, not the svn revision. That would be shown if you included the output of 'gcc -v' as requested in the bug reporting guidelines, although in this case the unimplemented feature is not dependent on any configure options.
[Bug target/47109] m68k-netbsdelf: collect2 build fails with undefined reference to m68k_cpu_flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47109 --- Comment #2 from Jorn Wolfgang Rennecke 2010-12-31 15:26:28 UTC --- (In reply to comment #1) > My preferred fix for this would be to eliminate the TARGET_VERSION macro > completely. I really don't think it's useful for targets to have this > special version text that's only used in collect2, mips-tdump and > mips-tfile; the information from gcc -v (configure arguments and target > triplet) is more useful. You can certainly try this for GCC 4.7, but to get that target to build again, it is sufficient to simplify TARGET_VERSION not a have a different string for 68010.
[Bug c++/47020] [4.6 Regression] [C++0x] ICE: unexpected expression 'foo' of kind overload when storing address of overloaded function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47020 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.31 15:45:35 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu 2010-12-31 15:45:35 UTC --- It is caused by revision 166167: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html
[Bug target/47109] m68k-netbsdelf: collect2 build fails with undefined reference to m68k_cpu_flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47109 Jorn Wolfgang Rennecke changed: What|Removed |Added Keywords||patch --- Comment #3 from Jorn Wolfgang Rennecke 2010-12-31 15:46:34 UTC --- A patch has been posted here: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02036.html
[Bug tree-optimization/47009] [4.6 Regression] ICE: SIGSEGV (too deep recursion) in cgraph_clone_inlined_nodes with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47009 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.31 15:46:59 Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu 2010-12-31 15:46:59 UTC --- It is caused by revision 165972: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01159.html
[Bug target/38662] __fastcall confuses a function's throw() specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38662 Kai Tietz changed: What|Removed |Added Status|NEW |ASSIGNED CC||ktietz at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ktietz at gcc dot gnu.org |gnu.org | --- Comment #2 from Kai Tietz 2010-12-31 16:06:35 UTC --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02016.html
[Bug regression/47131] [4.6 Regression] internal error for ACATS C34011B on SJLJ targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47131 Eric Botcazou changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.31 17:14:07 CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.6.0 Summary|Ada C34011B fails with |[4.6 Regression] internal |"GNAT BUG" on SJLJ targets |error for ACATS C34011B on ||SJLJ targets Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2010-12-31 17:14:07 UTC --- I can reproduce, thanks for the reduced testcase.
[Bug regression/47131] [4.6 Regression] internal error for ACATS C34011B on SJLJ targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47131 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #2 from Eric Botcazou 2010-12-31 17:14:49 UTC --- Investigating.
[Bug rtl-optimization/45235] const volatile read moved out of order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235 --- Comment #6 from Peter A. Bigot 2010-12-31 17:57:14 UTC --- I've been running with this since my last comment with no problems. Could this be integrated into as many of trunk, gcc-4_4-branch, and gcc-4_5-branch as possible, please? Thanks.
[Bug target/47119] sh-symbianelf: symbian-base.o won't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47119 --- Comment #1 from Jorn Wolfgang Rennecke 2010-12-31 19:51:25 UTC --- Created attachment 22875 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22875 tentative patch There are a lot more problems with this port. Here is a patch that makes the port sort-of build when using GCC as the build compiler; it uses the weak attribute to work around some issues with having different target hooks depending on the input language. I suppose we'd need some serious infrastructure work to make this work cleanly and portably. OTOH, considering that the port has been this seriously broken in GCC 4.5 (e.g. look at the array syntax in sh_symbian_class_needs_attribute), and no PR for this was filed against 4.5, I suppose we could consider this port to have already been deprecated in 4.5, and just remove it.
[Bug fortran/47136] New: [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 Summary: [OOP] possible name resolution problems between MODULE and INTERFACE? Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dfra...@gcc.gnu.org CC: ja...@gcc.gnu.org In the snippet below, I believe that "ABSTRACT INTERFACE s" of "MODULE a" and the "MODULE s" interfere with each other in an unholy way. If either is renamed, the error goes away. As I can not see why duplicate names like these should be invalid, I'd assume the code as-is to be valid?! MODULE a ABSTRACT INTERFACE SUBROUTINE s() END SUBROUTINE END INTERFACE TYPE, ABSTRACT :: t CONTAINS PROCEDURE(s), DEFERRED, NOPASS :: pp END TYPE END MODULE MODULE s USE a END MODULE $ gfortran-svn -c iface.f90 iface.f90:17.7: USE a 1 Error: 's' must be a module procedure or an external procedure with an explicit interface at (1) $ gfortran-svn -v gcc version 4.6.0 20101230 (experimental) (GCC) Same for $ gfortran-4.5 -v gcc version 4.5.3 20101230 (prerelease) (GCC)
[Bug target/47119] sh-symbianelf: symbian-base.o won't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47119 --- Comment #2 from joseph at codesourcery dot com 2010-12-31 20:03:27 UTC --- On Fri, 31 Dec 2010, amylaar at gcc dot gnu.org wrote: > There are a lot more problems with this port. Here is a patch that makes > the port sort-of build when using GCC as the build compiler; it uses the > weak attribute to work around some issues with having different target > hooks depending on the input language. I objected to a previous patch version using the weak attribute and thought that a way was found at that point to do without it. There's no way it should be needed on the host for anything reasonable in GCC - I don't know what this port is trying to do but there's bound to be a better way. Split up objects as necessary and ensure that exactly one implementation of each function needed is linked into each compiler. If the problem is generic functions calling C-family ones, use function pointers initialized at an appropriate point. (REGISTER_TARGET_PRAGMAS is abused by ARM as a "C family initialization hook" though a separate hook would be better.)
[Bug driver/47137] New: [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 Summary: [4.6 Regression] gcc incorrectly combines assembly inputs Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com [...@gnu-6 gcc]$ cat t1.s .globl main main: .L1: .word 9 [...@gnu-6 gcc]$ cat t2.s .L1: .word 9 [...@gnu-6 gcc]$ ./xgcc -B./ t1.s t2.s [...@gnu-6 gcc]$ ./xgcc -B./ t1.s t2.s -o foo t2.s: Assembler messages: t2.s:1: Error: symbol `.L1' is already defined [...@gnu-6 gcc]$
[Bug driver/47137] [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.31 20:24:14 CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu 2010-12-31 20:24:14 UTC --- It is caused by revision 164357: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00651.html
[Bug driver/47137] [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 --- Comment #2 from H.J. Lu 2010-12-31 20:26:43 UTC --- The proposed patch is at http://gcc.gnu.org/ml/gcc/2010-12/msg00517.html
[Bug target/47119] sh-symbianelf: symbian-base.o won't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47119 --- Comment #3 from Jorn Wolfgang Rennecke 2010-12-31 20:35:15 UTC --- (In reply to comment #2) > I objected to a previous patch version using the weak attribute and > thought that a way was found at that point to do without it. There's no > way it should be needed on the host for anything reasonable in GCC I'm not saying that this is doing something reasonable - I just wanted to know how much else it takes to get "make all-gcc" with --enable-werror-always to succeed. >- I > don't know what this port is trying to do but there's bound to be a better > way. Split up objects as necessary and ensure that exactly one > implementation of each function needed is linked into each compiler. If > the problem is generic functions calling C-family ones, use function > pointers initialized at an appropriate point. (REGISTER_TARGET_PRAGMAS is > abused by ARM as a "C family initialization hook" though a separate hook > would be better.) C and C++ frontends each have their own, different versions of these functions, but then these functions area also wanted for linking the ada, lto, and go compilers, and for collect2. So one uniform "C family initialization hook" would not be enough. Unless someone can re-unify the different implementations for the C language family. Maybe this will need some more language hooks. But would that be effort well spent? I.e. does anyone care about this port?
[Bug target/47119] sh-symbianelf: symbian-base.o won't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47119 --- Comment #4 from joseph at codesourcery dot com 2010-12-31 21:17:40 UTC --- On Fri, 31 Dec 2010, amylaar at gcc dot gnu.org wrote: > C and C++ frontends each have their own, different versions of these > functions, but then these functions area also wanted for linking the ada, > lto, and go compilers, and for collect2. > > So one uniform "C family initialization hook" would not be enough. The hook might call a function with different implementations for C and C++ if needed.
[Bug fortran/46448] [4.6 Regression] [OOP] symbol `__copy_...' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46448
--- Comment #3 from Salvatore Filippone
2010-12-31 22:52:03 UTC ---
(In reply to comment #2)
> I think you should check whether the symbol is already there using the "gsym"
> (assuming that -fwhole-file is used - but I think that can be assumed ;-).
>
> There should be only one such function per translation unit; it should use
> everywhere the same decl (UID) and - of course - it should be not exported
> ('static') such that you can have the same function in multiple translation
> units. (Which is ugly - best would be to have only once per program, but I
> think the .mod file is emitted before the CLASS is encountered.)
I just discovered that changing the order of some USE statements in one
intermediate module makes the extra __copy symbol disappear.
While it's a nice workaround, it's a bit suspicious.
[Bug rtl-optimization/47138] New: backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 Summary: backport r158175: replace dominated uses in loop-invariant Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org While updating the msp430 back-end, I've discovered that the problem fixed in trunk in revision 158175 bites me as well in 4.4.x and 4.5.x. This is a request to back-port the corresponding fix to gcc-4_4-branch and gcc-4_5-branch.
[Bug c++/47068] [C++0x] internal compiler error on decltype(~ expression)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47068 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill 2011-01-01 00:15:01 UTC --- Fixed.
[Bug c/47139] New: ice in process_use, at tree-vect-stmts.c:290
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47139
Summary: ice in process_use, at tree-vect-stmts.c:290
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[reg...@gamow tmp433]$ current-gcc -O3 small.c -c
small.c: In function 'func_1':
small.c:19:1: internal compiler error: in process_use, at tree-vect-stmts.c:290
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[reg...@gamow tmp433]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168380-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r168380-install
--program-prefix=r168380- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101231 (experimental) (GCC)
[reg...@gamow tmp433]$ cat small.c
typedef signed char int8_t;
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
static uint8_t
safe_add_func_uint32_t_u_u (uint32_t ui1, uint8_t ui2)
{
return ui1 + ui2;
}
int32_t g_10;
int32_t *g_23 = &g_10;
int32_t **const volatile g = &g_23;
int32_t g_42;
int32_t *func_68 (uint16_t p_69, int8_t p_70);
uint8_t
func_1 (void)
{
*g = func_68 (0x837BL, 0);
return 0;
}
int32_t *
func_68 (uint16_t p_69, int8_t p_70)
{
int32_t l_113;
for (p_70 = 1; p_70; p_70 = safe_add_func_uint32_t_u_u (p_70, 1))
{
int32_t *l_118 = &g_42;
*l_118 = l_113;
l_113 |= p_70;
}
return 0;
}
int
main (int argc, char *argv[])
{
func_1 ();
return 0;
}
[Bug c/47140] New: error: conversion of register to a different size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47140
Summary: error: conversion of register to a different size
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
There are several verify_stmts failed problems pending, but this one looks
different. Apologies if it's a dup.
[reg...@gamow tmp434]$ current-gcc -c -O2 small.c
small.c: In function 'uint321':
small.c:33:5: error: conversion of register to a different size
VIEW_CONVERT_EXPR(D.2762_32);
pretmp.6_33 = VIEW_CONVERT_EXPR(D.2762_32);
small.c:33:5: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[reg...@gamow tmp434]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168380-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r168380-install
--program-prefix=r168380- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101231 (experimental) (GCC)
[reg...@gamow tmp434]$ cat small.c
typedef short int int16_t;
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
static int32_t
safe_mod_func_int32_t_s_s (int32_t si1, int16_t si2)
{
return si2 == 0 || si1 == -2147483647 - 1 && si2 ? si1 : si1 + si2;
}
static uint8_t
safe_add_func_uint8_t_u_u (uint8_t ui1, uint8_t ui2)
{
return ui1 + ui2;
}
static uint16_t
safe_sub_func_uint16_t_u_u (uint16_t ui1, uint8_t ui2)
{
return ui1 - ui2;
}
int16_t g_32;
int16_t g_76[7][10] = {
};
volatile int32_t g_98[1][1] = {
};
volatile int32_t *g_97 = &g_98[0][0];
int uint321 (void)
{
for (0;; 1)
*g_97 =
safe_mod_func_int32_t_s_s (safe_add_func_uint8_t_u_u
(1,
func_21 (g_32,
g_76[5][5])) >=
safe_sub_func_uint16_t_u_u (&g_97 == 0, 1),
0);
}
[Bug c/47141] New: segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47141
Summary: segfault
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
Searching on "Segmentation fault" in the bugzilla returns hundreds of matches
so I can't really verify this is new, sorry! But at least it's a small
testcase :).
Valgrind talks about a read past the bound of a malloc'd block and also about a
null ptr dereference -- hard to tell what is the real problem.
[reg...@gamow tmp435]$ current-gcc -c small.c -O2
small.c: In function 'func_115':
small.c:30:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[reg...@gamow tmp435]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168380-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r168380-install
--program-prefix=r168380- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101231 (experimental) (GCC)
[reg...@gamow tmp435]$ cat small.c
typedef signed char int8_t;
typedef int int32_t;
typedef unsigned int uint32_t;
static uint32_t
safe_add_func_uint32_t_u_u (uint32_t ui1, uint32_t ui2)
{
return ui1 + ui2;
};
int8_t *const
func_112 (int32_t * p_113, int8_t p_114)
{
func_115 (func_115, 0);
return 0;
}
int32_t
func_115 (uint32_t p_116, uint32_t p_117, int8_t * p_118)
{
int32_t l_141;
int32_t *l_186 = &l_141;
if (l_141)
{
}
else
for (l_141 = 0; l_141; l_141 = safe_add_func_uint32_t_u_u (l_141, 1))
{
}
return *l_186;
}
[Bug c/47142] New: incorrect libgcc_s_sjlj-1.dll install
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 Summary: incorrect libgcc_s_sjlj-1.dll install Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dongsheng.s...@gmail.com When I cross build i686-w64-mingw32 target with multilib support on i686-pc-linux (Debian 6.0), libgcc_s_sjlj-1.dll not install correctly: gcc-4.6-w32_i686-linux$ find . -name *.dll ./bin/64/pthreadGC2.dll ./bin/pthreadGC2.dll ./bin/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/lib/libgfortran-3.dll ./i686-w64-mingw32/lib/libquadmath-0.dll ./i686-w64-mingw32/lib/libobjc-3.dll ./i686-w64-mingw32/lib/libgomp-1.dll ./i686-w64-mingw32/lib/libssp-0.dll ./i686-w64-mingw32/lib/libstdc++-6.dll ./i686-w64-mingw32/lib64/libgfortran-3.dll ./i686-w64-mingw32/lib64/libquadmath-0.dll ./i686-w64-mingw32/lib64/libobjc-3.dll ./i686-w64-mingw32/lib64/libgomp-1.dll ./i686-w64-mingw32/lib64/libssp-0.dll ./i686-w64-mingw32/lib64/libstdc++-6.dll $ file bin/libgcc_s_sjlj-1.dll bin/libgcc_s_sjlj-1.dll: PE32+ executable for MS Windows (DLL) (console) Mono/.Net assembly So no 32-bit version installed, not 64 bit version installed incorrectly. But the building result is correct: $ find . -name *.dll ./i686-w64-mingw32/64/libgomp/.libs/libgomp-1.dll ./i686-w64-mingw32/64/libgfortran/.libs/libgfortran-3.dll ./i686-w64-mingw32/64/libobjc/.libs/libobjc-3.dll ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++-6.dll ./i686-w64-mingw32/64/libquadmath/.libs/libquadmath-0.dll ./i686-w64-mingw32/64/libgcc/64/shlib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/64/libssp/.libs/libssp-0.dll ./i686-w64-mingw32/libgomp/.libs/libgomp-1.dll ./i686-w64-mingw32/libgfortran/.libs/libgfortran-3.dll ./i686-w64-mingw32/libobjc/.libs/libobjc-3.dll ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll ./i686-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./i686-w64-mingw32/libgcc/shlib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libssp/.libs/libssp-0.dll
[Bug c/47143] New: warning about const multidimensional array as function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47143
Summary: warning about const multidimensional array as function
parameter
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@linuxmail.org
Created attachment 22876
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22876
source which produces warning
Ehllo,
I'm getting some strange warning about this code:
--- snip ---
typedef double mat4[4][4];
void mprod4(mat4 r, const mat4 a, const mat4 b)
{
/* yes, function is empty */
}
int main()
{
mat4 mr, ma, mb;
mprod4(mr, ma, mb);
}
gcc output as follows:
--- snip
$ gcc -o test test.c
test.c: In function 'main':
test.c:13: warning: passing argument 2 of 'mprod4' from incompatible pointer
type
test.c:4: note: expected 'const double (*)[4]' but argument is of type 'double
(*)[4]'
test.c:13: warning: passing argument 3 of 'mprod4' from incompatible pointer
type
test.c:4: note: expected 'const double (*)[4]' but argument is of type 'double
(*)[4]'
defining the function as:
--- snip ---
void mprod4(mat4 r, mat4 a, mat4 b)
{
}
OR defining matrices at main as:
--- snip ---
mat4 mr;
const mat4 ma;
const mat4 mb;
OR calling teh function in main as:
--- snip ---
mprod4(mr, (const double(*)[4])ma, (const double(*)[4])mb);
OR even defining mat4 as:
--- snip ---
typedef double mat4[16];
make teh warning go away. Wat is happening here? Am I doing something invalid?
I have attached source code.
Thanks for your attention.
[Bug c++/47144] New: Doesn't reject attempt to define type in template argument; results in weird parse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47144
Summary: Doesn't reject attempt to define type in template
argument; results in weird parse
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
GCC accepts the following:
template struct A { }; A< struct B { } >::SomeNonSense int y;
Seems like internally it creates the specialization for "A< ::B >", but its
parser goes mad at some part. It's not allowed to define types in template
arguments. C++03 seems to have missed to explicitly state that, but n3225 says
so explicitly.
