[Bug target/40935] [avr] conditional comparison uses short instead of char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40935 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Resolution||INVALID --- Comment #2 from Ian Lance Taylor ian at airs dot com 2010-11-07 05:55:23 UTC --- I agree with Georg that there does not seem to be a bug here. When I compile with optimization this looks fine. Note that C states that all arithmetic operations are done in the type int, which for AVR is the same size as the type short by default. This is done unless the optimizers can prove that it is unnecessary.
[Bug target/20518] Clobber registers,in inline asm. Problem when using rcall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20518 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Version|3.4.3 |4.6.0 Resolution||FIXED --- Comment #3 from Ian Lance Taylor ian at airs dot com 2010-11-07 05:47:58 UTC --- In gcc mainline I get Main.c: In function ‘Foo’: Main.c:26:1: error: r28 cannot be used in asm here Main.c:26:1: error: r29 cannot be used in asm here so this appears to be fixed.
[Bug fortran/45636] Failed to fold simple Fortran string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC|danglin at gcc dot gnu.org | --- Comment #24 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-07 07:46:24 UTC --- remove Danglin to avoid mail spamage
[Bug c++/46341] New: [C++0X] ICE: in cxx_eval_vec_init_1, at cp/semantics.c:6362
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46341
Summary: [C++0X] ICE: in cxx_eval_vec_init_1, at
cp/semantics.c:6362
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
The following code causes an ICE, but compiles fine if I remove constexpr.
templateclass _T2
struct pair
{
_T2 second;
constexpr pair() : second() {}
};
templatetypename _Tp, int _Nm
struct array
{
_Tp _M_instance[_Nm];
};
struct Periodic_3_offset_3 {
Periodic_3_offset_3() {}
typedef array pairPeriodic_3_offset_3, 2 Periodic_segment;
Periodic_segment dual() {
Periodic_segment ps;
}
};
3.cc: In member function ‘Periodic_3_offset_3::Periodic_segment
Periodic_3_offset_3::dual()’:
3.cc:16:20: in constexpr expansion of ‘ps.arraypairPeriodic_3_offset_3,
2::array()’
3.cc:16:20: internal compiler error: in cxx_eval_vec_init_1, at
cp/semantics.c:6362
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.1.2 Keywords||ice-on-valid-code Last reconfirmed||2010.11.07 08:24:07 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|gfortran internal compiler |[4.3/4.4/4.5/4.6 |error |Regression] ICE (segfault) ||in ||gfc_trans_pointer_assignmen ||t Target Milestone|--- |4.4.6 Known to fail||4.3.4, 4.4.0, 4.5.1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-07 08:24:07 UTC --- ==16250== Invalid read of size 8 ==16250==at 0x56962A: gfc_trans_pointer_assignment (trans-expr.c:4892) ==16250==by 0x54610D: trans_code (trans.c:1259) ==16250==by 0x562721: gfc_generate_function_code (trans-decl.c:4651) ==16250==by 0x546581: gfc_generate_module_code (trans.c:1560) else if (expr2-expr_type == EXPR_VARIABLE) [...] gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp); Hereby GFC_DECL_SPAN(decl) == decl-decl_common.lang_specific-span but decl-decl_common.lang_specific == NULL
[Bug fortran/46340] internal compiler error: Segmentation fault building LAPACK 3.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46340 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.11.07 08:28:26 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-07 08:28:26 UTC --- Can you try a newer version? I can reproduce it with 4.6.0 20100831 but it seems to be fixed in 4.6.0 20101106. (And also works in my GCC 4.4 and 4.5.) Cf. also http://gcc.gnu.org/wiki/GFortranBinaries
[Bug c/46342] New: I am a student.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46342 Summary: I am a student. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: yueni_z...@hotmail.com I you want!
[Bug c/46343] New: I am a student.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46343 Summary: I am a student. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: yueni_z...@hotmail.com I you want!
[Bug c/46342] I am a student.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46342 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-07 09:50:53 UTC --- Not a bug.
[Bug c/46343] I am a student.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46343 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-07 09:51:00 UTC --- Not a bug.
[Bug rtl-optimization/46337] dse.c:replace_inc_dec mis-use of gen_int_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46337 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2010-11-07 09:56:41 UTC --- Do you have a test case? That would greatly increase the chance of this fix being added to the 4.4 branch. (This is not the first error fixed by r146451 but not backported to 4.4, see http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01120.html for another one.)
[Bug rtl-optimization/46337] dse.c:replace_inc_dec mis-use of gen_int_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46337 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.07 10:18:15 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-07 10:18:15 UTC --- Do you have a test case? That would greatly increase the chance of this fix being added to the 4.4 branch. Backporting the fix onto the 4.4 and 4.3 branches is OK, the current code doesn't make any sense. But, yes, having a testcase would be better.
[Bug target/45359] poor -march=native choices for VIA C7 Esther processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added Attachment #0|0 |1 is obsolete|| --- Comment #4 from Dzianis Kahanovich mahatma at eu dot by 2010-11-07 10:47:13 UTC --- Created attachment 22306 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22306 centaur.patch Just cleanup (c3-2). -mtune not passed to assembler, then -mtune vs. NOPL (by Gentoo Wiki) is not useful. May be -Wa,-mtune=generic or -Wa,, but not here...
[Bug other/46332] __cxa_demangle yields excess parentheses for function types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ian at airs dot com Component|libstdc++ |other --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07 11:08:40 UTC --- Ian, can you have a look? Thanks in advance.
[Bug c++/46335] [C++0X] [4.6 Regression] ICE: in gimple_add_tmp_var, at gimplify.c:701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46335 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.07 11:12:14 CC||jason at gcc dot gnu.org Summary|[C++0X] ICE: in |[C++0X] [4.6 Regression] |gimple_add_tmp_var, at |ICE: in gimple_add_tmp_var, |gimplify.c:701 |at gimplify.c:701 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07 11:12:14 UTC --- Looks like a regression.
[Bug c++/46336] [C++0X] ICE on invalid: in register_constexpr_fundef, at cp/semantics.c:5571
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46336 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.07 11:13:05 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07 11:13:05 UTC --- Let's add Jason in CC.
[Bug c++/46341] [C++0X] ICE: in cxx_eval_vec_init_1, at cp/semantics.c:6362
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46341 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.07 11:15:06 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07 11:15:06 UTC --- Let's add Jason in CC for this one too.
[Bug target/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45585 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-07 11:45:18 UTC --- I have posted at http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00551.html the result of the regtest with the patch in comment #5. The patch fixes this PR without adding regressions of its own (the new failures are also seen in http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00540.html and gfortran.dg/vect/pr45714-b.f failed before the patch). Thanks.
[Bug fortran/46344] New: [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 Summary: [OOP] ICE with allocatable CLASS components Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test case: module mld_d_prec_type type mld_d_base_solver_type end type mld_d_base_solver_type type mld_d_base_smoother_type class(mld_d_base_solver_type), allocatable :: sv end type mld_d_base_smoother_type type mld_donelev_type class(mld_d_base_smoother_type), allocatable :: sm end type mld_donelev_type end module mld_d_prec_type program ppde use mld_d_prec_type implicit none type(mld_donelev_type), allocatable :: precv(:) allocate(precv(1)) end program ppde This produces an ICE (segfault) with current trunk. Reported by Salvatore Fillipone.
[Bug fortran/46344] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from janus at gcc dot gnu.org 2010-11-07 12:58:32 UTC --- Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00576077 in structure_alloc_comps (der_type=0x1914d40, decl=0x76ba0300, dest=0x0, rank=0, purpose=1) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6322 6322 comp = fold_build3_loc (input_location, COMPONENT_REF, (gdb) bt #0 0x00576077 in structure_alloc_comps (der_type=0x1914d40, decl=0x76ba0300, dest=0x0, rank=0, purpose=1) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6322 #1 0x005766fd in gfc_deallocate_alloc_comp (der_type=0x1914d40, decl=0x76ba0300, rank=0) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6435 #2 0x00561fdc in gfc_deallocate_scalar_with_status (pointer=0x76b99a00, status=0x0, can_fail=1 '\001', expr=0x0, ts=...) at /home/jweil/gcc46/trunk/gcc/fortran/trans.c:1005 #3 0x005760f7 in structure_alloc_comps (der_type=0x1915310, decl=0x77f09828, dest=0x0, rank=1, purpose=1) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6325 #4 0x00575c8a in structure_alloc_comps (der_type=0x1915310, decl=0x77fcb500, dest=0x0, rank=1, purpose=1) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6251 #5 0x005766fd in gfc_deallocate_alloc_comp (der_type=0x1915310, decl=0x77fcb500, rank=1) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6435 #6 0x00576cba in gfc_trans_deferred_array (sym=0x1917610, block=0x7fffde10) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:6564 #7 0x0058c6cc in gfc_trans_deferred_vars (proc_sym=0x1912340, block=0x7fffde10) at /home/jweil/gcc46/trunk/gcc/fortran/trans-decl.c:3372 #8 0x005913d0 in gfc_generate_function_code (ns=0x1911940) at /home/jweil/gcc46/trunk/gcc/fortran/trans-decl.c:4703 #9 0x005630f7 in gfc_generate_code (ns=0x1911940) at /home/jweil/gcc46/trunk/gcc/fortran/trans.c:1510 #10 0x0050c989 in translate_all_program_units (gfc_global_ns_list=0x1911940) at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:4243 #11 0x0050cf4a in gfc_parse_file () at /home/jweil/gcc46/trunk/gcc/fortran/parse.c:4443 #12 0x00551daf in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc46/trunk/gcc/fortran/f95-lang.c:250 #13 0x00a307c5 in compile_file () at /home/jweil/gcc46/trunk/gcc/toplev.c:919 #14 0x00a32ceb in do_compile () at /home/jweil/gcc46/trunk/gcc/toplev.c:2359 #15 0x00a32e17 in toplev_main (argc=2, argv=0x7fffe228) at /home/jweil/gcc46/trunk/gcc/toplev.c:2419 #16 0x005e529c in main (argc=2, argv=0x7fffe228) at /home/jweil/gcc46/trunk/gcc/main.c:36
[Bug fortran/46345] New: ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46345 Summary: ICE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 22307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22307 test-case While cutting down a test case for a wrong-code issue, I have produced the following ICE: Driving: gfortran -v .o tp tp.f90 -l gfortran -l m -shared-libgcc gfortran: error: .o: No such file or directory Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel /GCC/mpfr --with-mpc=/home/travel/GCC/mpc Thread model: posix gcc version 4.6.0 20101105 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 tp.f90 -quiet -dumpbase tp.f90 -mtune=generic -march=x86-64 -auxbase tp -version -f intrinsic-modules-path /usr/local/gnu46/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /tmp/ccggWLYz.s GNU Fortran (GCC) version 4.6.0 20101105 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101105 (experimental), GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101105 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101105 (experimental), GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 tp.f90: In function 'ppde': tp.f90:282:0: 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. -bash-4.1$
[Bug fortran/46223] [4.6 Regression] gfortran.dg/bessel_7.f90 failures on s390-ibm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46223 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.6.0 Summary|gfortran.dg/bessel_7.f90|[4.6 Regression] |failures on |gfortran.dg/bessel_7.f90 |s390-ibm-linux-gnu |failures on ||s390-ibm-linux-gnu --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-07 13:03:50 UTC --- Mark as regression to keep in on my radar. The test case is new thus one can argue whether it is a regression or not.
[Bug fortran/46345] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46345 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||janus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from janus at gcc dot gnu.org 2010-11-07 13:04:49 UTC --- PR 46344 contains a reduced version. *** This bug has been marked as a duplicate of bug 46344 ***
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 janus at gcc dot gnu.org changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #2 from janus at gcc dot gnu.org 2010-11-07 13:04:49 UTC --- *** Bug 46345 has been marked as a duplicate of this bug. ***
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-07 13:07:35 UTC --- (In reply to comment #2) *** Bug 46345 has been marked as a duplicate of this bug. *** That PR contains a longer test case: attachment 22307
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #4 from janus at gcc dot gnu.org 2010-11-07 13:16:29 UTC --- Here's a variant: module m type t1 end type type t2 class(t1), allocatable :: cc end type class(t2), allocatable :: sm end module m program p use m implicit none type(t2), allocatable :: x(:) allocate(x(1)) end program p (Same ICE.)
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #5 from janus at gcc dot gnu.org 2010-11-07 13:22:07 UTC --- (In reply to comment #4) Here's a variant: Side remark: In comment #4, if I change the name of 'sm' to 'y', I get: end module m 1 Internal Error at (1): write_symbol(): bad module symbol 'y' ... which is *very* strange to say the least.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-07 13:39:37 UTC --- Revision 162456 compiles the tests, but not revision 166102. When compiled, the executable for pr46345 gives Check 0: T a.out(84352) malloc: *** error for object 0x13072: pointer being freed was not allocated
[Bug tree-optimization/45844] FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45844 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-07 13:53:58 UTC --- Could this pr be related to pr45585? The fix for pr45585 does not works for this pr.
[Bug rtl-optimization/46337] dse.c:replace_inc_dec mis-use of gen_int_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46337 --- Comment #3 from Peter A. Bigot bigotp at acm dot org 2010-11-07 14:09:31 UTC --- Created attachment 22308 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22308 Test case This test case evokes the bug with the 16-bit msp430 target, which is not integrated into gcc mainline. When built with -O2, the copy from cal into tcal is converted into a series of five one-word moves. The copies for the values at word offsets 2 (first half temperature_scale) and 4 (local_modbus_addr) are apparently eliminated by some other optimization, but the copy for the last half of temperature_scale hits the dse.c code. In my case, I end up attempting to convert the value 5 to CCMode, instead of the value 2 to HIMode, resulting in an ICE in trunc_int_for_mode at explow.c:56. I wasn't able to reproduce the ICE on a different architecture, and haven't tried to check the generated code. Seems that it's pretty dependent on the back end. Hope this helps, and if not, that it's still ok to fix because it's clearly wrong.
[Bug objc/41617] [4.4/4.5/4.6 regression] ObjC: Error: symbol `_OBJC_CLASS_AppController' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org Known to fail|| --- Comment #7 from Iain Sandoe iains at gcc dot gnu.org 2010-11-07 14:18:43 UTC --- Is this still a problem? I cannot reproduce this on i686-darwin9 on trunk or 4.5.2 with : ./gcc/xgcc -Bgcc ../tests/AppController_44.mi -c -fgnu-runtime -w
[Bug fortran/46331] Compilation time long with simple function in array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46331
--- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-07
14:32:47 UTC ---
Patch: The part removed too agressively decides if an expression is constant.
In the case of rand(), the result obviously does not reduce to a constant but
the array constructor was expanded. Returning zero here means the function is
not constant and therefore the array is not expanded at compile time.
Regression tested OK on x86-64.
Index: expr.c
===
--- expr.c(revision 166382)
+++ expr.c(working copy)
@@ -900,7 +900,6 @@ int
gfc_is_constant_expr (gfc_expr *e)
{
gfc_constructor *c;
- gfc_actual_arglist *arg;
if (e == NULL)
return 1;
@@ -921,19 +920,8 @@ gfc_is_constant_expr (gfc_expr *e)
/* Specification functions are constant. */
if (check_specification_function (e) == MATCH_YES)
return 1;
+ return 0;
- /* Call to intrinsic with at least one argument. */
- if (e-value.function.isym e-value.function.actual)
-{
- for (arg = e-value.function.actual; arg; arg = arg-next)
-if (!gfc_is_constant_expr (arg-expr))
- return 0;
-
- return 1;
-}
- else
-return 0;
-
case EXPR_CONSTANT:
case EXPR_NULL:
return 1;
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #18 from Iain Sandoe iains at gcc dot gnu.org 2010-11-07 14:50:00 UTC --- The test has been removed for GNU runtime for the present, since it seems that fixing this is probably outside the scope of 4.6. The forward-1.m test has been moved to objc.dg/torture (so that is also exercises with lto) and confined to m32 NeXT runtime.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #7 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-11-07 14:58:40 UTC --- (In reply to comment #6) Revision 162456 compiles the tests, but not revision 166102. When compiled, the executable for pr46345 gives Check 0: T a.out(84352) malloc: *** error for object 0x13072: pointer being freed was not allocated ...which is the original problem for which I was trying to open a PR, a wrong allocation status for a scalar component. Salvatore
[Bug target/46346] New: [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46346 Summary: [4.6 regression] fma testsuite failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: meiss...@gcc.gnu.org Target: powerpc*-*-linux FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvmadd 4 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsmadd 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fmadds 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvmsub 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsmsub 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvnmadd 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsnmadd 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fnmadds 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvnmsub 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsnmsub 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fnmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvmadd 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsmadd 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fmadds 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvmsub 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsmsub 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvnmadd 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsnmadd 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fnmadds 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvnmsub 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsnmsub 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fnmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-3.c scan-assembler-times vmaddfp 2 FAIL: gcc.target/powerpc/ppc-fma-3.c scan-assembler-times fmadds 2 FAIL: gcc.target/powerpc/ppc-fma-4.c scan-assembler-times vmaddfp 1 FAIL: gcc.target/powerpc/ppc-fma-4.c scan-assembler-times fmadd 1 FAIL: gcc.target/powerpc/ppc-fma-4.c scan-assembler-times fmadds 1 ppc-fma-5.c: In function 'main': ppc-fma-5.c:26:1: internal compiler error: in rhs_to_tree, at tree-ssa-forwprop.c:352 FAIL: gcc.target/powerpc/ppc-fmadd-1.c scan-assembler-not f(add|sub|mul|neg)
[Bug fortran/46340] internal compiler error: Segmentation fault building LAPACK 3.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46340 Jeff jeff.science at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #2 from Jeff jeff.science at gmail dot com 2010-11-07 15:00:53 UTC --- Yep, the latest version is fine. Thanks.
[Bug c++/46335] [C++0X] [4.6 Regression] ICE: in gimple_add_tmp_var, at gimplify.c:701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46335 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug target/46346] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46346 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.07 15:22:59 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-07 15:22:59 UTC --- Mine.
[Bug libstdc++/46347] New: Profile-mode executables too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46347
Summary: Profile-mode executables too large
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com
I believe we should seriously investigate whether we can reduce the size of the
profile-mode executables. Likely that means we have also to add exports, but
the current status seems really pretty bad. Just as a trivial example, on
mainline today (rev 166416), x86_64, -O2, we have, for
#include vector
int main()
{
std::vectorint v(100);
v.push_back(2);
}
the following sizes:
normal-mode:12184
debug-mode:17370
profile-mode: 130345
[Bug c++/46335] [C++0X] [4.6 Regression] ICE: in gimple_add_tmp_var, at gimplify.c:701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46335 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-07 15:49:48 UTC --- It is caused by revision 166167: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html
[Bug c++/46348] New: [C++0x] ICE with constexpr default constructor and array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46348
Summary: [C++0x] ICE with constexpr default constructor and
array member
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com
This is just a link to this issue
http://gcc.gnu.org/ml/gcc/2010-11/msg00135.html
http://gcc.gnu.org/ml/gcc/2010-11/msg00136.html
which we don't want to forget. To repeat:
struct A
{
int arr[1];
constexpr A()
: arr() { }
};
u.C: In constructor ‘constexpr A::A()’:
u.C:6:13: internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5499
I'm adding Jason in CC.
[Bug target/46346] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46346
--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2010-11-07 16:15:39
UTC ---
A trivial attempt that fixes builtin-attr-1.c for x86 with -mfma:
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c(revision 166415)
+++ tree-ssa-forwprop.c(working copy)
@@ -341,7 +341,11 @@ rhs_to_tree (tree type, gimple stmt)
{
location_t loc = gimple_location (stmt);
enum tree_code code = gimple_assign_rhs_code (stmt);
- if (get_gimple_rhs_class (code) == GIMPLE_BINARY_RHS)
+ if (get_gimple_rhs_class (code) == GIMPLE_TERNARY_RHS)
+return fold_build3_loc (loc, code, type, gimple_assign_rhs1 (stmt),
+gimple_assign_rhs2 (stmt),
+gimple_assign_rhs3 (stmt));
+ else if (get_gimple_rhs_class (code) == GIMPLE_BINARY_RHS)
return fold_build2_loc (loc, code, type, gimple_assign_rhs1 (stmt),
gimple_assign_rhs2 (stmt));
else if (get_gimple_rhs_class (code) == GIMPLE_UNARY_RHS)
[Bug target/40171] GCC does not pass -mtune and -march options to assembler!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171 Dzianis Kahanovich mahatma at eu dot by changed: What|Removed |Added CC||mahatma at eu dot by --- Comment #5 from Dzianis Kahanovich mahatma at eu dot by 2010-11-07 16:15:37 UTC --- (In reply to comment #0) Even Linux kernel use -march without -Wa,-march. If I pass -Wa,-march=prescott option to Linux kernel - they failed to build (used wide range of directives like AMD's prefetch). IMHO only -mtune need to be passed to not bound directives range.
[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-07 17:07:00 UTC --- Last patch: http://gcc.gnu.org/ml/fortran/2010-11/msg00052.html
[Bug target/46346] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46346
--- Comment #3 from rguenther at suse dot de rguenther at suse dot de
2010-11-07 17:39:16 UTC ---
On Sun, 7 Nov 2010, ubizjak at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46346
--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2010-11-07
16:15:39 UTC ---
A trivial attempt that fixes builtin-attr-1.c for x86 with -mfma:
Works for me.
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c(revision 166415)
+++ tree-ssa-forwprop.c(working copy)
@@ -341,7 +341,11 @@ rhs_to_tree (tree type, gimple stmt)
{
location_t loc = gimple_location (stmt);
enum tree_code code = gimple_assign_rhs_code (stmt);
- if (get_gimple_rhs_class (code) == GIMPLE_BINARY_RHS)
+ if (get_gimple_rhs_class (code) == GIMPLE_TERNARY_RHS)
+return fold_build3_loc (loc, code, type, gimple_assign_rhs1 (stmt),
+gimple_assign_rhs2 (stmt),
+gimple_assign_rhs3 (stmt));
+ else if (get_gimple_rhs_class (code) == GIMPLE_BINARY_RHS)
return fold_build2_loc (loc, code, type, gimple_assign_rhs1 (stmt),
gimple_assign_rhs2 (stmt));
else if (get_gimple_rhs_class (code) == GIMPLE_UNARY_RHS)
[Bug target/46346] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46346 --- Comment #4 from uros at gcc dot gnu.org 2010-11-07 17:49:15 UTC --- Author: uros Date: Sun Nov 7 17:49:11 2010 New Revision: 166419 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166419 Log: PR tree-optimization/46346 * tree-ssa-forwprop.c (rhs_to_tree): Handle GIMPLE_TERNARY_RHS. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug tree-optimization/46346] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46346 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-11/msg00690.htm ||l Component|target |tree-optimization Resolution||FIXED --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2010-11-07 18:00:05 UTC --- Fixed.
[Bug c++/46348] [C++0x] ICE with constexpr default constructor and array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46348 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2010-11-07 18:06:38 UTC --- Already fixed.
[Bug c++/46348] [C++0x] ICE with constexpr default constructor and array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46348 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07 18:09:35 UTC --- Ah, now I see the patch, thanks Jason!
[Bug c++/46348] [C++0x] ICE with constexpr default constructor and array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46348 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2010.11.07 18:43:45 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07 18:43:45 UTC --- Jason, unfortunately the original std::bitset issues aren't all fixed yet. If you apply the patchlet I'm attaching here too for your convenience to std::bitset and then run the v3 testsuite, you get this new ICE: FAIL: 23_containers/bitset/cons/constexpr.cc (test for excess errors) Excess errors: /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h:654:20: in constexpr expansion of '((std::bitset256ul*)( __v))-std::bitset_Nb::bitset [with long unsigned int _Nb = 256ul]()' /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bitset:814:7: in constexpr expansion of 'std::bitset256ul::anonymous.std::_Base_bitset_Nw::_Base_bitset [with long unsigned int _Nw = 4ul]()' /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h:654:20: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in build_special_member_call, at cp/call.c:6342 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I'll try to come up with a reduced testcase myself ASAP.
[Bug c++/46348] [C++0x] ICE with constexpr default constructor and array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46348 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07 18:45:19 UTC --- Created attachment 22309 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22309 Apply to current v3 to see ICEs in the testsuite
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 --- Comment #19 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-07 19:01:53 UTC --- (In reply to comment #18) The forward-1.m test has been moved to objc.dg/torture (so that is also exercises with lto) and confined to m32 NeXT runtime. I think this is the wrong approach. Please just xfail it for the GNU runtime. This testcase works on some targets (x86 32bits). -- Pinski
[Bug c++/46348] [C++0x] ICE with constexpr default constructor and array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46348
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-07
19:07:45 UTC ---
This:
template__SIZE_TYPE__ _Nw
struct _Base
{
typedef unsigned long _WordT;
_WordT _M_w[_Nw];
constexpr
_Base()
: _M_w() { }
};
int main()
{
_Base256 bs;
}
t2.C: In function ‘int main()’:
t2.C:15:14: in constexpr expansion of ‘bs._Base_Nw::_Base [with long
unsigned int _Nw = 256ul]()’
t2.C:15:14: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have integer_type in build_special_member_call,
at cp/call.c:6342
[Bug tree-optimization/46349] New: [4.6 regression] incorrect scalarization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46349 Summary: [4.6 regression] incorrect scalarization Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org The fix for PR tree-opt/44972 has introduced regressions in Ada, specifically: (sra_modify_assign): Removed ref_expr_for_all_replacements_p checks, checks for return values of build_ref_for_offset. sra_modify_assign now builds addresses of non-byte-aligned references, leading to the expected ICE later in the RTL expander: e...@atlantis:~/build/gcc/native32 gcc/xgcc -Bgcc -S opt9.adb -gnatws -O +===GNAT BUG DETECTED==+ | 4.6.0 20101105 (experimental) [trunk revision 166350] (i586-suse-linux-gnu) GCC error:| | in expand_expr_addr_expr_1, at expr.c:7009 | | Error detected around opt9.adb:17:7 The non-byte-aligned reference is a bitfield with aggregate type. I think that the checks of the return values should be reinstated somehow or other. The testcase is suitable for addition to the gnat.dg testsuite.
[Bug fortran/45636] Failed to fold simple Fortran string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636 --- Comment #25 from dave at hiauly1 dot hia.nrc.ca 2010-11-07 19:44:07 UTC --- The change was r166378 and if the test failures are the only reason to keep this bug report open then it we should be able to close it now. Closing would be ok if there is a reason the call to mempcpy shouldn't be eliminated. On darwin, it was eliminated. Dave
[Bug tree-optimization/46349] [4.6 regression] incorrect scalarization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46349 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-07 19:45:50 UTC --- Created attachment 22310 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22310 Testcase, file #1
[Bug tree-optimization/46349] [4.6 regression] incorrect scalarization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46349 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-07 19:46:51 UTC --- Created attachment 22311 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22311 Testcase, file #2
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org 2010-11-07 19:55:00 UTC --- Author: iains Date: Sun Nov 7 19:54:51 2010 New Revision: 166421 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166421 Log: gcc/testsuite: PR libobjc/36610 * objc.dg/torture/forward-1.m: Re-enable for gnu-runtime, XFAIL the run for all but m32 x86. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/torture/forward-1.m
[Bug boehm-gc/46311] boehm-gc build problem with uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46311 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||Hans.Boehm at hp dot com --- Comment #1 from David Edelsohn dje at gcc dot gnu.org 2010-11-07 19:57:00 UTC --- Boehm-GC bugs best are handled upstream by the Boehm-GC community.
[Bug ada/46350] New: s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46350 Summary: s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include-c -g -O2 -W -Wall -gnatpg s-taprop.adb -o s-taprop.o s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID make[5]: *** [s-taprop.o] Error 1 make[5]: Leaving directory `/xxx/gnu/gcc/objdir/gcc/ada/rts' make[4]: *** [gnatlib] Error 2 make[4]: Leaving directory `/xxx/gnu/gcc/objdir/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/xxx/gnu/gcc/objdir/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/xxx/gnu/gcc/objdir'
[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45801 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #12 from Mikael Pettersson mikpe at it dot uu.se 2010-11-07 20:24:31 UTC --- Bootstrap works again in 4.6 r166408, presumably because r164552 was reverted.
[Bug tree-optimization/46351] New: [4.6 regression] incorrect scalarization (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46351 Summary: [4.6 regression] incorrect scalarization (2) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org The fix for PR tree-opt/44972 has introduced regressions in Ada, specifically: (sra_modify_assign): Removed ref_expr_for_all_replacements_p checks, checks for return values of build_ref_for_offset. This is a second example, which ICEs in tree-sra.c directly because of an offset not multiple of a byte: e...@atlantis:~/build/gcc/native gcc/xgcc -Bgcc -S opt10.adb -O2 +===GNAT BUG DETECTED==+ | 4.6.0 20101106 (experimental) [trunk revision 166404] (x86_64-suse-linux-gnu) GCC error:| | in build_ref_for_offset, at tree-sra.c:1345 | | Error detected around opt10.adb:6:1 This is again a bitfield with aggregate type. I think that the checks of the return values should be reinstated somehow or other. The testcase is suitable for addition to the gnat.dg testsuite.
[Bug tree-optimization/46351] [4.6 regression] incorrect scalarization (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46351 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-07 20:38:11 UTC --- Created attachment 22312 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22312 opt10.adb
[Bug tree-optimization/46351] [4.6 regression] incorrect scalarization (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46351 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-07 20:38:43 UTC --- Created attachment 22313 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22313 opt10_pkg.ads
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.11.07 20:41:31
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.6.0
Ever Confirmed|0 |1
--- Comment #8 from janus at gcc dot gnu.org 2010-11-07 20:41:31 UTC ---
The ICE can be fixed with the following patch:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 166419)
+++ gcc/fortran/trans-array.c (working copy)
@@ -6278,6 +6278,9 @@ structure_alloc_comps (gfc_symbol * der_type, tree
cdecl = c-backend_decl;
ctype = TREE_TYPE (cdecl);
+ if (c-ts.type == BT_CLASS c-ts.u.derived-backend_decl == NULL)
+ gfc_get_derived_type (c-ts.u.derived);
+
switch (purpose)
{
case DEALLOCATE_ALLOC_COMP:
With this the test case from PR46345 gives the output:
Check 0: F
(which apparently is the expected result).
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 davidxl xinliangli at gmail dot com changed: What|Removed |Added CC|davidxl at gcc dot gnu.org |xinliangli at gmail dot com --- Comment #7 from davidxl xinliangli at gmail dot com 2010-11-07 21:12:12 UTC --- It looks to me the problem is caused by double_int arithmetic (mul) overflow which is not properly checked. This results in wrong value range and VRP happily removes the cmp/jmp. Why double_int does not use the widest int type for low/high part on the host? David
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344
--- Comment #9 from janus at gcc dot gnu.org 2010-11-07 21:12:22 UTC ---
(In reply to comment #8)
The ICE can be fixed with the following patch:
Here is a better patch which has the same effect:
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c(revision 166419)
+++ gcc/fortran/trans-types.c(working copy)
@@ -1936,10 +1936,12 @@ gfc_copy_dt_decls_ifequal (gfc_symbol *from, gfc_s
for (; to_cm; to_cm = to_cm-next, from_cm = from_cm-next)
{
to_cm-backend_decl = from_cm-backend_decl;
- if ((!from_cm-attr.pointer || from_gsym)
- from_cm-ts.type == BT_DERIVED)
+ if (from_cm-ts.type == BT_DERIVED
+ (!from_cm-attr.pointer || from_gsym))
gfc_get_derived_type (to_cm-ts.u.derived);
-
+ else if (from_cm-ts.type == BT_CLASS
+(!CLASS_DATA (from_cm)-attr.class_pointer || from_gsym))
+gfc_get_derived_type (to_cm-ts.u.derived);
else if (from_cm-ts.type == BT_CHARACTER)
to_cm-ts.u.cl-backend_decl = from_cm-ts.u.cl-backend_decl;
}
In fact this one pretty much qualifies as obvious, once the location of the
problem has been identified. It's one of those instances where we do something
for BT_DERIVED, but fail to do the analogous thing for BT_CLASS.
I will commit after regtesting.
[Bug tree-optimization/46352] New: ICE: division by zero with -fdump-tree-tracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46352
Summary: ICE: division by zero with -fdump-tree-tracer
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
- testcase.c -
void foo (void)
{
return;
label:;
}
--
Compiler output:
$ gcc -O -freorder-blocks -ftracer -fdump-tree-tracer testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r166414 - crash
4.3.5 - crash
4.2.4 - doesn't know -fdump-tree-tracer
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-07 21:32:12 UTC --- Why double_int does not use the widest int type for low/high part on the host? Not clear what you mean; it uses HOST_WIDE_INT like the rest of the compiler.
[Bug target/46353] New: [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46353 Summary: [4.6 regression] fma testsuite failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: meiss...@gcc.gnu.org Target: powerpc*-*-linux FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvmadd 4 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsmadd 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fmadds 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvmsub 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsmsub 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvnmadd 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsnmadd 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fnmadds 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xvnmsub 2 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times xsnmsub 1 FAIL: gcc.target/powerpc/ppc-fma-1.c scan-assembler-times fnmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvmadd 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsmadd 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fmadds 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvmsub 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsmsub 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvnmadd 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsnmadd 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fnmadds 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xvnmsub 2 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times xsnmsub 1 FAIL: gcc.target/powerpc/ppc-fma-2.c scan-assembler-times fnmsubs 1 FAIL: gcc.target/powerpc/ppc-fma-3.c scan-assembler-times vmaddfp 2 FAIL: gcc.target/powerpc/ppc-fma-3.c scan-assembler-times fmadds 2 FAIL: gcc.target/powerpc/ppc-fma-4.c scan-assembler-times vmaddfp 1 FAIL: gcc.target/powerpc/ppc-fma-4.c scan-assembler-times fmadd 1 FAIL: gcc.target/powerpc/ppc-fma-4.c scan-assembler-times fmadds 1 FAIL: gcc.target/powerpc/ppc-fmadd-1.c scan-assembler-not f(add|sub|mul|neg)
[Bug c/46354] New: attribute((aligned(...))) can incorrectly decrease structure field alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 Summary: attribute((aligned(...))) can incorrectly decrease structure field alignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pagee...@freemail.hu while investigating a clang error when compiling the linux kernel i narrowed the problem down to what seems to be a gcc bug. what happens is that despite what the gcc documentation says about the aligned attribute, gcc does decrease structure field alignment even when the packed attribute is not specified. the attached example shows that the issue is only with the attribute attached to a typedef. the relevant part of the generated asm looks like this for gcc: movqxx+8(%rip), %rax addqx+4(%rip), %rax bug, should be +8 addqp+2(%rip), %rax should it be +4? addqpp+4(%rip), %rax and for clang: movqxx+8(%rip), %rax addqx+8(%rip), %rax addqp+2(%rip), %rax addqpp+4(%rip), %rax the tested gcc versions so far: gcc version 4.4.5 (Gentoo 4.4.5 p1.0, pie-0.4.5) gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) note that fixing this bug will have a non-trivial effect on linux as this construct is relied upon throughout the compat layer (that implements transforming syscall parameters between 32 bit userland and the 64 bit kernel) so when gcc stops decreasing the natural alignment of these structure fields, all such code will have to be changed to explicitly use the packed attribute lest the kernel/userland syscall ABI break... only to run into the next issue in that the packed attribute on the structure ignores the aligned attribute in the typedef (see the +2 above), both in gcc and clang (given both compilers are affected, i'm not sure if this is a bug or feature). more interestingly, if the aligned attribute is on the structure field itself then it is properly taken into account, both in gcc and clang. so this looks like a fine mess to clean up if/when the root bug gets fixed.
[Bug c/46354] attribute((aligned(...))) can incorrectly decrease structure field alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 --- Comment #1 from pageexec at freemail dot hu 2010-11-07 22:43:33 UTC --- Created attachment 22314 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22314 sample code to demonstrate structure field offsets
[Bug c/46354] attribute((aligned(...))) can incorrectly decrease structure field alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-07 23:00:25 UTC --- Generally GCC lays out structures based on the types of the elemets, not based on the alignment specified on fields. Which is why I think what you see is correct and intended.
[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333 Jay jay.krell at cornell dot edu changed: What|Removed |Added Version|4.5.1 |4.6.0 --- Comment #17 from Jay jay.krell at cornell dot edu 2010-11-07 23:01:14 UTC --- unpatched trunk, same as 4.5.1: /home/jkrell/src/gcc-trunk/configure -prefix=$HOME/test1 -enable-build-with-cxx gmake gmake[3]: Entering directory `/home/jkrell/obj/a/libcpp' source='/home/jkrell/src/gcc-trunk/libcpp/charset.c' object='charset.o' libtool=no DEPDIR=.deps depmode=dashXmstdout /bin/bash /home/jkrell/src/gcc-trunk/libcpp/../depcomp CC -I/home/jkrell/src/gcc-trunk/libcpp -I. -I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl -I/home/jkrell/src/gcc-trunk/libcpp/include -g -I/home/jkrell/src/gcc-trunk/libcpp -I. -I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl -I/home/jkrell/src/gcc-trunk/libcpp/include -c /home/jkrell/src/gcc-trunk/libcpp/charset.c /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 619: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 620: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 621: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 622: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 623: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 624: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 625: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 626: Warning (Anachronism): Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to initialize extern C bool(*const)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 643: Warning (Anachronism): Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 666: Warning (Anachronism): Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 679: Warning (Anachronism): Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 687: Warning (Anachronism): Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*). /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 744: Warning (Anachronism): The operation extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) is illegal. /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 746: Warning (Anachronism): The operation extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) is illegal. /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 748: Warning (Anachronism): The operation extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) is illegal. /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 750: Warning (Anachronism): The operation extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) is illegal. /home/jkrell/src/gcc-trunk/libcpp/charset.c, line 752: Warning (Anachronism): The
[Bug target/46353] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46353 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/46351] [4.6 regression] incorrect scalarization (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46351 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334 --- Comment #1 from Jay jay.krell at cornell dot edu 2010-11-07 23:08:17 UTC --- Created attachment 22315 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22315 toplevel config.log
[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334 --- Comment #2 from Jay jay.krell at cornell dot edu 2010-11-07 23:08:57 UTC --- Created attachment 22316 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22316 libcpp config.log
[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334 --- Comment #3 from Jay jay.krell at cornell dot edu 2010-11-07 23:10:50 UTC --- jkr...@login [login]:~/src ssh current10s Last login: Sun Nov 7 23:09:51 2010 from login.bo.opencs Sun Microsystems Inc. SunOS 5.10 Generic January 2005 -bash-4.1$ cd obj -bash-4.1$ mkdir b -bash-4.1$ cd b -bash-4.1$ which gcc no gcc in /home/jkrell/sparc/bin /opt/csw/bin /usr/bin /usr/ccs/bin /opt/csw/bin -bash-4.1$ export CC=/opt/csw/gcc4/bin/gcc -bash-4.1$ $CC -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc Thread model: posix gcc version 4.3.3 (GCC) -bash-4.1$ export CXX=CC -bash-4.1$ $CXX -V CC: Sun C++ 5.9 SunOS_sparc 2007/05/03 -bash-4.1$ which ar /usr/ccs/bin/ar -bash-4.1$ which gmake /opt/csw/bin/gmake -bash-4.1$ which make /usr/ccs/bin/make -bash-4.1$ export MAKE=gmake -bash-4.1$ uname -a SunOS current10s 5.10 Generic_142909-17 sun4v sparc SUNW,SPARC-Enterprise-T5220 /home/jkrell/src/gcc-trunk/configure -prefix=$HOME/test2 -enable-build-with-cxx $MAKE . gmake[3]: Entering directory `/home/jkrell/obj/b/libcpp' source='/home/jkrell/src/gcc-trunk/libcpp/charset.c' object='charset.o' libtool=no DEPDIR=.deps depmode=dashXmstdout /bin/bash /home/jkrell/src/gcc-trunk/libcpp/../depcomp CC -I/home/jkrell/src/gcc-trunk/libcpp -I. -I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl -I/home/jkrell/src/gcc-trunk/libcpp/include -g -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -I/home/jkrell/src/gcc-trunk/libcpp -I. -I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl -I/home/jkrell/src/gcc-trunk/libcpp/include -c /home/jkrell/src/gcc-trunk/libcpp/charset.c CC: Warning: Option -W passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -Wwrite-strings passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -Wmissing-format-attribute passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -pedantic passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored otherwise attached toplevel config.log and libcpp/config.log excerpt: configure:4440: checking whether /opt/csw/gcc4/bin/gcc supports -pedantic -Wno-long-long WARN_PEDANTIC='-pedantic -Wno-long-long' so you can see, CC and CXX are configured the same by autoconf, even though they might not be related.
[Bug c/44772] [4.5 Regression] -Wc++-compat warns incorrectly for anonymous unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44772 --- Comment #6 from Dale Stimson ml-gnu-dale at riyescott dot com 2010-11-07 23:18:23 UTC --- Created attachment 22317 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22317 Backport of Jakub's patch from 4.6 trunk to 4.5.1. The attached patch for gcc 4.5.1 is provided in case it is useful to any one... Thanks to Jakub for solving this problem. This attachment is derived from Jakub's patch by backporting to 4.5.1 (as obtained from the presumably pristine Fedora gcc file gcc-4.5.1-20100924.tar.bz2 from Fedora's gcc-4.5.1-4.fc14.src.rpm). I have lightly tested this. It works for me.
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #9 from davidxl xinliangli at gmail dot com 2010-11-07 23:22:30 UTC --- For i686 target, the HOST_WIDE_INT is 'long int' -- not 'long long'. David
[Bug c/46354] attribute((aligned(...))) can incorrectly decrease structure field alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 --- Comment #3 from pageexec at freemail dot hu 2010-11-07 23:33:54 UTC --- (In reply to comment #2) Generally GCC lays out structures based on the types of the elemets, not based on the alignment specified on fields. according to the gcc docs, explicit alignment on structure fields *is* taken into account in that one can *increase* the natural alignment associated with a given type: The `aligned' attribute can only increase the alignment; but you can decrease it by specifying `packed' as well. See below. in this bug you can see that even without the packed attribute gcc can decrease the alignment. so either the docs or the implementation is buggy ;). the second issue is that when one does use the packed attribute on a structure, the resulting field alignment seems inconsistent depending on where the aligned attribute is (typedef vs. structure field). i don't see where the docs specify or imply this behaviour.
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #10 from davidxl xinliangli at gmail dot com 2010-11-08 00:08:38 UTC --- Need define need_64bit_host_wide_int in configuration which is not done by default. David
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-08 00:53:17 UTC --- For i686 target, the HOST_WIDE_INT is 'long int' -- not 'long long'. Yes, this is the default. By default we don't require a 64-bit type on the host for a 32-bit target, only for a 64-bit target.
[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333 --- Comment #18 from Jay jay.krell at cornell dot edu 2010-11-08 00:57:29 UTC --- more gcc_unreachable and then functions not returning, slightly 4.5.1 with Sun CC (C++): see http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/105/console /usr/bin/CC -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc -I../../gcc-4.5/gcc/. -I../../gcc-4.5/gcc/../include -I../../gcc-4.5/gcc/../libcpp/include -I/home/m3hudson/current10x/workspace/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/cm3/m3-sys/m3cc/I386_SOLARIS/./gmp -I/home/m3hudson/current10x/workspace/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/cm3/m3-sys/m3cc/gcc-4.5/gmp -I/usr/include/libelf insn-output.c -o insn-output.o ../../gcc-4.5/gcc/config/i386/i386.md, line 2987: Error: output_100(rtx_def**, rtx_def*) is expected to return a value. ../../gcc-4.5/gcc/config/i386/i386.md, line 2999: Error: output_101(rtx_def**, rtx_def*) is expected to return a value. ../../gcc-4.5/gcc/config/i386/i386.md, line 3490: Error: output_106(rtx_def**, rtx_def*) is expected to return a value. ../../gcc-4.5/gcc/config/i386/i386.md, line 3502: Error: output_107(rtx_def**, rtx_def*) is expected to return a value. ../../gcc-4.5/gcc/config/i386/i386.md, line 3643: Error: output_111(rtx_def**, rtx_def*) is expected to return a value. I put return 0; after the gcc_unreachable.
[Bug tree-optimization/45948] [4.6 Regression] ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Known to work||4.5.2 Summary|ICE: SIGSEGV in |[4.6 Regression] ICE: |find_uses_to_rename_use |SIGSEGV in |(tree-ssa-loop-manip.c:1242 |find_uses_to_rename_use |) with -O2 |(tree-ssa-loop-manip.c:1242 |-ftree-loop-distribution|) with -O -fstrict-overflow ||-ftree-loop-distribution --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-11-08 01:01:51 UTC --- I did further testing, and this seems to be a regression: Related valgrind output: $ gcc -O -fstrict-overflow -ftree-loop-distribution pr45948.c ==3184== Invalid read of size 8 ==3184==at 0x966569: find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) ==3184==by 0x96683F: find_uses_to_rename_bb (tree-ssa-loop-manip.c:284) ==3184==by 0x966EED: rewrite_into_loop_closed_ssa (tree-ssa-loop-manip.c:331) ==3184==by 0x8D79A9: distribute_loop (tree-loop-distribution.c:1080) ==3184==by 0x8D8A0C: tree_loop_distribution (tree-loop-distribution.c:1201) ==3184==by 0x79980E: execute_one_pass (passes.c:1560) ==3184==by 0x799AB4: execute_pass_list (passes.c:1615) ==3184==by 0x799AC6: execute_pass_list (passes.c:1616) ==3184==by 0x799AC6: execute_pass_list (passes.c:1616) ==3184==by 0x8E6715: tree_rest_of_compilation (tree-optimize.c:422) ==3184==by 0xAB6601: cgraph_expand_function (cgraphunit.c:1493) ==3184==by 0xAB8BC9: cgraph_optimize (cgraphunit.c:1552) ==3184== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==3184== pr45948.c: In function 'foo': pr45948.c:4: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. Tested revisions: r166414 - crash r161659 - crash r159696 - OK 4.5 r165781 - OK
[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334 --- Comment #4 from Jay jay.krell at cornell dot edu 2010-11-08 01:10:25 UTC --- another, this is an older Darwin/powerpc machine, using some version of g++ http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/93/consoleFull g++ -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute-DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o m3cg/m3-convert.o attribs.o main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a -L/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/.libs -lgmp -L/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/.libs -lgmp ld: Undefined symbols: __Z29legitimate_indirect_address_pP7rtx_defi Presumed fix: remove inline on config/rs6000/rs6000.c/legitimate_indirect_address.
[Bug tree-optimization/46355] New: [4.5/4.6 Regression] ICE: SIGSEGV in create_preheader (cfgloopmanip.c:1336) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46355 Summary: [4.5/4.6 Regression] ICE: SIGSEGV in create_preheader (cfgloopmanip.c:1336) with -O -fstrict-overflow -ftree-loop-distribution Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: s...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22318 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22318 reduced testcase I was reducing a testcase that had the same backtrace as PR45948, but the reduced testcase turned out to cause a bit different ICE. It also started crashing at different revision. I don't know how much is this related to PR45948 and PR45199. Related valgrind output: $ gcc -O -ftree-loop-distribution -fstrict-overflow pr46355.c ==20450== Invalid read of size 8 ==20450==at 0x59BF64: create_preheader (cfgloopmanip.c:1336) ==20450==by 0x8D845D: distribute_loop (tree-loop-distribution.c:180) ==20450==by 0x8D8A0C: tree_loop_distribution (tree-loop-distribution.c:1201) ==20450==by 0x79980E: execute_one_pass (passes.c:1560) ==20450==by 0x799AB4: execute_pass_list (passes.c:1615) ==20450==by 0x799AC6: execute_pass_list (passes.c:1616) ==20450==by 0x799AC6: execute_pass_list (passes.c:1616) ==20450==by 0x8E6715: tree_rest_of_compilation (tree-optimize.c:422) ==20450==by 0xAB6601: cgraph_expand_function (cgraphunit.c:1493) ==20450==by 0xAB8BC9: cgraph_optimize (cgraphunit.c:1552) ==20450==by 0xAB9129: cgraph_finalize_compilation_unit (cgraphunit.c:1016) ==20450==by 0x4AC9AB: c_write_global_declarations (c-decl.c:9831) ==20450== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==20450== pr46355.c: In function 'foo': pr46355.c:2: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. Tested revisions: r166414 - crash r153685 - crash 4.5 r165781 - crash 4.4 r165754 - OK
[Bug fortran/46331] Compilation time long with simple function in array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46331 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.08 02:19:56 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-08 02:19:56 UTC --- I have a better patch and will submit it for approval.
[Bug tree-optimization/46355] [4.5/4.6 Regression] ICE: SIGSEGV in create_preheader (cfgloopmanip.c:1336) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46355 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.08 02:25:56 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 02:25:56 UTC --- It is caused by revision 149207: http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00084.html
[Bug fortran/46356] New: Erroneous procedure/intent error and ICE for class dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46356 Summary: Erroneous procedure/intent error and ICE for class dummy argument Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ian_har...@bigpond.com The following example, when compiled with gfortran 4.6 built from trunk source 166232 (20101103), rejects the following code with a dubious errror (PROCEDURE attribute conflicts with INTENT attribute in 'pvec') before the compiler dies with an ICE. I believe the code is valid F2003. It, and the subsequent variations below, are accepted by ifort 11.1.067. MODULE procedure_intent_nonsense IMPLICIT NONE PRIVATE TYPE, PUBLIC :: Parent INTEGER :: comp END TYPE Parent TYPE :: ParentVector INTEGER :: a ! CLASS(Parent), ALLOCATABLE :: a END TYPE ParentVector CONTAINS SUBROUTINE vector_operation(pvec) CLASS(ParentVector), INTENT(INOUT) :: pvec(:) INTEGER :: i !--- DO i = 1, SIZE(pvec) CALL item_operation(pvec(i)) END DO ! PRINT *, pvec(1)%a%comp END SUBROUTINE vector_operation SUBROUTINE item_operation(pvec) CLASS(ParentVector), INTENT(INOUT) :: pvec !TYPE(ParentVector), INTENT(INOUT) :: pvec END SUBROUTINE item_operation END MODULE procedure_intent_nonsense Variants, which may all be just the result of the compiler thinking the pvec argument is a procedure... If the ParentVector component is switched to being the CLASS(Parent) component and the PRINT statement in vector_operation is uncommented, a syntax error that appears to be spurious is generated. Alternatively, if the pvec dummy in item_option is changed to be non-polymorphic, then two additional errors appear and the ICE disappears. One of the additional errors is 'array' argument of 'size' intrinsic at (1) must be an array, referring to the SIZE intrinsic in the DO statement. The argument to the SIZE intrinsic is an array, so this error is spurious. The other additional error is that there is a type mismatch with the argument for in the CALL to item_operation (passed CLASS(...) to TYPE(...)). I believe this is also spurious.
[Bug tree-optimization/45948] [4.6 Regression] ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.08 04:21:15 Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 04:21:15 UTC --- It is caused by revision 159992: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01050.html
[Bug target/46089] ICE: in gen_reg_rtx, at emit-rtl.c:861 with -mcmodel=large -fsplit-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46089 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2010-11-08 04:34:37 UTC --- Author: ian Date: Mon Nov 8 04:34:32 2010 New Revision: 166427 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166427 Log: gcc/: PR target/46089 * config/i386/i386.c (split_stack_fn_large): New static variable. (ix86_expand_split_stack_prologue): Handle large model. libgcc/: * config/i386/morestack.S (__morestack_large_model): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/libgcc/ChangeLog trunk/libgcc/config/i386/morestack.S
[Bug target/46089] ICE: in gen_reg_rtx, at emit-rtl.c:861 with -mcmodel=large -fsplit-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46089 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Resolution||FIXED --- Comment #2 from Ian Lance Taylor ian at airs dot com 2010-11-08 04:37:40 UTC --- Fixed. Thanks for the bug report.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #8 from Dave Korn davek at gcc dot gnu.org 2010-11-08 04:52:12 UTC --- The generated source file selfassign.so.ltrans0.s (and hence also the object file selfassign.so.ltrans0.ltrans.o) file which gets created when lto-plugin invokes lto1 on the original input selfassign.o file has no contents. This appears to be because plugin_init in selfassign.c isn't marked with __attribute__((externally_visible)), and the resolution file marks it as PREVAILING_DEF_IRONLY. WPA then concludes that everything can be made static, nothing is referenced, and discards the lot. The consequence of this is that the object file that the pluging then adds back into the link has no contents, so it doesn't override the symbol definitions supplied from the IR when it first claimed the input selfassign.o file. It works with GOLD because GOLD thinks the plugin's external symbols are PREVAILING_DEF, not PREVAILING_DEF_IRONLY. This is the resolution file that the lto-plugin writes based on what LD tells it at all_symbols_read time: 1 selfassign.o 27 5072 e2eb6ce9 PREVAILING_DEF_IRONLY plugin_init 5105 e2eb6ce9 UNDEF tree_check_failed 5114 e2eb6ce9 UNDEF tree_class_check_failed 5148 e2eb6ce9 UNDEF fancy_abort 5155 e2eb6ce9 UNDEF gimple_check_failed 5165 e2eb6ce9 UNDEF gimple_assign_single_p 5169 e2eb6ce9 UNDEF tree_contains_struct_check_failed 5253 e2eb6ce9 UNDEF build4_stat 5262 e2eb6ce9 UNDEF tree_operand_check_failed 5271 e2eb6ce9 UNDEF fold_build2_stat_loc 5279 e2eb6ce9 UNDEF build3_stat 5287 e2eb6ce9 UNDEF warning_at 5302 e2eb6ce9 UNDEF operand_equal_p 5308 e2eb6ce9 UNDEF maybe_get_identifier 5312 e2eb6ce9 UNDEF integer_zerop 5314 e2eb6ce9 UNDEF register_callback 5324 e2eb6ce9 UNDEF warning 5351 e2eb6ce9 UNDEF plugin_default_version_check 5494 e2eb6ce9 PREVAILING_DEF_IRONLY check_operator_eq 5536 e2eb6ce9 PREVAILING_DEF_IRONLY plugin_is_GPL_compatible 5433 e2eb6ce9 UNDEF tree_code_type 5442 e2eb6ce9 UNDEF tree_code_length 5452 e2eb6ce9 UNDEF gss_for_code_ 5457 e2eb6ce9 UNDEF gimple_ops_offset_ 5471 e2eb6ce9 UNDEF tree_contains_struct 5486 e2eb6ce9 UNDEF input_location 5502 e2eb6ce9 UNDEF cfun ... and here is the one generated when the plugin is loaded into GOLD: 1 selfassign.o 27 5072 e2eb6ce9 PREVAILING_DEF plugin_init 5105 e2eb6ce9 UNDEF tree_check_failed 5114 e2eb6ce9 UNDEF tree_class_check_failed 5148 e2eb6ce9 UNDEF fancy_abort 5155 e2eb6ce9 UNDEF gimple_check_failed 5165 e2eb6ce9 UNDEF gimple_assign_single_p 5169 e2eb6ce9 UNDEF tree_contains_struct_check_failed 5253 e2eb6ce9 UNDEF build4_stat 5262 e2eb6ce9 UNDEF tree_operand_check_failed 5271 e2eb6ce9 UNDEF fold_build2_stat_loc 5279 e2eb6ce9 UNDEF build3_stat 5287 e2eb6ce9 UNDEF warning_at 5302 e2eb6ce9 UNDEF operand_equal_p 5308 e2eb6ce9 UNDEF maybe_get_identifier 5312 e2eb6ce9 UNDEF integer_zerop 5314 e2eb6ce9 UNDEF register_callback 5324 e2eb6ce9 UNDEF warning 5351 e2eb6ce9 UNDEF plugin_default_version_check 5494 e2eb6ce9 PREVAILING_DEF check_operator_eq 5536 e2eb6ce9 PREVAILING_DEF plugin_is_GPL_compatible 5433 e2eb6ce9 UNDEF tree_code_type 5442 e2eb6ce9 UNDEF tree_code_length 5452 e2eb6ce9 UNDEF gss_for_code_ 5457 e2eb6ce9 UNDEF gimple_ops_offset_ 5471 e2eb6ce9 UNDEF tree_contains_struct 5486 e2eb6ce9 UNDEF input_location 5502 e2eb6ce9 UNDEF cfun
[Bug c/46357] New: Unnecessary movzx instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46357
Summary: Unnecessary movzx instruction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: justin.lebar+...@gmail.com
Originally reported to the gcc-help list.
Tested with gcc Ubuntu/Linaro 4.5.1-7ubuntu2, but I get the same code with gcc
4.4.
The following C code generates assembly code with what appears to be an
unnecessary call to movzx:
char skip[] = { /* ... */ };
int foo(const unsigned char *str, int len)
{
int result = 0;
int i = 7;
while (i len) {
if (str[i] == '_' str[i-1] == 'D') {
result |= 2;
}
i += skip[str[i]];
}
return result;
}
foo:
0: 31 c0 xoreax,eax
2: 83 fe 07cmpesi,0x7
5: ba 07 00 00 00 movedx,0x7
a: 7f 14 jg 20 foo+0x20
c: eb 32 jmp40 foo+0x40
e: 66 90 xchg ax,ax
// Beginning of loop
10: 0f b6 c9movzx ecx,cl
13: 0f be 89 00 00 00 00movsx ecx,BYTE PTR [rcx+0x0]
1a: 01 ca addedx,ecx
1c: 39 d6 cmpesi,edx
1e: 7e 20 jle40 foo+0x40
20: 4c 63 c2movsxd r8,edx
23: 42 0f b6 0c 07 movzx ecx,BYTE PTR [rdi+r8*1]
28: 80 f9 5fcmpcl,0x5f
2b: 75 e3 jne10 foo+0x10
// Likely end of loop (i.e. branch above is likely taken)
2d: 41 89 c1movr9d,eax
30: 41 83 c9 02 or r9d,0x2
34: 41 80 7c 38 ff 44 cmpBYTE PTR [r8+rdi*1-0x1],0x44
3a: 41 0f 44 c1 cmove eax,r9d
3e: eb d0 jmp10 foo+0x10
40: f3 c3 repz ret
The movzx on line 10 sets everything except the least-significant bit of ecx to
zero. This is unnecessary since line 23 dominates line 10, so we're guaranteed
that ecx contains zeros everywhere except in its least-significant bit by the
time we get to line 10.
If I change |str| in the C code to a signed char, then line 10 becomes movsx
(now a necessary instruction). Perhaps this gives a hint as to where the errant
instruction is coming from.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #9 from Dave Korn davek at gcc dot gnu.org 2010-11-08 06:27:25 UTC --- (In reply to comment #8) This appears to be because plugin_init in selfassign.c isn't marked with __attribute__((externally_visible)), and the resolution file marks it as PREVAILING_DEF_IRONLY. It works with GOLD because GOLD thinks the plugin's external symbols are PREVAILING_DEF, not PREVAILING_DEF_IRONLY. Thanks to Ian T, I now have an understanding of why GOLD does this: it is because if the ELF symbol visibility is STV_DEFAULT or STV_PROTECTED, GOLD assumes it may be externally referenced, perhaps dynamically at runtime, so doesn't resolve it _IRONLY. I'll need to adjust GNU LD to match this behaviour. (Can't work around it just by tagging __attribute__((externally_visible)) onto the definition of plugin_init in selfassign.c, because cc1 has been lto-bootstrapped, and all the symbols that the plugin wants to reference have been made static for the same reason - they are seen as IRONLY - so the plugin can't resolve them and dlopen'ing it fails.)
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316 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 2010-11-08 07:03:37 UTC --- Won't there be similar problem when using TImode IVs on 64-bit targets (e.g. __int128 or int __attribute__((mode (TI ? Normally overflows are detected when doing computations on trees rather than just in double_int.
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316
--- Comment #13 from davidxl xinliangli at gmail dot com 2010-11-08 07:13:03
UTC ---
(In reply to comment #12)
Won't there be similar problem when using TImode IVs on 64-bit targets (e.g.
__int128 or int __attribute__((mode (TI ?
Normally overflows are detected when doing computations on trees rather than
just in double_int.
yes. The following is the fix to this particular problem.
Index: tree-vrp.c
===
--- tree-vrp.c(revision 166426)
+++ tree-vrp.c(working copy)
@@ -3402,24 +3402,34 @@ adjust_range_with_scev (value_range_t *v
|| get_value_range (init)-type == VR_RANGE))
{
value_range_t maxvr = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
- double_int dtmp;
- dtmp = double_int_mul (tree_to_double_int (step),
- double_int_sub (loop-nb_iterations_upper_bound,
- double_int_one));
- tem = double_int_to_tree (TREE_TYPE (init), dtmp);
- /* If the multiplication overflowed we can't do a meaningful
- adjustment. */
- if (double_int_equal_p (dtmp, tree_to_double_int (tem)))
-{
- extract_range_from_binary_expr (maxvr, PLUS_EXPR,
- TREE_TYPE (init), init, tem);
- /* Likewise if the addition did. */
- if (maxvr.type == VR_RANGE)
-{
- tmin = maxvr.min;
- tmax = maxvr.max;
-}
-}
+ double_int upper_bound_m1, step_int, dtmp;
+ bool unsigned_p;
+
+ upper_bound_m1 = double_int_sub (loop-nb_iterations_upper_bound,
+ double_int_one);
+ step_int = tree_to_double_int (step);
+ dtmp = double_int_mul (step_int, upper_bound_m1);
+ unsigned_p = TYPE_UNSIGNED (TREE_TYPE (step));
+ /* Check overflow. */
+ if (double_int_equal_p (upper_bound_m1,
+ double_int_div (dtmp, step_int,
+ unsigned_p, ROUND_DIV_EXPR)))
+{
+ tem = double_int_to_tree (TREE_TYPE (init), dtmp);
+ /* If the multiplication overflowed we can't do a meaningful
+ adjustment. */
+ if (double_int_equal_p (dtmp, tree_to_double_int (tem)))
+{
+ extract_range_from_binary_expr (maxvr, PLUS_EXPR,
+ TREE_TYPE (init), init, tem);
+ /* Likewise if the addition did. */
+ if (maxvr.type == VR_RANGE)
+{
+ tmin = maxvr.min;
+ tmax = maxvr.max;
+}
+}
+}
}
if (vr-type == VR_VARYING || vr-type == VR_UNDEFINED)
[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46114 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #14 from Steven Bosscher steven at gcc dot gnu.org 2010-11-08 07:30:47 UTC --- Fixed by the commit that reverted bernds' patch.
