[Bug driver/48306] [4.4 Regression] presence of gcc subdir with . in PATH causes breakdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48306 Jakub Jelinek changed: What|Removed |Added CC||mmlr at mlotz dot ch --- Comment #13 from Jakub Jelinek 2012-08-16 06:58:19 UTC --- *** Bug 38966 has been marked as a duplicate of this bug. ***
[Bug bootstrap/54260] GCC 4.7.1 fails to build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54260 --- Comment #4 from Mikael Pettersson 2012-08-16 07:24:56 UTC --- (In reply to comment #3) > 99 /home/Feto/sw/gcc/build/./gcc/cc1: error while loading shared libraries: > libmpc.so.2: cannot open shared object > file: No such file or directory You failed to inform the dynamic linker where to find libmpc.so. Set LD_LIBRARY_PATH to something like "/usr/local/lib:".
[Bug target/54280] New: AVR target: -mmcu=atxmega128b support missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54280
Bug #: 54280
Summary: AVR target: -mmcu=atxmega128b support missing
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ha...@debian.org
Forwarding Debian Bug#684226 reported by a...@avarner.servebeer.com:
Using the version of avr-gcc that comes with Atmel Studio 6.0 (for Windows,
unfortunately), -mmcu=atxmega128b1 is accepted:
$ cat xmegab1test.c
#include
int main(void)
{
while(1)
{
//TODO:: Please write your application code
}
}
$ 'C:\Program Files\Atmel\Atmel Studio
6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin\avr-gcc' -o /dev/null
-mmcu=atxmega128b1 xmegab1test.c -Wall -Wextra
$ echo $?
0
$ 'C:\Program Files\Atmel\Atmel Studio
6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin\avr-gcc' --version
avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug bootstrap/54260] GCC 4.7.1 fails to build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54260 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Jonathan Wakely 2012-08-16 07:44:32 UTC --- These links explain that the support libraries must be in the dynamic linker's search path: (In reply to comment #2) > Did you read http://gcc.gnu.org/wiki/FAQ#configure_suffix ? > > http://gcc.gnu.org/wiki/InstallingGCC explains how to avoid that issue If you follow those instructions it will work. That's why I provided the links.
[Bug c++/51494] Legal program rejection - capturing "this" when using static method inside lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org --- Comment #6 from Paolo Carlini 2012-08-16 09:53:36 UTC --- Not actively working on this.
[Bug middle-end/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 --- Comment #5 from Tobias Burnus 2012-08-16 09:56:51 UTC --- > c) For the program in comment 0, one enters rtx_for_function_call [...] > However, that function is called *AFTER* check_global_declaration_1 and comes > thus too late. check_global_declaration_1 is called write_global_declarations via compile_file via do_compile While rtx_for_function_call is later also called via write_global_declarations -> finalize_compilation_unit -> output_in_order -> expand_function -> execute_pass_list -> execute_one_pass -> ... -> expand_call_stmt -> ... In C, one has the same order - except that TREE_USED is already set. My impression is that in C it gets set when the DECL is 'created' in the caller. * * * Hence, I think one should think of handling it on Fortran FE level by setting USE_TREE. For procedures, I think we need to cover procedure calls, proc-pointer assignments and proc-pointer assignments via initializers and default initializers. On tree level, we could either plug into gfc_trans_pointer_assignment and conv_function_val - or make some use of attr.referenced (though, the latter seems to be also set for uncalled functions). Not as important as we do not currently get a bogus warning, but still nice to have: A warning for PRIVATE module variables. For module m private integer, save :: var ! = 5 end module m we always set TREE_USED in gfc_finish_var_decl. One could check whether simply not doing so for private variables is sufficient to get a warning, but I am not sure whether we won't run into the problem of getting the diagnostic in check_global_declaration_1 sym->referenced is always set: It is set before gfc_create_module_variable and it is unconditionally set in that function. (EQUIVALENCE with PRIVATE/PUBLIC has to be handled as well.)
[Bug c++/52806] "zero as null pointer constant" in C++98 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52806 --- Comment #6 from Paolo Carlini 2012-08-16 10:07:10 UTC --- See my Comment #2 and #3: I'm still convinced that the warning can be useful in C++98 mode too. Unless Jason or another C++ front-end maintainer overrules me, I'm not going to do anything about this.
[Bug target/25629] -mcpu=601 doesn't use MQ register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25629 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution||WONTFIX --- Comment #2 from Segher Boessenkool 2012-08-16 10:12:11 UTC --- Nothing will ever use the MQ register anymore: all support for the old POWER ISA has been removed, and PowerPC does not have an MQ register.
[Bug middle-end/41743] Missing loop optimisation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41743 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Segher Boessenkool 2012-08-16 10:26:21 UTC --- Indeed, closing as fixed.
[Bug c++/52806] "zero as null pointer constant" in C++98 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52806 --- Comment #7 from Jonathan Wakely 2012-08-16 10:33:38 UTC --- (In reply to comment #4) > Unfortunately the user *will* have warnings if she passes the > warning flag but not -std=c++11. So don't use that warning flag. It's not included in -Wall for good reason.
[Bug middle-end/41741] -Os generates bigger code than -O2 for simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41741 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Segher Boessenkool 2012-08-16 10:34:42 UTC --- Current mainline does: memset: addi 5,5,1 li 9,0 mtctr 5 b .L2 .L3: stbx 4,3,9 addi 9,9,1 .L2: bdnz .L3 blr So closing as fixed.
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/41742] Unnecessary zero-extension at -O2 but not -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41742 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-16 CC||segher at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Segher Boessenkool 2012-08-16 10:39:45 UTC --- Still happens on mainline: -O2 still has the superfluous sign-extend, but now the -O1 code is perfect.
[Bug tree-optimization/54271] [4.7/4.8 Regression] libgcrypt CRC24RFC2440 30% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54271 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.7.2 --- Comment #2 from Richard Guenther 2012-08-16 10:41:11 UTC --- I'd say wontfix then. No need to waste time fixing bogus benchmarks.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #48 from Steven Bosscher 2012-08-16 10:52:20 UTC --- Author: steven Date: Thu Aug 16 10:52:14 2012 New Revision: 190442 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190442 Log: PR middle-end/54146 * tree-flow.h (compute_global_livein): Remove prototype. * tree-into-ssa.c (compute_global_livein): Remove function. * tree-ssa-loop-manip.c: Include gimple-pretty-print.h. (find_sibling_superloop): New function. (compute_live_loop_exits): New function. (add_exit_phis_edge): Rename to add_exit_phi. Do not allow inserting a PHI in a block that is not a loop exit for VAR. Add dumping if TDF_DETAILS. (add_exit_phis_var): Rewrite. (add_exit_phis): Update. (get_loops_exits): Rewrite to return an array of per-loop exits rather than one bitmap with all loop exits. (find_uses_to_rename_bb): Ignore virtual PHI nodes. (rewrite_into_loop_closed_ssa): Update. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-into-ssa.c trunk/gcc/tree-ssa-loop-manip.c
[Bug bootstrap/54281] New: [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 Bug #: 54281 Summary: [4.8 Regression] Fails to bootstrap with --disable-nls Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org With --disable-nls intl.h does #ifdef ENABLE_NLS #include extern void gcc_init_libintl (void); extern size_t gcc_gettext_width (const char *); #else /* Stubs. */ # undef textdomain # define textdomain(domain) (domain) # undef bindtextdomain # define bindtextdomain(domain, directory) (domain) # undef gettext # define gettext(msgid) (msgid) which wrecks an included libintl.h: extern char *(__const char *__msgid) throw () __attribute__ ((__format_arg__ (1))); and g++ rightfully complains. We end up including libintl.h through gcc/double-int.h #include #include (here from GCC 4.1) #include #include
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 Richard Guenther changed: What|Removed |Added CC||dnovillo at gcc dot ||gnu.org, iant at google dot ||com --- Comment #1 from Richard Guenther 2012-08-16 11:01:51 UTC --- Diego / Ian, can any of you try to fix this? Possibly by looking for and including libintl.h before re-defining those macros? It's the toplevel intl.h btw. Broke all our autotesters ...
[Bug other/54279] [4.8 Regression] first stage build with g++ fails with "." as the first component of $PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54279 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/53343] [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' breaks bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53343 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/53062] [4.8 Regression] 445.gobmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug debug/53671] [4.8 Regression] Many guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #10 from Alexandre Oliva 2012-07-06 11:37:19 UTC --- Author: aoliva Date: Fri Jul 6 11:37:14 2012 New Revision: 189325 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189325 Log: PR rtl-optimization/53827 PR debug/53671 PR debug/49888 * alias.c (memrefs_conflict_p): Adjust offset and size by the same amount for alignment ANDs. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c
[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53839 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53876 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug other/53923] [4.8 Regression] ICE: RTL check: expected code 'reg', have 'debug_expr' in rhs_regno, at rtl.h:1091
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53923 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/54144] [4.6 Regression] With -std=c++0x certain incorrect arguments to map.insert cause gcc crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54144 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug tree-optimization/54153] [4.8 Regression] Bytemark IDEA 6% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54153 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libstdc++/54228] [4.6 Regression] 22_locale/num_put/put/char/9780-2.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54228 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2 Summary|[4.7 Regression] Bad|[4.7/4.8 Regression] Bad |alignment code generated|alignment code generated |for Neon loads |for Neon loads
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 --- Comment #2 from Richard Guenther 2012-08-16 11:18:42 UTC --- Another fix is to include all system headers (and thus gmp.h) from system.h which always comes before includes of intl.h.
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 --- Comment #3 from Richard Guenther 2012-08-16 11:22:06 UTC --- Fails with a 4.1 host libstdc++, succeeds with a 4.6 host libstdc++.
[Bug target/54272] [SH] Add support for addv / subv instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272 --- Comment #2 from Kazumoto Kojima 2012-08-16 11:23:42 UTC --- (In reply to comment #1) For linux environment, libc's abort function is a rather complex function and trapa handler should do equivalent things to keep complete binary compatibility. I guess that it isn't worth to do so. You can introduce simple trapa sequence as an ABI changing -m option on linux, though trap numbers < 32 are allocated for the syscalls and all other numbers are given for debug purposes and generate SIGTRAP with modified pc which points to trapa instruction itself. If the user program uses its own SIGTRAP handlers, this might be problematic. Perhaps the "sleep" instruction will be a candidate because current libc uses it for ABORT_INSTRUCTION, though it would be bad for bare metal cases. BTW, there is a known SH4 core bug for trapa instruction and we are using 5 or r0,r0 instructions just after trapa. See libitm/ config/sh/futex_bits.h for example.
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 --- Comment #4 from Diego Novillo 2012-08-16 12:04:59 UTC --- Tentative fix: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01046.html Don't have an old enough compiler to test it myself. Need help with testing.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Richard Guenther changed: What|Removed |Added Keywords||memory-hog --- Comment #49 from Richard Guenther 2012-08-16 12:10:56 UTC --- We still use very much memory (full testcase doesn't fit in 4GB ram). With ... check(); //check(); //check >(); //check >(); //check(); //check(); //check(); //check(); I see (--enable-gather-detailed-mem-stats): Kind Nodes Bytes --- decls1116380 181227400 types 535841 90021288 blocks222522 17801760 stmts 457492068872 refs 854577 43178392 exprs2147881 95117920 constants 1401324176820 identifiers737106486480 vecs 2654190 131466648 binfos 481624873432 ssa names 339369 27149520 constructors 26426 634224 random kinds 1885177 73894984 lang_decl kinds 352117 13918872 lang_type kinds482187329136 omp clauses0 0 --- Total10490451 699345748 a lot of memory in TREE_VECs for some reason. GIMPLE statements Kind Stmts Bytes --- assignments 316019 30602376 phi nodes 54994 15777472 conditionals 260902504640 everything else 237509 23110772 --- Total 634612 71995260 gimple is lean, so is RTL ;) Alloc-pool Kind Elt size Pools Allocated (elts)Peak (elts)Leak (elts) -- live ranges40513 19250760(481269) 10800800( 270020) 0( 0) df_scan ref base 56 1026 331010008( 5910893) 14059808( 251068) 0( 0) df_scan ref artificial 64 1026 20113600(314275)4239872( 66248) 0( 0) df_scan ref regular64 1026 66557568( 1039962)4543872( 70998) 0( 0) are by far the biggest alloc-pool users. bitmap stats are confusing because they show leaks for bitmaps we free by releasing their obstack. DF and PTA bitmaps are largest. We leak some VECs ... c-family/c-pragma.c:619 (push_visibility)24: 0.0% 24 1: 0.0% cp/pt.c:471 (maybe_begin_member_template_process 24: 0.0% 24 1: 0.0% function.c:4513 (push_struct_function) 40: 0.0% 40 1: 0.0% vec.c:307 (vec_stack_p_reserve_exact_1) 40: 0.0% 40 1: 0.0% tree-ssa-loop-ivopts.c:3070 (multiplier_allowed_328: 0.0%608 3: 0.0% tree-ssa-loop-ivopts.c:3153 (get_address_cost) 328: 0.0%608 3: 0.0% tree-ssa-sccvn.c:745 (copy_reference_ops_from_re392: 0.0% 806232 102098: 4.6% cfgloop.h:583 (fel_init)480: 0.0%860 106: 0.0% c-family/c-pragma.c:1246 (c_register_pragma_1) 584: 0.0%696 4: 0.0% function.c:156 (push_function_context) 976: 0.0% 1200 8: 0.0% ira.c:3699 (find_moveable_pseudos) 1240: 0.0% 221128 513: 0.0% passes.c:2188 (execute_one_pass) 4360: 0.1% 655320 16466: 0.7% tree-ssa-structalias.c:3870 (handle_lhs_call) 9576: 0.2% 18360 133: 0.0% ipa-ref.c:55 (ipa_record_reference) 60184: 1.1% 327640 5813: 0.3% cfgloop.c:1143 (get_loop_exit_edges) 73184: 1.3% 157888 62221: 2.8% tree-into-ssa.c:940 (mark_phi_for_rewrite) 153360: 2.7% 164096 17: 0.0% cfgloop.c:1134 (get_loop_exit_edges) 166592: 3.0% 238712 11639: 0.5% ipa-reference.c:184 (set_reference_optimization_ 180248: 3.2% 248064 47: 0.0% tree-into-ssa.c:321 (get_ssa_name_ann) 627448:11.2% 716496 14: 0.0% tree-ssa-sccvn.c:3657 (extract_and_process_scc_f1246864:22.3%1291960 105903: 4.7% tree-ssa-loop-im.c:1562 (record_mem_ref_loc)1292560:23.1%1392576 55465: 2.5% tree-ssa-loop-im.c:1551 (record_mem_ref_loc)1771800:31.7%3141360 52717: 2.4% I'll look at the loop and sccvn parts.
[Bug target/54272] [SH] Add support for addv / subv instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272 --- Comment #3 from Oleg Endo 2012-08-16 12:43:09 UTC --- (In reply to comment #2) > (In reply to comment #1) > > For linux environment, libc's abort function is a rather complex > function and trapa handler should do equivalent things to keep > complete binary compatibility. I guess that it isn't worth to do > so. You can introduce simple trapa sequence as an ABI changing -m > option on linux, though trap numbers < 32 are allocated for the > syscalls and all other numbers are given for debug purposes and > generate SIGTRAP with modified pc which points to trapa instruction > itself. If the user program uses its own SIGTRAP handlers, this > might be problematic. Perhaps the "sleep" instruction will be > a candidate because current libc uses it for ABORT_INSTRUCTION, > though it would be bad for bare metal cases. > BTW, there is a known SH4 core bug for trapa instruction and we > are using 5 or r0,r0 instructions just after trapa. See libitm/ > config/sh/futex_bits.h for example. Thanks a lot for the hints! Just for the record, the SH7750 / SH7751 trapa bug is described here http://documentation.renesas.com/doc/products/mpumcu/tu/tnsh7456ae.pdf Taking this into account, the trapa insn suddenly seems very unattractive for this purpose ;) How about small variation: mov.l .Loverflow_trap, r1 addv r4,r5 bf 0f jsr @r1 0: nop 'overflow_trap' then would be a library function in libgcc lib1funcs.S, like e.g. the dynamic shift functions for SH2. The default implementation of overflow_trap could simply invoke abort to stay in line with the other trapping operations in libgcc. For bare metal cases, users can provide their own libgcc implementation and do whatever they want.
[Bug c/54282] New: GCC generates incorrect code for the PDP-11 target when -Os or -O2 is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54282 Bug #: 54282 Summary: GCC generates incorrect code for the PDP-11 target when -Os or -O2 is specified Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jguillau...@gmail.com Created attachment 28029 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28029 Compiler generated file When doing an indirect function call (using a function pointer table), GCC generates incorrectly the JSR instruction. Assuming than R0 contains the address of the pointer to the function to call, the correct instruction would be: JSR PC,@(R0) The compiler generates instead: JSR PC,(R0) That causes the machine to jump to the pointer address instead of jumping to the function address. Oddly enough, the assembly (*.s) file generated it I specify the -S option is right: mov _trap_table.1213+02(r0), -(sp) add $_trap_table.1213, r0 jsr pc, @(r0) But the compiled code in the *.o file, shown using the objdump utility is wrong: 66: 1066mov r1, -(sp) 68: 1c26 0082 mov 202(r0), -(sp) 6c: 65c0 0080 add $200, r0 70: 09c8jsr pc, (r0) Compiler output: Usant especificacions internes. COLLECT_GCC=pdp11-aout-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/pdp11-aout/4.6.4/lto-wrapper Target: pdp11-aout Configurat amb: ../gcc/configure --enable-languages=c --target=pdp11-aout --with-newlib Model de fils: single gcc version 4.6.4 20120725 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-S' '-Os' '-Wall' '-Wextra' /usr/local/libexec/gcc/pdp11-aout/4.6.4/cc1 -E -quiet -v indirect_call_table.c -Wall -Wextra -Os -fpch-preprocess -o indirect_call_table.i ignorant el directori inexistent "/usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/sys-include" la recerca de #include "..." s'inicia aquí: la recerca de #include <...> s'inicia aquí: /usr/local/lib/gcc/pdp11-aout/4.6.4/include /usr/local/lib/gcc/pdp11-aout/4.6.4/include-fixed /usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/include Fi de la llista de recerca. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-S' '-Os' '-Wall' '-Wextra' /usr/local/libexec/gcc/pdp11-aout/4.6.4/cc1 -fpreprocessed indirect_call_table.i -quiet -dumpbase indirect_call_table.c -auxbase indirect_call_table -Os -Wall -Wextra -version -o indirect_call_table.s GNU C (GCC) version 4.6.4 20120725 (prerelease) (pdp11-aout) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.6.4 20120725 (prerelease) (pdp11-aout) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4e94c29ebf077b5bb93c64c5b111b8f7 indirect_call_table.c: In function ‘muxx_systrap_handler’: indirect_call_table.c:30:7: avís: variable ‘rc’ set but not used [-Wunused-but-set-variable] indirect_call_table.c: In function ‘muxx_svc_conputc’: indirect_call_table.c:48:1: avís: no hi ha una declaració de retorn en una funció que retorna "non-void" [-Wreturn-type] indirect_call_table.c:44:33: avís: unused parameter ‘np’ [-Wunused-parameter] indirect_call_table.c: In function ‘muxx_svc_muxxhlt’: indirect_call_table.c:52:1: avís: no hi ha una declaració de retorn en una funció que retorna "non-void" [-Wreturn-type] indirect_call_table.c:50:33: avís: unused parameter ‘np’ [-Wunused-parameter] indirect_call_table.c:50:45: avís: unused parameter ‘args’ [-Wunused-parameter] indirect_call_table.c: In function ‘muxx_unimpl’: indirect_call_table.c:55:28: avís: unused parameter ‘np’ [-Wunused-parameter] indirect_call_table.c:55:40: avís: unused parameter ‘args’ [-Wunused-parameter] indirect_call_table.c: In function ‘muxx_systrap_handler’: indirect_call_table.c:42:1: avís: el control arriba a el final d'una funció que no és void [-Wreturn-type] COMPILER_PATH=/usr/local/libexec/gcc/pdp11-aout/4.6.4/:/usr/local/libexec/gcc/pdp11-aout/4.6.4/:/usr/local/libexec/gcc/pdp11-aout/:/usr/local/lib/gcc/pdp11-aout/4.6.4/:/usr/local/lib/gcc/pdp11-aout/:/usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/bin/ LIBRARY_PATH=/usr/local/lib/gcc/pdp11-aout/4.6.4/:/usr/local/lib/gcc/pdp11-aout/4.6.4/../../../../pdp11-aout/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-S' '-Os' '-Wall' '-Wextra'
[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966 --- Comment #12 from Tom Tignor 2012-08-16 12:59:39 UTC --- Hi Jakub, Can you tell me what gcc version has the fix? Read through 48306 and saw "Fixed in 4.5+" but I have a colleague here who is able to reproduce on 4.5.1. Tom:-) From: "jakub at gcc dot gnu.org" To: Thomas Tignor/Marlborough/IBM@IBMUS Date: 08/16/2012 02:59 AM Subject:[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #11 from Jakub Jelinek 2012-08-16 06:58:19 UTC --- Dup of PR48306. *** This bug has been marked as a duplicate of bug 48306 ***
[Bug target/54272] [SH] Add support for addv / subv instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272 --- Comment #4 from Kazumoto Kojima 2012-08-16 13:00:37 UTC --- (In reply to comment #3) > How about small variation: Sounds reasonable to me.
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 --- Comment #5 from Diego Novillo 2012-08-16 13:28:27 UTC --- Author: dnovillo Date: Thu Aug 16 13:28:13 2012 New Revision: 190444 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190444 Log: 2012-08-16 Diego Novillo PR bootstrap/54281 * double-int.h: Move including of gmp.h ... * system.h: ... here. * realmpfr.h: Do not include gmp.h. * tree-ssa-loop-niter.c: Do not include gmp.h. fortran/ChangeLog * gfortran.h: Do not include gmp.h. Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.h trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/realmpfr.h trunk/gcc/system.h trunk/gcc/tree-ssa-loop-niter.c
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 Diego Novillo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Diego Novillo 2012-08-16 13:30:22 UTC --- Fixed at rev 190444.
[Bug bootstrap/54283] New: [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 Bug #: 54283 Summary: [4.8 regression] build tools don't run after cxx-conversion merge Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: cr...@gcc.gnu.org, dnovi...@gcc.gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* Since the merge of the cxx-conversion branch, Solaris bootstrap fails for me. In stage 1, the build tools fail to run, e.g. build/genmddeps /vol/gcc/src/hg/trunk/local/gcc/config/i386/i386.md > tmp-mddeps ld.so.1: genmddeps: fatal: libstdc++.so.6: open failed: No such file or directory make[3]: *** [s-mddeps] Killed make[3]: *** Waiting for unfinished jobs I'm using a self-built gcc 4.4.2 as bootstrap compiler, installed into /vol/gcc-4.4. In order to assure that the libstdc++.so.6 included there is found, I've so far been configuring with --with-host-libstdcxx=\'-L/vol/gcc-4.4/lib -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm\' --with-boot-ldflags=\'-static-libstdc++' -static-libgcc -L/vol/gcc-4.4/lib\' This is not enough after the conversion since the build tools don't use either $BOOT_LDFLAGS or $HOST_LIBS. The attached patch allowed the bootstrap to finish, but is obviously wrong as-is since it doesn't correctly distinguish between build and host tools. Having never run a canadian cross myself, I'm not sure what the right approach is. The first part (using $CC as linker instead of $CXX_FOR_BUILD) is necessary to avoid linking with g++ which links with -lstdc++ on its own. Rainer
[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53839 --- Comment #2 from H.J. Lu 2012-08-16 13:46:24 UTC --- It was triggered by revision 176549: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00816.html But ICE is always there.
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 --- Comment #1 from Rainer Orth 2012-08-16 13:53:37 UTC --- Created attachment 28030 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28030 hacky patch
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #50 from stevenb.gcc at gmail dot com 2012-08-16 13:55:40 UTC ---
On Thu, Aug 16, 2012 at 2:10 PM, rguenth at gcc dot gnu.org
wrote:
> bitmap stats are confusing because they show leaks for bitmaps we free
> by releasing their obstack. DF and PTA bitmaps are largest.
The bitmap obstack stats are not very reliable anyway, I think. I've
been using my own stats for this (with a size_t version of
obstack_memory_used:
+static size_t
+obstack_memory_used2 (struct obstack *h)
+{
+ struct _obstack_chunk* lp;
+ size_t nbytes = 0;
+
+ for (lp = h->chunk; lp != 0; lp = lp->prev)
+{
+ nbytes += (size_t) (lp->limit - (char *) lp);
+}
+ return nbytes;
+}
+
so that also the "freed" bitmap elements are counted). With that, you
can show that the reg_obstack and bitmap_default_obstack grow up to
several GB that isn't released between passes. An added problem is
that IRA puts its bitmap on its own obstack (as it should, really) but
that means the >3GB of free elements on the reg_obstack and
bitmap_default_obstack remain unused. So on the machine I use for
testing (cfarm gcc17), the memory footprint is reduced by >2GB (~25%)
with this hack:
Index: ira.c
===
--- ira.c (revision 190442)
+++ ira.c (working copy)
@@ -4132,6 +4132,12 @@
int max_regno_before_ira, ira_max_point_before_emit;
int rebuild_p;
+ /* There shouldn't be anything on these obstacks. */
+ bitmap_obstack_release (NULL);
+ bitmap_obstack_initialize (NULL);
+ bitmap_obstack_release (®_obstack);
+ bitmap_obstack_initialize (®_obstack);
+
if (flag_caller_saves)
init_caller_save ();
There is in general a lot of BITMAP_ALLOC(NULL) abuse in the compiler.
I have patches to address the cases in tree-ssa-live.c and dse.c, and
I intend to look at the tree-ssa-ter and cfgexpand cases this weekend.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #51 from rguenther at suse dot de
2012-08-16 14:06:06 UTC ---
On Thu, 16 Aug 2012, stevenb.gcc at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
>
> --- Comment #50 from stevenb.gcc at gmail dot com com> 2012-08-16 13:55:40 UTC ---
> On Thu, Aug 16, 2012 at 2:10 PM, rguenth at gcc dot gnu.org
> wrote:
> > bitmap stats are confusing because they show leaks for bitmaps we free
> > by releasing their obstack. DF and PTA bitmaps are largest.
>
> The bitmap obstack stats are not very reliable anyway, I think. I've
> been using my own stats for this (with a size_t version of
> obstack_memory_used:
>
> +static size_t
> +obstack_memory_used2 (struct obstack *h)
> +{
> + struct _obstack_chunk* lp;
> + size_t nbytes = 0;
> +
> + for (lp = h->chunk; lp != 0; lp = lp->prev)
> +{
> + nbytes += (size_t) (lp->limit - (char *) lp);
> +}
> + return nbytes;
> +}
> +
>
> so that also the "freed" bitmap elements are counted). With that, you
> can show that the reg_obstack and bitmap_default_obstack grow up to
> several GB that isn't released between passes. An added problem is
Hum, I thought we release those obstacks after each pass ...
[Bug target/54284] New: -mabi=ieeelongdouble problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54284 Bug #: 54284 Summary: -mabi=ieeelongdouble problems Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: seg...@gcc.gnu.org CC: berg...@vnet.ibm.com, dje@gmail.com, meiss...@gcc.gnu.org Target: powerpc-* As I noted in http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01017.html , there are quite a few problems with -mabi=ieeelongdouble. On 64-bit Linux it crashes the compiler: Program received signal SIGSEGV, Segmentation fault. 0x10578da4 in simplify_subreg (outermode=TImode, op=0xfffb69b1160, innermode=TFmode, byte=0) at /home/segher/src/gcc/gcc/simplify-rtx.c:5429 The other issues are more minor, but the option obviously suffers from a lack of testing.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #52 from Richard Guenther 2012-08-16 14:27:59 UTC --- Author: rguenth Date: Thu Aug 16 14:27:51 2012 New Revision: 190445 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190445 Log: 2012-08-16 Richard Guenther PR middle-end/54146 * tree-ssa-loop-niter.c (find_loop_niter_by_eval): Free the exit vector. * ipa-pure-const.c (analyze_function): Use FOR_EACH_LOOP_BREAK. * cfgloop.h (FOR_EACH_LOOP_BREAK): Fix. * tree-ssa-structalias.c (handle_lhs_call): Properly free rhsc. * tree-into-ssa.c (get_ssa_name_ann): Allocate info only when needed. * tree-ssa-loop-im.c (analyze_memory_references): Adjust. (tree_ssa_lim_finalize): Free all mem_refs. * tree-ssa-sccvn.c (extract_and_process_scc_for_name): Free scc when bailing out. * modulo-sched.c (sms_schedule): Use FOR_EACH_LOOP_BREAK. * ira-build.c (loop_with_complex_edge_p): Free loop exit vector. * graphite-sese-to-poly.c (scop_ivs_can_be_represented): Use FOR_EACH_LOOP_BREAK. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.h trunk/gcc/graphite-sese-to-poly.c trunk/gcc/ipa-pure-const.c trunk/gcc/ira-build.c trunk/gcc/modulo-sched.c trunk/gcc/tree-into-ssa.c trunk/gcc/tree-ssa-loop-im.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-structalias.c
[Bug fortran/54285] New: [F03] Calling a PPC with proc-ptr result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54285 Bug #: 54285 Summary: [F03] Calling a PPC with proc-ptr result Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org The following (supposedly valid) test case ... type :: t procedure(a), pointer, nopass :: p end type type(t) :: x procedure(iabs), pointer :: pp x%p => a pp => x%p() ! "Invalid character in name at (1)" print *,pp(-3) contains function a() result (b) procedure(iabs), pointer :: b b => iabs end function end triggers the error: pp => x%p() 1 Error: Invalid character in name at (1)
[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53839 --- Comment #3 from Paolo Carlini 2012-08-16 14:45:03 UTC --- I see. Jonathan, I guess a reduced testcase not including anything would be very useful anyway (even if the ICE is very old)
[Bug c++/53839] [4.7/4.8 Regression] [C++11] internal compiler error: in adjust_temp_type, at cp/semantics.c:6391
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53839 --- Comment #4 from Jonathan Wakely 2012-08-16 14:58:53 UTC --- I'll see what I can do.
[Bug fortran/54286] New: [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54286 Bug #: 54286 Summary: [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org The following test is probably invalid, but not rejected by recent trunk versions: type :: t procedure(a), pointer, nopass :: p end type type(t) :: x procedure(iabs), pointer :: pp x%p => a ! ok x%p => a(1) ! invalid, but not rejected by 4.8 pp => a(2) ! ok pp => a ! invalid, but not rejected by 4.8 contains function a (c) result (b) integer, intent(in) :: c procedure(iabs), pointer :: b b => iabs end function end gfortran 4.7 rejects it with: x%p => a(1) 1 Error: Interface mismatch in procedure pointer assignment at (1): Type/rank mismatch in return value of 'b' pp => a 1 Error: Interface mismatch in procedure pointer assignment at (1): Type/rank mismatch in return value of 'a' However, I wonder why one of the errors refers to 'a' and the other to 'b'. Also I'm not sure whether 'type/rank mismatch' is the correct diagnostic. I would rather say there is a mismatch in the procedure pointer attribute of the result (which is not checked for yet), cf. also PR 35831.
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283
--- Comment #2 from Richard Guenther 2012-08-16
15:29:24 UTC ---
Maybe related that we don't build a "host" libstdc++-v3 but only a target one:
target_modules = { module= libstdc++-v3;
bootstrap=true;
lib_path=src/.libs;
raw_cxx=true; };
and funnily we bootstrap it. We should bootstrap a host libstdc++-v3 and
build a target libstdc++-v3 (if C++ is enabled). The host libstdc++-v3
would not need libstdc++ PCHs or multilibs of course.
[Bug middle-end/54287] New: -finstrument-functions-exclude-function-list ignores class/namespace scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54287 Bug #: 54287 Summary: -finstrument-functions-exclude-function-list ignores class/namespace scope Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: mg1...@web.de In it's current implementation, the symbol matching of -finstrument-functions-exclude-function-list performs a strstr() on the function name only, ignoring the class/namespace scope. That is, with sym=func, both foo::func() and bar::func() with foo and bar being either classes or namespaces will be matched and excluded from instrumentation. To allow for a more fine-grained specification, the function name used for matching should include the class/namespace scope. This can easily be achived using the patch given below (against the 4.7.1 release). A matching based on regular expressions would be even more convenient, but the proposed change would already help a lot. diff -Nrup gcc-4.7.1.orig/gcc/gimplify.c gcc-4.7.1/gcc/gimplify.c --- gcc-4.7.1.orig/gcc/gimplify.c2012-05-10 17:00:11.0 +0200 +++ gcc-4.7.1/gcc/gimplify.c2012-08-16 18:12:45.793020996 +0200 @@ -8079,7 +8079,7 @@ flag_instrument_functions_exclude_p (tre int i; char *s; - name = lang_hooks.decl_printable_name (fndecl, 0); + name = lang_hooks.decl_printable_name (fndecl, 1); FOR_EACH_VEC_ELT (char_p, vec, i, s) if (strstr (name, s) != NULL) return true;
[Bug c/54282] GCC generates incorrect code for the PDP-11 target when -Os or -O2 is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54282 Jordi Guillaumes Pons changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jordi Guillaumes Pons 2012-08-16 16:20:46 UTC --- The problem seems to be in binutils (gas) instead of gcc. I'm opening a bug in the binutils tracker.
[Bug c++/54288] New: Wrong sign compiled at run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54288
Bug #: 54288
Summary: Wrong sign compiled at run-time
Classification: Unclassified
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l.lapoi...@srtechlabs.com
Simple code will be found below.
Optimization of the code lose the sign of a negative integer.
#include
#include
#include
#include
#include
#include
struct struct_sz
{
static const unsigned int scu_sz = 40;
};
class CQ
{
public:
void doIt();
CQ();
private:
int _i;
bool question();
};
//
const unsigned int struct_sz::scu_sz;
CQ::CQ()
{
_i = -1;
}
void CQ::doIt()
{
double dZ;
double dO = 0.0;
if (question())
{
dO = 1.0;
}
else
{
//Execution is going here
dO = 0.0;
}
dZ = 1.0/dO;
cout << dZ << endl;
}
bool CQ::question()
{
if (_i < struct_sz::scu_sz - 2)
{
return true;
}
return false;
}
int main(int argc, char* argv[])
{
CQ cq;
cq.doIt();
return 0;
}
[Bug c++/54288] Wrong sign compiled at run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54288 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab 2012-08-16 16:46:04 UTC --- The usual arithmetic conversions convert _i to unsigned int in the condition inside CQ::question.
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 Diego Novillo changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-08-16 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #7 from Diego Novillo 2012-08-16 18:03:47 UTC --- Mi fix broke Ada and in-tree cloog/isl. I will revert and fix it without the system.h modification.
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 --- Comment #8 from Diego Novillo 2012-08-16 18:24:30 UTC --- Author: dnovillo Date: Thu Aug 16 18:24:22 2012 New Revision: 190449 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190449 Log: 2012-08-16 Diego Novillo Revert PR bootstrap/54281 * double-int.h: Move including of gmp.h ... * system.h: ... here. * realmpfr.h: Do not include gmp.h. * tree-ssa-loop-niter.c: Do not include gmp.h. Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.h trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/realmpfr.h trunk/gcc/system.h trunk/gcc/tree-ssa-loop-niter.c
[Bug libstdc++/54289] New: setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 Bug #: 54289 Summary: setjmp isn't included into std namespace Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dmitriy-h...@mail.ru Hello! longjmp, jmp_buf are included into std namespace, but setjmp isn't! It is possible: #include ... std::jmp_buf ... std::longjmp() ... ... // but std::setjmp() // => error: «_setjmp» isn't an element/item of «std»
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 --- Comment #9 from Diego Novillo 2012-08-16 18:42:48 UTC --- New proposed patch. Needs testing with a 4.1 compiler. I couldn't build my own (fails to build). http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01090.html
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 --- Comment #3 from Ollie Wild 2012-08-16 18:44:01 UTC --- Author: aaw Date: Thu Aug 16 18:43:52 2012 New Revision: 190450 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190450 Log: Fix some cases where lifetimes of temporaries bound to expressions are not properly extended (Google ref b/6946758). 2012-08-16 Ollie Wild PR c++/54197 * gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees. * gcc/testsuite/g++.dg/init/lifetime3.C: New test. Added: branches/google/gcc-4_7/gcc/testsuite/g++.dg/init/lifetime3.C Modified: branches/google/gcc-4_7/gcc/cp/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/cp/call.c branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 --- Comment #4 from Ollie Wild 2012-08-16 18:46:42 UTC --- Fix submitted to the google/gcc-4_7 branch. Still waiting on maintainer approval for the trunk and gcc-4_7-branches.
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | --- Comment #3 from Dodji Seketeli 2012-08-16 19:09:39 UTC --- Sorry, I am getting to this just now.
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 --- Comment #4 from dodji at seketeli dot org 2012-08-16 19:11:01 UTC --- > I think it's valid, CC'ing Dodji for confirmation. I agree this is a bug. I am looking into it.
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Paolo Carlini 2012-08-16 19:33:11 UTC --- Open the header with your favorite editor and you will see why (spoiler: setjmp is defined as a macro in C)
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289
--- Comment #2 from Daniel Krügler
2012-08-16 19:38:16 UTC ---
The problem seems still to exist in gcc 4.8.0 20120729 (experimental).
Just to be sure that this is not due to a badly formed error description I
tested to compile the folowing code (C++03 or C++11 mode)
#include
std::jmp_buf b;
int main()
{
std::setjmp(b); // Error
}
"In function 'int main()':|
7|error: '_setjmp' is not a member of 'std'|
7|note: suggested alternative:|
c:\program files\develop\gcc\x86_64-w64-mingw32\include\setjmp.h|164|note:
'_setjmp'|"
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Daniel Krügler 2012-08-16 19:41:00 UTC --- (In reply to comment #1) > Open the header with your favorite editor and you will see why (spoiler: > setjmp > is defined as a macro in C) You are right, but I initially thought that this would be a function in C++11. But after checking, I'm satisfied, it is macro here as well.
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 --- Comment #4 from Dmitry 2012-08-16 19:43:15 UTC --- Sorry, but I think standard declares that all function should be in std.
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 --- Comment #5 from Daniel Krügler 2012-08-16 19:46:16 UTC --- (In reply to comment #4) > Sorry, but I think standard declares that all function should be in std. No. 17.6.1.2 [headers] only says so for non-macros: "In the C++ standard library, however, the declarations (except for names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace std."
[Bug target/54290] New: gcc 4.4/4.5/4.6 produces wrong code on sparc with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54290
Bug #: 54290
Summary: gcc 4.4/4.5/4.6 produces wrong code on sparc with -O2
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eriks...@gmail.com
Created attachment 28031
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28031
Output from gcc -v
Test system: SunOS 5.10 sun4u sparc SUNW,SPARC-Enterprise Solaris
GCC Config: output from gcc -v is attached for version 4.6.3
# Test case:
# cat ./testcase.c
#define CHECK 1234567890
double vd[2] = {1., 0.};
intvi[2] = {CHECK, 0};
double *pd = vd;
int*pi = vi;
void init (int *n, int *dummy) __attribute__ ((noinline));
void init (int *n, int *dummy)
{
if(0 == n) dummy[0] = 0;
}
int main ()
{
int dummy[1532];
int i = -1, n = 1, s = 0;
init (&n, dummy);
while (i < n) {
if (i == 0) {
if (pd[i] > 0) {
if (pi[i] > 0) {
s += pi[i];
#ifdef VERIFY
return (pi[i] == CHECK? 2 : 3);
#endif
}
}
pd[i] = pi[i];
}
++i;
}
return (s == CHECK? 0 : 1);
}
#
# gcc-4.6.3 -O2 ./testcase.c
# ./a.out; echo $?
1
#
O1 returns expected result (exit code 0).
Problem is reproducible with gcc/g++, 32/64bit ABI with same test case
or slight variations thereof.
Problem is not reproducible on x86_64/Linux.
# Results from other GCC versions:
GCC version 4.3.2: returns 0, ie. correct result
GCC version 4.4.3: returns 1, ie. wrong result
GCC version 4.5.2: returns 1, ie. wrong result
GCC version 4.6.1: returns 1, ie. wrong result
GCC version 4.6.3: returns 1, ie. wrong result
GCC version 4.7.1: returns 0, ie. correct result
On x86_64/Linux, all versions return 0.
# Details:
The code produced by gcc-4.6.3 misses a load (resp. contains erroneous
instructions) resulting in the use of the address of a temp in place of
the value stored at that address.
[..]
fbule,pt %fcc0, .LL10
ld [%o7], %f8 ! %f8 <- pi[i]
sethi %hi(-6144), %i5 ! compute address for temp
or %i5, 4, %i5
add %i5, %fp, %i5
st %f8, [%i5] ! copy from %f8 ...
ld [%i5], %i5 ! ... to %i5 via temp
add %g4, %i5, %o5 ! %o5 <- s+pi[i]
sethi %hi(-6144), %i5 ! recompute address of temp ...
or %i5, 4, %i5 ! ... which is unnecessary; but when doing so
add %i5, %fp, %i5 ! ... value needs to be reloaded as well:
! !
! ld [%i5], %i5 ! missing instruction
! !
cmp %i5, 0 ! supposedly (pi[i] <=> 0), except %i5 contains
! ! address of temp instead of its value
movg%icc, %o5, %g4 ! pi[i] > 0 : s <- s+pi[i]
.LL10:
fitod %f8, %f8
[..]
As an apparent pre-requisite, the offset for the temp needs to be too
large to fit into an immediate constant. Any array size greater equal to
1022(m32) resp. 1532(m64) for "dummy" in the test case seems to fit the bill.
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 --- Comment #6 from Dmitry 2012-08-16 19:49:27 UTC --- I think standard of C std libs declares setjmp as a function. So, it should be function. Some code: __BEGIN_NAMESPACE_STD typedef struct __jmp_buf_tag jmp_buf[1]; extern int setjmp (jmp_buf __env) __THROW; __END_NAMESPACE_STD #ifndef__FAVOR_BSD extern int _setjmp (struct __jmp_buf_tag __env[1]) __THROW; # define setjmp(env)_setjmp (env) #else # define setjmp(env)setjmp (env) #endif Do you see that if __FAVOR_BSD is defined then std::setjmp will work? Different behaviours aren't good.
[Bug target/54290] gcc 4.4/4.5/4.6 produces wrong code on sparc with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54290 --- Comment #1 from Erik Volk 2012-08-16 19:51:23 UTC --- Created attachment 28032 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28032 preprocessed test case
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 --- Comment #7 from Paolo Carlini 2012-08-16 19:51:54 UTC --- Nothing changes, because the C++ standard says that macros which can be implemented as functions in C must be actual macros in C++ (and setjmp is *explicitly* mentioned)
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 --- Comment #8 from Daniel Krügler 2012-08-16 19:54:10 UTC --- (In reply to comment #6) > I think standard of C std libs declares setjmp as a function. So, it should be > function. I'm not looking at any code, but C says: "The header defines the macro setjmp, [..]" And in C++ (quoting from C++11) [headers]: "Names which are defined as macros in C shall be defined as macros in the C++ standard library, even if C grants license for implementation as functions. [ Note: The names defined as macros in C include the following: assert, offsetof, setjmp, va_arg, va_end, and va_start. —end note ]" For this discussion it is completely irrelevant whether the macro expands to a function or something else.
[Bug libstdc++/54289] setjmp isn't included into std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54289 --- Comment #9 from Dmitry 2012-08-16 19:55:57 UTC --- C standard: The header defines the macro setjmp, and declares one function and one type, for bypassing the normal function call and return discipline. OK. I agree with you. But one moment. If my system is BSD I will write std::setjmp() that isn't good. May be better: __BEGIN_NAMESPACE_STD typedef struct __jmp_buf_tag jmp_buf[1]; __END_NAMESPACE_STD extern int setjmp (jmp_buf __env) __THROW; I think setjmp should be outside of std.
[Bug fortran/54285] [F03] Calling a PPC with proc-ptr result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54285
--- Comment #1 from janus at gcc dot gnu.org 2012-08-16 20:33:22 UTC ---
The following patch fixes the error message in comment 0:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(revision 190419)
+++ gcc/fortran/primary.c(working copy)
@@ -2004,8 +2004,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
primary->ts = component->ts;
- if (component->attr.proc_pointer && ppc_arg
- && !gfc_matching_procptr_assignment)
+ if (component->attr.proc_pointer && ppc_arg)
{
/* Procedure pointer component call: Look for argument list. */
m = gfc_match_actual_arglist (sub_flag,
@@ -2014,7 +2013,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
return MATCH_ERROR;
if (m == MATCH_NO && !gfc_matching_ptr_assignment
- && !matching_actual_arglist)
+ && !gfc_matching_procptr_assignment && !matching_actual_arglist)
{
gfc_error ("Procedure pointer component '%s' requires an "
"argument list at %C", component->name);
However, with this one gets:
pp => x%p()
1
Error: Interface mismatch in procedure pointer assignment at (1): 'p' has the
wrong number of arguments
... which is obviously not true. Apparently the formal args of pp are compared
to the formal args of x%p itself, and not to those of the result of x%p.
[Bug target/54272] [SH] Add support for addv / subv instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-08-16
Ever Confirmed|0 |1
--- Comment #5 from Oleg Endo 2012-08-16 20:34:53
UTC ---
Regarding saturating arithmetic, I took the function FIXED_SSADD from
libgcc/fixed-bit.c and substituted FIXED_C_TYPE with int.
int test_01 (int a, int b)
{
int c;
int x, y, z;
x = a;
y = b;
z = x + y;
if x ^ y) >> 31) & 1) == 0)
{
if (((z ^ x) >> 31) & 1)
{
z = 1;
z = z << 31;
if (x >= 0)
z--;
}
}
c = z;
return c;
}
compiled with -O2 -m4 -ml:
div0s r4,r5
mov r4,r0
bt/s.L4
add r5,r0
div0s r0,r4
bt/s.L6
cmp/pz r4
.L4:
rts
nop
.align 1
.L6:
mov.l .L7,r0
movtr1
rts
sub r1,r0
.L8:
.align 2
.L7:
.long -2147483648
In this case combine can successfully match the div0s sign comparison patterns
that I added in PR 52933. However, after matching those, it does not try to
combine the patterns any further (probably because of the conditional
branches). I guess this would be a job for an optimization at the GIMPLE level.
[Bug c++/54291] New: why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 Bug #: 54291 Summary: why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed? Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lirex.softw...@gmail.com Created attachment 28033 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28033 a c++ source file 2 SQL requests update fields of accounts table and one adds a payment into bills table. The requests are for PostgreSQL server using their native library. As I add a transaction from 1001 to 1000 for the first time all is ok, but for the second time the value of the variable(! according to the C language syntax it is a variable even if it is a CHAR characters 1 dimenisional array) SQL_from_account changes it value from 1001 to 1000(but it should not). So if I press add(caption in cyrillic, but function names, etc are in english) Why is this?
[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 --- Comment #1 from Denis Kolesnik 2012-08-16 21:04:28 UTC --- Created attachment 28034 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28034 additional files to source asked
[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 --- Comment #2 from Denis Kolesnik 2012-08-16 21:06:51 UTC --- to THE source
[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 --- Comment #3 from Denis Kolesnik 2012-08-16 21:09:24 UTC --- Created attachment 28035 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28035 object file to the source
[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 --- Comment #4 from Denis Kolesnik 2012-08-16 21:11:38 UTC --- Created attachment 28036 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28036 assembler source file
[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 Denis Kolesnik changed: What|Removed |Added Attachment #28034|0 |1 is obsolete|| --- Comment #5 from Denis Kolesnik 2012-08-16 21:15:14 UTC --- Created attachment 28037 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28037 additional files to the source asked
[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 --- Comment #6 from Denis Kolesnik 2012-08-16 21:18:32 UTC --- I know it could be because if accounts values are changed they are sorted in reverse order(last changed), but my SQL request requests in strict order and my program even not changes the value of SQL_from_account in this function int apply_button_add(etc...).
[Bug bootstrap/54292] New: Errors due to conflicting strsignal headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 Bug #: 54292 Summary: Errors due to conflicting strsignal headers Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@gcc.gnu.org Target: Darwin This resembles PR31776. My build from current HEAD fails with g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/Users/tobi/src/gcc/build/./gmp -I/Users/tobi/src/gcc/gmp -I/Users/tobi/src/gcc/build/./mpfr -I/Users/tobi/src/gcc/mpfr -I/Users/tobi/src/gcc/mpc/src -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber\ -o build/genconstants.o ../../gcc/genconstants.c In file included from /usr/include/sys/wait.h:117, from /usr/include/stdlib.h:65, from ../../gcc/system.h:228, from ../../gcc/genconstants.c:29: /usr/include/sys/resource.h:89: error: declaration does not declare anything In file included from ../../gcc/genconstants.c:29: ../../gcc/system.h:499: error: declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:144: error: previous declaration 'char* strsignal(int)' here make[3]: *** [build/genconstants.o] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 I'm using an in-tree gmp, mpfr etc setup with contrib/download_prerequisites. I mention this because in gcc/config.log (attached) I see that the strsignal configure tests apparently got confused by the location of gmp.h.
[Bug bootstrap/54292] Errors due to conflicting strsignal headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 --- Comment #1 from Tobias Schlüter 2012-08-16 21:49:53 UTC --- Created attachment 28038 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28038 configure log
[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 Andrew Pinski changed: What|Removed |Added Keywords||build Summary|Errors due to conflicting |[4.8 Regression] Errors due |strsignal headers |to conflicting strsignal ||headers --- Comment #2 from Andrew Pinski 2012-08-16 21:58:49 UTC --- This is due to including gmp.h inside system.h so the tests for those functions are failing. There is a mention of this on the list too. IIRC Diego is fixing it.
[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54261 --- Comment #2 from Hans-Peter Nilsson 2012-08-16 22:03:39 UTC --- Author: hp Date: Thu Aug 16 22:03:33 2012 New Revision: 190454 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190454 Log: PR middle-end/54261 * optabs.c (expand_atomic_fetch_op): Save and restore code when retrying after failed attempt. Modified: trunk/gcc/ChangeLog
[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54261 --- Comment #3 from Hans-Peter Nilsson 2012-08-16 22:05:37 UTC --- Author: hp Date: Thu Aug 16 22:05:32 2012 New Revision: 190455 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190455 Log: PR middle-end/54261 * gcc.dg/torture/pr54261-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr54261-1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 --- Comment #5 from dodji at seketeli dot org 2012-08-16 22:18:36 UTC --- A candidate patch was sent to http://gcc.gnu.org/ml/gcc-patches/2012-08/msg0.html.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 --- Comment #10 from Hans-Peter Nilsson 2012-08-16 22:23:32 UTC --- (In reply to comment #9) > Actually, that's the way __atomic_is_lock_free() has always been implemented > (even in 4.7). There's miscommunication here. The point of this PR is, the code for is_lock_free must be per-type, agreed? It used __atomic_is_lock_free() with a non-null pointer, hence it was per-object, a bug, agreed? (Mr. Crowl asserts on IRC what can be understood from the referenced URL; that the function started as per-object but semantics later changed to be per-type.) The committed changes were to make it use __atomic_always_lock_free() so per-type. IIUC you mean it should instead use __atomic_is_lock_free() with the object pointer changed to NULL. That might be: whether that is preferred to r190216 I can't say, in particular with a pending rewrite.
[Bug c++/54291] why the value of the variable CHAR SQL_from_account[3] of is changed if it should not be changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54291 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #7 from Andreas Schwab 2012-08-16 22:26:11 UTC --- If you want to learn C this is not the right place. *** This bug has been marked as a duplicate of bug 54180 ***
[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180 --- Comment #12 from Andreas Schwab 2012-08-16 22:26:11 UTC --- *** Bug 54291 has been marked as a duplicate of this bug. ***
[Bug c++/54293] New: When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293
Bug #: 54293
Summary: When a reference is bound to subobject of a temporary,
lifetime of the temporary is not extended
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google reference: b/6996555
"ISO/IEC 14882:2011(E) 12.2.5 [class.temporary]
The temporary to which the reference is bound or the temporary that is the
complete object of a subobject to which the reference is bound persists for the
lifetime of the reference except: [etc]"
With gcc-4.6, the lifetime extension is not happening at all:
FAIL int
FAIL Obj
With gcc-4.7 and 4.8 (rev 190453), lifetime is extended for Obj subobject, but
not for 'int' (or 'char', or other primitive types):
FAIL int
The test:
#include
#include
std::set subobjs;
template
struct ValueHolder {
explicit ValueHolder() {
subobjs.insert(&v);
}
~ValueHolder() {
subobjs.erase(&v);
}
T v;
};
struct Obj { };
bool IsValid(const void* p) {
return subobjs.find(p) != subobjs.end();
}
int main() {
const int& ref_int = ValueHolder().v;
if (!IsValid(&ref_int)) {
std::cout << "FAIL int" << std::endl;
}
const Obj& ref_obj = ValueHolder().v;
if (!IsValid(&ref_obj)) {
std::cout << "FAIL Obj" << std::endl;
}
}
[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180 Denis Kolesnik changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #13 from Denis Kolesnik 2012-08-16 22:35:01 UTC --- I disagree: I know enough to use strcat and strcpy. 1: Why those functions work false and are dependent on variables(! I name it correct even if it is one dimenision array of chararters) declare order I don't know. 2: on this site there are enough people with very vary C and C++ language skills, so this sites helps on learning also. I know too much people who learner more from wrong experiences rather than from clear imagination.
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 Denis Kolesnik changed: What|Removed |Added Resolution|WORKSFORME |DUPLICATE --- Comment #6 from Denis Kolesnik 2012-08-16 22:38:19 UTC --- *** This bug has been marked as a duplicate of bug 54214 ***
