[Bug bootstrap/48327] New: [4.7 Regression] Bootstrap comparison failure with ada since r171622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48327 Summary: [4.7 Regression] Bootstrap comparison failure with ada since r171622 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: l...@gcc.gnu.org Target: x86_64-linux ../configure --enable-languages=all,obj-c++,ada,lto,go --enable-checking=yes,rtl configured gcc results in .bad_compare: gcc/ada/exp_dist.o differs r171621 works, r171622 fails. Most likely stage2 tree-ssa-forwprop.o is miscompiled, doesn't seem to be VTA related, as even when I compile exp_dist.adb with -g0 by both stage1-gcc/gnat1 and prev-gcc/gnat1, it differs. r171621 compiled exp_dist.s is identical to what stage1-gcc/gnat1 in r171622 produces, differences start in forwprop1 pass.
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 --- Comment #8 from Tobias Burnus 2011-03-29 06:26:50 UTC --- (In reply to comment #7) > call set1 (get (h)) > subroutine set1 (a) > integer, intent(inout) :: a If one changes the (invalid) INOUT to IN, it compiles. * * * Additionally, for the modified program, I think NAG is correct with the following error - gfortran just compiles it: Error: GET1 in generic GET is an internal procedure >From F2008, "12.4.3.4.1 Generic identifiers": "The PROCEDURE statement lists procedure pointers, external procedures, dummy procedures, or module procedures that have this generic interface." (However, g95, pgf95 and crayftn also compile it, thus, I might misread F2008.)
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 Andrew Pinski changed: What|Removed |Added Component|c |target Severity|major |normal
[Bug c/48326] New: Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 Summary: Target attribute leaks from function pointers Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mich...@talamasca.ocis.net Created attachment 23795 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23795 Raw preprocessed code demonstrating the bug. In at least one case, a function -not- bearing a target attribute may be compiled with illegal instructions for the current -m option, when it handles pointers to functions that do have a permissive target attribute. Attached is a demonstration case. When compiled on i386 with "-O1 -march=i386", a "cmovne" instruction is emitted. One thing that makes this bug especially serious, is that my testcase is distilled down from the function init_vectorized_lexer of "libcpp/lex.c" in GCC itself. As a result, GCC 4.6.0 will fail to bootstrap on any processor that does not support cmov-family instructions.
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
--- Comment #7 from H.J. Lu 2011-03-29 04:06:02
UTC ---
Another testcase:
[hjl@gnu-6 gcc]$ ./xgcc -B./
/export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/eoshift_large_1.f90
-Os -pedantic-errors -S -mx32
/export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/eoshift_large_1.f90:
In function \u2018intrinsic_eoshift\u2019:
/export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/eoshift_large_1.f90:106:0:
error: insn does not satisfy its constraints:
(insn 3117 2287 2288 208 (set (reg:TI 41 r12)
(mem/u/c:TI (zero_extend:DI (plus:SI (plus:SI (reg:SI 1 dx [orig:963
ivtmp.408 ] [963])
(reg:SI 0 ax [orig:1214 ivtmp.417 ] [1214]))
(symbol_ref:SI ("A.190.2202") [flags 0x2] ))) [6 MEM[symbol: A.190, base: ivtmp.417_1486, index:
ivtmp.408_1391, offset: 0B]+0 S16 A128]))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/eoshift_large_1.f90:97
60 {*movti_internal_rex64}
(nil))
/export/gnu/import/git/gcc-x32/gcc/testsuite/gfortran.dg/eoshift_large_1.f90:106:0:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[hjl@gnu-6 gcc]$
[Bug target/48301] Xcode 4.0's llvm-gcc can't bootstrap gcc 4.6.0 or trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48301 --- Comment #5 from Jack Howarth 2011-03-29 03:15:32 UTC --- FYI, this problem also exists under linux so it isn't darwin specific. Opened... http://llvm.org/bugs/show_bug.cgi?id=9571
[Bug c/48325] New: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396 with neon optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48325
Summary: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396 with
neon optimized code
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nereu...@gmail.com
Created attachment 23794
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23794
preprocessed file
I have following error while building neon optimized code.
$ cat insn-unsat-constr.c
#include
void test(signed int *output)
{
int16_t * out = (int16_t *) output;
{
int16x4_t a = {0, };
int16x4_t b = {1, };
int16x4x4_t z;
z.val[0] = vadd_s16(a, b);
z.val[1] = vadd_s16(a, b);
z.val[2] = vsub_s16(a, b);
z.val[3] = vadd_s16(a, b);
vst4_lane_s16(&out[0]+0*4, z, 0);
vst4_lane_s16(&out[8]+0*4, z, 1);
}
}
$ arm-none-linux-gnueabi-gcc -mfloat-abi=softfp -mfpu=neon -O1 -o
insn-unsat-constr.o -c insn-unsat-constr.c
insn-unsat-constr.c: In function 'test':
insn-unsat-constr.c:19:1: error: insn does not satisfy its constraints:
(insn 40 38 26 2
/scratchbox/compilers/arm-linux-gnueabi-gcc4.5.1-2010.09-50/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.1/include/arm_neon.h:10277
(set (reg:OI 95 d16 [orig:152 __b ] [152])
(mem/s/c:OI (pre_dec:SI (reg/f:SI 3 r3 [151])) [0 __b+0 S32 A64])) 740
{*neon_movoi} (expr_list:REG_INC (reg/f:SI 3 r3 [151])
(nil)))
insn-unsat-constr.c:19:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
$ arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/scratchbox/compilers/arm-linux-gnueabi-gcc4.5.1-2010.09-50/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/scratchbox/compilers/arm-linux-gnueabi-gcc4.5.1-2010.09-50/bin/../libexec/gcc/arm-none-linux-gnueabi/4.5.1/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with: /scratch/nathan/arm-lite/src/gcc-4.5-2010.09/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2010 -D__CS_SOURCERYGXX_MIN__=9
-D__CS_SOURCERYGXX_REV__=50 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery G++ Lite 2010.09-50'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/nathan/arm-lite/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/nathan/arm-lite/obj/host-libs-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/nathan/arm-lite/obj/host-libs-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-mpc=/scratch/nathan/arm-lite/obj/host-libs-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-ppl=/scratch/nathan/arm-lite/obj/host-libs-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/nathan/arm-lite/obj/host-libs-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-libelf=/scratch/nathan/arm-lite/obj/host-libs-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/nathan/arm-lite/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/nathan/arm-lite/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
[Bug c++/48313] [C++0x] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 --- Comment #7 from Jason Merrill 2011-03-29 00:04:57 UTC --- Author: jason Date: Tue Mar 29 00:04:54 2011 New Revision: 171643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171643 Log: PR c++/48313 * pt.c (maybe_adjust_types_for_deduction): Handle T&& deduction from overloaded function. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-deduce2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48324] New: [C++0x] constexpr evaluation should respect lifetime rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48324
Summary: [C++0x] constexpr evaluation should respect lifetime
rules
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
// { dg-options -std=c++0x }
struct S {
const int val;
constexpr S(int i) : val(i) { }
};
constexpr const int& to_ref(int i) {
return S(i).val;
}
constexpr int ary[to_ref(98)] = { }; // { dg-error "use of dead temporary" }
int main() { }
[Bug debug/48253] [4.6/4.7 Regression] Further .debug_aranges issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48253
--- Comment #3 from Jakub Jelinek 2011-03-28
23:55:49 UTC ---
Author: jakub
Date: Mon Mar 28 23:55:47 2011
New Revision: 171642
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171642
Log:
PR debug/48253
* dwarf2out.c (struct dw_fde_struct): Remove dw_fde_hot_section_label,
dw_fde_hot_section_end_label, dw_fde_unlikely_section_label,
dw_fde_unlikely_section_end_label, cold_in_std_section,
dw_fde_switched_sections and dw_fde_switched_cold_to_hot fields.
Add dw_fde_second_begin, dw_fde_second_end and second_in_std_section
fields.
(output_fde): Use dw_fde_second_{begin,end} if second is
true, otherwise dw_fde_{begin,end}.
(output_call_frame_info): Test dw_fde_second_begin != NULL
instead of dw_fde_switched_sections.
(dwarf2out_begin_prologue): Stop initializing removed dw_fde_struct
fields, initialize new fields. Initialize in_std_section
unconditionally from the first partition.
(dwarf2out_end_epilogue): Don't override dw_fde_end when
dw_fde_second_begin is non-NULL.
(dwarf2out_switch_text_section): Stop initializing removed
dw_fde_struct fields, initialize new fields, initialize
also dw_fde_end here. Set dw_fde_switch_cfi even when
dwarf2out_do_cfi_asm (). Call var_location_switch_text_section.
(struct var_loc_list_def): Add last_before_switch field.
(arange_table, arange_table_allocated, arange_table_in_use,
ARANGE_TABLE_INCREMENT, add_arange): Removed.
(size_of_aranges): Count !in_std_section and !second_in_std_section
hunks in fdes, instead of looking at arange_table_in_use.
(output_aranges): Add aranges_length argument, don't call
size_of_aranges here. Instead of using aranges_table*
emit ranges for fdes when !in_std_section resp.
!second_in_std_section.
(dw_loc_list): Break ranges crossing section switch.
(convert_cfa_to_fb_loc_list): Likewise. If switched sections,
use dw_fde_second_end instead of dw_fde_end as end of last
range.
(gen_subprogram_die): Don't call add_arange. Use
dw_fde_{begin,end} for first partition and if switched
section dw_fde_second_{begin,end} for the second.
(var_location_switch_text_section_1,
var_location_switch_text_section): New functions.
(dwarf2out_begin_function): Initialize cold_text_section even
when function_section () isn't text_section.
(prune_unused_types): Don't walk arange_table.
(dwarf2out_finish): Don't needlessly test
flag_reorder_blocks_and_partition when testing cold_text_section_used.
If info_section_emitted, call size_of_aranges and if it indicates
non-empty .debug_aranges, call output_aranges with the computed
size. Stop using removed dw_fde_struct fields, use
dw_fde_{begin,end} for first partition and dw_fde_second_{begin,end}
for second.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
[Bug debug/48203] ICE in dwarf2out.c while building eglibc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203 --- Comment #13 from Jakub Jelinek 2011-03-28 23:53:49 UTC --- Author: jakub Date: Mon Mar 28 23:53:46 2011 New Revision: 171640 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171640 Log: PR debug/48203 * cfgexpand.c (expand_debug_expr) : Only create ENTRY_VALUE if incoming or address of incoming's MEM is a hard REG. * dwarf2out.c (mem_loc_descriptor): Don't emit DW_OP_GNU_entry_value of DW_OP_fbreg. * var-tracking.c (vt_add_function_parameter): Ensure cselib_lookup on ENTRY_VALUE is able to find the canonical parameter VALUE. * cselib.c (rtx_equal_for_cselib_1) : Use rtx_equal_p instead of rtx_equal_for_cselib_1 to compare ENTRY_VALUE_EXPs. (cselib_hash_rtx) : If ENTRY_VALUE_EXP is a REG_P or MEM_P with REG_P address, compute hash directly instead of calling cselib_hash_rtx on ENTRY_VALUE_EXP. (preserve_only_constants): Don't clear VALUES forwaring ENTRY_VALUE to some other VALUE. * gcc.dg/pr48203.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48203.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/cselib.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug c++/48296] [C++0x] constexpr member function cannot use the class type it belongs as parameter type or return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48296 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.28 23:51:40 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/46170] [4.4/4.5 Regression] g++ wrongly rejects pointer-to-member in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46170 --- Comment #27 from David Fang 2011-03-28 23:42:54 UTC --- Friendly ping for backport?
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #5 from Mikael Pettersson 2011-03-28 22:57:21 UTC --- Created attachment 23793 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23793 reduced^2 test case
[Bug middle-end/48323] [4.5/4.6/4.7 Regression] Lifetime of local variables: global versus member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48323 --- Comment #5 from Andrew Pinski 2011-03-28 22:25:00 UTC --- (In reply to comment #4) > (In reply to comment #3) > Sorry for being pedantic, but would you care to explain how your observation > renders this report invalid? I am afraid I do not understand this resolution. > > Do you assert that the two cases (static local in global vs. class scope > function) are deliberately treated differently? If so, is this an > implementation choice, or is it based on a document that I should have read > (which one)? Yes they are different because C::class_scope_f is a vague linkage while global_f is global linkage. So the i in each one is of different linkage. If you want C type to be local to the shared, then you need to use either the hidden attribute on it or use -fvisibility=hidden.
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Mikael Pettersson changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #4 from Mikael Pettersson 2011-03-28 22:24:05 UTC --- It's triggered by r163998: Author: matz Date: Wed Sep 8 12:34:52 2010 New Revision: 163998 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163998 Log: PR tree-optimization/33244 * tree-ssa-sink.c (statement_sink_location): Don't sink into empty loop latches.
[Bug middle-end/48323] [4.5/4.6/4.7 Regression] Lifetime of local variables: global versus member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48323 --- Comment #4 from Jan van Dijk 2011-03-28 22:17:15 UTC --- (In reply to comment #3) Sorry for being pedantic, but would you care to explain how your observation renders this report invalid? I am afraid I do not understand this resolution. Do you assert that the two cases (static local in global vs. class scope function) are deliberately treated differently? If so, is this an implementation choice, or is it based on a document that I should have read (which one)? If this isn't changed back, shouldn't this change at least be documented? It may break more user code, not just mine... Thanks again for your time.
[Bug driver/48306] presence of gcc subdir with . in PATH causes breakdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48306 --- Comment #2 from karl at freefriends dot org 2011-03-28 21:51:03 UTC --- For both gcc 4.5.2 and 4.6.0, I configured it from the original source on ftp.gnu.org, using --prefix=/usr/local/gnu --enable-languages=c,c++, no other arguments. "make install" to install. Here is the gcc -v output. I note that cpp is not even being executed. $ gcc -v hello.c Using built-in specs. COLLECT_GCC=gcc Target: i686-pc-linux-gnu Configured with: ../gcc-4.6.0/configure --prefix=/usr/local/gnu --enable-langua\ ges=c,c++ Thread model: posix gcc version 4.6.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro' cc1 -quiet -v -iprefix /tmp/../lib/gcc/i686-pc-linux-gnu/4.6.0/ hello.c -quiet\ -dumpbase hello.c -mtune=generic -march=pentiumpro -auxbase hello -version -o \ /dev/shm/cc34H39x.s gcc: error trying to exec 'cc1': execvp: No such file or directory The /tmp/../lib seems like a clear indication it is finding the empty /tmp/gcc directory. I thought it might be something in my environment causing the failure, but even running with env -i, I get the same error. It is puzzling that you do not see it. I can't think of what else would be specific to my installation. $ mkdir /tmp/gcc $ env -i PATH=/tmp:/usr/local/gnu/bin gcc hello.c gcc: error trying to exec 'cc1': execvp: No such file or directory (the gcc -v output from this env -i run is the same as above.) Thanks, karl
[Bug middle-end/48323] [4.5/4.6/4.7 Regression] Lifetime of local variables: global versus member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48323 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Jakub Jelinek 2011-03-28 20:55:38 UTC --- It has nothing to do with __cxa_atexit. The dynamic linker sets if (map->l_type == lt_loaded) /* Make sure we don't unload this object by setting the appropriate flag. */ map->l_flags_1 |= DF_1_NODELETE; whenever doing successful symbol lookup of a STB_GNU_UNIQUE symbol, so that that symbol will always be found at that point afterwards.
[Bug fortran/48095] [OOP] Invalid assignment to procedure pointer component not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48095 --- Comment #3 from janus at gcc dot gnu.org 2011-03-28 20:55:13 UTC --- Also the following variant is not rejected (seems to be a module problem): module m implicit none type :: rectangle real :: width, height procedure(get_area), pointer, pass(this) :: get_special_area end type rectangle abstract interface real function get_area( this ) import :: rectangle class(rectangle), intent(in) :: this end function get_area end interface type(rectangle) :: rect contains real function get_my_area( this ) type(rectangle), intent(in) :: this write(*,*) 'This: ', this%width, this%height get_my_area = 3.0 * this%width * this%height end function get_my_area end module use m rect%get_special_area => get_my_area end
[Bug middle-end/48323] [4.5/4.6/4.7 Regression] Lifetime of local variables: global versus member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48323 Andrew Pinski changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Andrew Pinski 2011-03-28 20:41:55 UTC --- http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01240.html was the patch which changed to use @gnu_unique_object . Jason can you explain why this is causing an issue where the function passed to __cxa_atexit being called?
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 --- Comment #7 from janus at gcc dot gnu.org 2011-03-28 20:39:53 UTC --- Reduced/modified test case: interface get procedure get1 end interface integer :: h call set1 (get (h)) contains subroutine set1 (a) integer, intent(inout) :: a end subroutine integer function get1 (s) integer :: s end function end
[Bug middle-end/48323] [4.5/4.6/4.7 Regression] Lifetime of local variables: global versus member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48323 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.5.3
[Bug middle-end/48323] [4.5/4.6/4.7 Regression] Lifetime of local variables: global versus member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48323 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2011.03.28 20:31:38 Component|c++ |middle-end Ever Confirmed|0 |1 Summary|Lifetime of local |[4.5/4.6/4.7 Regression] |variables: global versus|Lifetime of local |member function |variables: global versus ||member function --- Comment #1 from Andrew Pinski 2011-03-28 20:31:38 UTC --- +.type_ZZN1C13class_scope_fEvE1i, @gnu_unique_object -.type_ZZN1C13class_scope_fEvE1i, @object - works but + does not. 4.4 produces object while 4.5 and above produce @gnu_unique_object.
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Severity|blocker |normal
[Bug c++/48313] [C++0x] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2011-03-28 12:17:25 |2011.03.28 20:10:59 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #6 from Jason Merrill 2011-03-28 20:10:59 UTC --- Yes, that's a bug.
[Bug c++/48323] New: Lifetime of local variables: global versus member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48323
Summary: Lifetime of local variables: global versus member
function
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j.v.d...@tue.nl
[First presented on gcc-help. Submitted as per the suggestion of Ian Lance
Taylor, see http://gcc.gnu.org/ml/gcc-help/2011-03/msg00340.html ]
Consider the following shared object:
// g++ -o libtest.so -shared -fPIC dltestlib.cpp
#include
int global_f() { static int i=0; return i; }
struct C
{
int class_scope_f() { static int i=0; return i; }
C()
{
global_f();
// class_scope_f(); // CULPRIT
}
~C() { std::cout << "Destructor called" << std::endl; }
};
static C c;
Also consider the following test program, which merely loads and unloads this
library using dlopen/dlclose.
// g++ dltest2.cpp -ldl
#include
#include
int main(int argc, const char* argv[])
{
if (argc!=2) return -1;
const char* fname = argv[1];
std::cout << "Opening: " << fname << std::endl;
void* handle = dlopen( fname, RTLD_NOW | RTLD_LOCAL);
std::cout << "Handle after dlopen: " << handle << std::endl;
if(!handle)
{
std::cout << dlerror() << std::endl;
}
dlclose(handle);
// do not load. Only check if the file is resident.
handle = dlopen( fname, RTLD_NOW | RTLD_NOLOAD);
std::cout << "Handle after dlclose: " << handle << std::endl;
std::cout << "Exiting..." << std::endl;
}
Providing the abovementioned library as argument, I get the expected result:
./a.out /home/jan/src/gum-cvs/ideas/jan/libtest.so
Opening: /home/jan/src/gum-cvs/ideas/jan/libtest.so
Handle after dlopen: 0x602050
Destructor called
Handle after dlclose: 0
Exiting...
In particular, the library *is* unloaded by dlclose (so the global destructor
of object c in the library is called before the program is exiting.)
And now for the problem...
If I comment in line 11 of the library module (marked CULPRIT), thus calling
class_scope_f(), and try again, the result is:
Opening: /home/jan/src/gum-cvs/ideas/jan/libtest.so
Handle after dlopen: 0x602050
Handle after dlclose: 0x602050
Exiting...
Destructor called
Now the library unloading fails (the handle is still !=0, and indeed the
destructor of c is not called before the program terminates).
I assume this is because there is a difference in lifetime between local
static variables in functions in global scope vs. those of member functions.
Is this the intended behaviour? (I say 'intended', not 'mandated', because I
know so's are beyond the scope of ISO-C++.) If not, should I file a report?
I am on OpenSuSE 11.4; that is: glibc 2.11.3, gcc 4.5.1, binutils 2.21.
[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #8 from Rainer Orth 2011-03-28 19:48:07 UTC --- Support for --with-threads=solaris has been removed for GCC 4.7.0. It isn't resonably supported in the target libraries and untested, so no point in spending time on this issue.
[Bug debug/47471] [4.6/4.7 Regression] stdarg functions extraneous too-early prologue end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.28 19:46:26 CC|dodji at gcc dot gnu.org| AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug boehm-gc/11412] boehm-gc testing problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11412 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Rainer Orth 2011-03-28 19:43:39 UTC --- Fixed for 4.7.0.
[Bug c++/48322] New: [C++0x] Plural parameter packs are not expanded well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48322
Summary: [C++0x] Plural parameter packs are not expanded well
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
Source Code (bug.cc):
#include
#include
#include
#include
template
void print_typename()
{
int status = 0;
char* const name = abi::__cxa_demangle( typeid(T).name(), 0, 0, &status );
std::cout << name << std::endl;
std::free( name );
}
#include
#include
#include
template
struct X
{
template< class... Us,
class Tuple = std::tuple<
std::pair...
>
>
static void test( Us... ) {
print_typename();
}
};
int main()
{
// expected
X<>::test(); // std::tuple<>
X::test(1); // std::tuple>
X::test(1.0); // std::tuple>
X<>::test(1); // no matching function
X::test();// no matching function
}
Output:
std::tuple<>
std::tuple >
std::tuple >
std::tuple >
std::tuple<>
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #5 from Jakub Jelinek 2011-03-28 18:49:06 UTC --- Created attachment 23792 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23792 gcc46-pr48248.patch Untested fix (the second alternative).
[Bug tree-optimization/48321] New: gcc.dg/graphite/id-pr46845.c FAILs on IRIX 6.5: ICE in commit_one_edge_insertion, at cfgrtl.c:1566
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48321 Summary: gcc.dg/graphite/id-pr46845.c FAILs on IRIX 6.5: ICE in commit_one_edge_insertion, at cfgrtl.c:1566 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: s...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 The new gcc.dg/graphite/id-pr46845.c causes an ICE on IRIX 6.5: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/graphite/id-pr46845.c: In funct ion 'foo': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/graphite/id-pr46845.c:17:1: int ernal compiler error: in commit_one_edge_insertion, at cfgrtl.c:1566
[Bug c++/48319] [4.6/4.7 Regression] [C++0x] Segmentation fault in instantiation of std::is_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48319
--- Comment #2 from Jonathan Wakely 2011-03-28
18:38:37 UTC ---
reduced
template Tp declval() noexcept;
template
class __is_constructible_helper
{
typedef char __one;
typedef struct { char __arr[2]; } __two;
template
static decltype(_Tp1(declval<_Args1>()...), __one()) __test(int);
template
static __two __test(...);
public:
static const bool __value = sizeof(__test<_Tp>(0)) == 1;
};
int main() {
return __is_constructible_helper::__value;
}
[Bug go/48312] [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48312 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Ian Lance Taylor 2011-03-28 18:36:37 UTC --- Fixed.
[Bug go/48312] [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48312 --- Comment #2 from ian at gcc dot gnu.org 2011-03-28 18:35:56 UTC --- Author: ian Date: Mon Mar 28 18:35:53 2011 New Revision: 171623 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171623 Log: PR go/48312 Fix fd_select.go for changes in FD handling. We have to wake up the goroutine waiting in select each time we change the set of descriptors we are waiting for, unlike epoll. Modified: trunk/libgo/go/net/fd.go trunk/libgo/go/net/fd_linux.go trunk/libgo/go/net/fd_select.go trunk/libgo/go/net/newpollserver.go trunk/libgo/go/net/newpollserver_rtems.go
[Bug regression/48320] New: [C++0x] cannot expand template parameter pack in Default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48320
Summary: [C++0x] cannot expand template parameter pack in
Default template arguments
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
Source File (bug.cc):
#include
#include
#include
template< std::size_t... Indices >
struct indices {};
template< class Tuple, std::size_t... Indices,
class Result = std::tuple<
typename std::tuple_element<
Indices, typename std::decay::type
>::type...
>
>
Result f( Tuple && t, indices )
{
return Result(
std::forward::type>(
std::get(t)
)...
);
}
#include
int main()
{
auto t = f( std::make_tuple( 1, 2, 3 ), indices<2, 1, 0>() );
assert( std::get<0>(t) == 3 );
assert( std::get<1>(t) == 2 );
assert( std::get<2>(t) == 1 );
}
Message:
compiling and running file 'bug.cc'...
bug.cc: In function ‘int main()’:
bug.cc:28:62: error: no matching function for call to ‘f(std::tuple, indices<2u, 1u, 0u>)’
bug.cc:28:62: note: candidate is:
bug.cc:15:43: note: template Result f(Tuple&&, indices)
bug.cc:28:62: error: unable to deduce ‘auto’ from ‘’
Note:
#include
#include
#include
template< std::size_t... Indices >
struct indices {};
template< class Tuple, std::size_t... Indices >
std::tuple<
typename std::tuple_element<
Indices, typename std::decay::type
>::type...
>
f( Tuple && t, indices )
{
typedef std::tuple<
typename std::tuple_element<
Indices, typename std::decay::type
>::type...
> Result;
return Result(
std::forward::type>(
std::get(t)
)...
);
}
#include
int main()
{
auto t = f( std::make_tuple( 1, 2, 3 ), indices<2, 1, 0>() );
assert( std::get<0>(t) == 3 );
assert( std::get<1>(t) == 2 );
assert( std::get<2>(t) == 1 );
}
is OK.
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290 --- Comment #5 from Dominique d'Humieres 2011-03-28 18:26:52 UTC --- The patch in comment #3 fixes the ICE, but the test still fails: FAIL: gcc.dg/vect/pr38529.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1 Compiling with -Ofast -ftree-vectorizer-verbose=2 I get /opt/gcc/_clean/gcc/testsuite/gcc.dg/vect/pr38529.c:11: note: not vectorized: unsupported data-type /opt/gcc/_clean/gcc/testsuite/gcc.dg/vect/pr38529.c:6: note: vectorized 0 loops in function. With revision 171398 I get /opt/gcc/_clean/gcc/testsuite/gcc.dg/vect/pr38529.c:10: note: LOOP VECTORIZED. /opt/gcc/_clean/gcc/testsuite/gcc.dg/vect/pr38529.c:10: note: OUTER LOOP VECTORIZED. /opt/gcc/_clean/gcc/testsuite/gcc.dg/vect/pr38529.c:6: note: vectorized 1 loops in function. No other test fails in gcc/testsuite/*/vect/* (full test for tonight).
[Bug c++/48319] [4.6/4.7 Regression] [C++0x] Segmentation fault in instantiation of std::is_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48319 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|Segmentation fault in |[4.6/4.7 Regression] |instantiation of|[C++0x] Segmentation fault |std::is_constructible |in instantiation of ||std::is_constructible --- Comment #1 from Paolo Carlini 2011-03-28 17:58:08 UTC --- Looks like a regression. Note, in any case std::is_constructible itself didn't change lately.
[Bug target/48288] [4.7 Regression] ld: Unsatisfied symbol "__iordi3" in file /test/gnu/gcc/objdir/./gcc/libgcc_eh.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48288 John David Anglin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from John David Anglin 2011-03-28 17:45:39 UTC --- Fixed on trunk.
[Bug c++/48319] New: Segmentation fault in instantiation of std::is_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48319
Summary: Segmentation fault in instantiation of
std::is_constructible
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com
Source file (bug.cc):
#include
int main() {
static_assert( std::is_constructible::value, "" );
}
Message:
In file included from bug.cc:1:0:
/usr/local/gcc-4.6.0/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:
In instantiation of ‘const bool
std::__is_constructible_helper::__value’:
/usr/local/gcc-4.6.0/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:683:12:
instantiated from ‘std::is_constructible’
bug.cc:7:42: instantiated from here
/usr/local/gcc-4.6.0/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:661:71:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug target/48301] Xcode 4.0's llvm-gcc can't bootstrap gcc 4.6.0 or trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48301 --- Comment #4 from Mike Stump 2011-03-28 17:41:36 UTC --- If there is an easy work around in gcc to avoid the problem, we could entertain that, but, generally, I'd be more interested in clang failures going forward. llvm-gcc is old and getting older every day. The dragon egg bits are newer and more compelling.
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 --- Comment #3 from Steven Bosscher 2011-03-28 17:18:25 UTC --- Jakub, please do not forget about this one for stage1 GCC 4.7.
[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48135 --- Comment #25 from Rainer Orth 2011-03-28 17:09:34 UTC --- Author: ro Date: Mon Mar 28 17:09:27 2011 New Revision: 171617 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171617 Log: libgfortran: backport from mainline: 2011-03-21 Rainer Orth PR bootstrap/48135 * configure.ac (gfortran_use_symver): Handle --disable-symvers. * configure: Regenerate. libgomp: backport from mainline: 2011-03-21 Rainer Orth PR bootstrap/48135 * acinclude.m4 (enable_symvers): Handle --disable-symvers. * configure: Regenerate. libjava: backport from mainline: 2011-03-21 Rainer Orth PR bootstrap/48135 * configure.ac (libjava_cv_anon_version_script): Handle --disable-symvers. * configure: Regenerate. libquadmath: backport from mainline: 2011-03-21 Rainer Orth PR bootstrap/48135 * configure.ac (quadmath_use_symver): Handle --disable-symvers. * configure: Regenerate. libssp: backport from mainline: 2011-03-21 Rainer Orth PR bootstrap/48135 * configure.ac (ssp_use_symver): Handle --disable-symvers. * configure: Regenerate. Modified: branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/configure branches/gcc-4_6-branch/libgfortran/configure.ac branches/gcc-4_6-branch/libgomp/ChangeLog branches/gcc-4_6-branch/libgomp/acinclude.m4 branches/gcc-4_6-branch/libgomp/configure branches/gcc-4_6-branch/libjava/ChangeLog branches/gcc-4_6-branch/libjava/configure branches/gcc-4_6-branch/libjava/configure.ac branches/gcc-4_6-branch/libquadmath/ChangeLog branches/gcc-4_6-branch/libquadmath/configure branches/gcc-4_6-branch/libquadmath/configure.ac branches/gcc-4_6-branch/libssp/ChangeLog branches/gcc-4_6-branch/libssp/configure branches/gcc-4_6-branch/libssp/configure.ac
[Bug lto/47891] GCC 4.6/4.7 LTO not worked reliable on Windows target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 Andrew Pinski changed: What|Removed |Added CC||gordon.magnusson at gmail ||dot com --- Comment #8 from Andrew Pinski 2011-03-28 17:03:25 UTC --- *** Bug 48309 has been marked as a duplicate of this bug. ***
[Bug lto/48309] gcc -flto -fuse-linker-plugin generates crashing executables on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48309 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #4 from Andrew Pinski 2011-03-28 17:03:25 UTC --- *** This bug has been marked as a duplicate of bug 47891 ***
[Bug c++/48313] [C++0] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
CC||jason at gcc dot gnu.org
Component|libstdc++ |c++
Summary|std::bind with template |[C++0] std::bind with
|function|template function
Ever Confirmed|1 |0
--- Comment #5 from Jonathan Wakely 2011-03-28
17:02:14 UTC ---
Actually no, that paragraph doesn't apply because P is a reference type not
function type.
Jason should the call to f(h) be accepted here?
template
void f(F&&) { }
void g() { }
template void h() { }
int main()
{
f( g ); // OK
void (&p)() = h;
f( p ); // OK
f( h ); // ???
}
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 --- Comment #3 from Rainer Orth 2011-03-28 16:46:33 UTC --- Author: ro Date: Mon Mar 28 16:46:27 2011 New Revision: 171616 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171616 Log: Backport from mainline: 2011-03-23 Rainer Orth PR testsuite/48251 * g++.dg/guality/guality.exp: Disable on alpha*-dec-osf*. Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/guality/guality.exp
[Bug testsuite/48238] FAIL: gcc.dg/debug/dwarf2/pr47939-0.c scan-assembler on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48238 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-03/msg01918 Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #9 from Rainer Orth 2011-03-28 16:42:51 UTC --- Applied the patch after testing. Thanks. Rainer
[Bug testsuite/48238] FAIL: gcc.dg/debug/dwarf2/pr47939-0.c scan-assembler on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48238 --- Comment #8 from Rainer Orth 2011-03-28 16:39:44 UTC --- Author: ro Date: Mon Mar 28 16:39:35 2011 New Revision: 171615 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171615 Log: 2011-03-26 Dominique d'Humieres PR testsuite/48238 * gcc.dg/debug/dwarf2/pr47939-1.c: Generalize scan-assembler regex. * gcc.dg/debug/dwarf2/pr47939-2.c: Likewise. * gcc.dg/debug/dwarf2/pr47939-3.c: Likewise. * gcc.dg/debug/dwarf2/pr47939-4.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr47939-4.c
[Bug c++/48292] [C++0x] "sorry, unimplemented: use of 'type_pack_expansion' in template"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48292 --- Comment #3 from Paolo Carlini 2011-03-28 16:27:43 UTC --- CC-ing Jason about this one too. By the way, isn't the first time this sorry message surfaces, eg, Comment #4 in PR44167.
[Bug c++/48294] [C++0x] ICE in build_noexcept_spec, at cp/except.c:1217
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48294 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.1, 4.7.0 Resolution||FIXED Summary|internal compiler error: in |[C++0x] ICE in |build_noexcept_spec, at |build_noexcept_spec, at |cp/except.c:1217|cp/except.c:1217 Known to fail||4.6.0 --- Comment #2 from Paolo Carlini 2011-03-28 16:21:25 UTC --- Fixed for trunk and 4.6.1 by this patch: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01913.html
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248
--- Comment #4 from Jakub Jelinek 2011-03-28
16:15:52 UTC ---
Ah, I can reproduce with those lines.
Apparently caused by my PR41445 fix.
To fix this, I think we should remember not just src_line, but also filename
in print variable in c-ppoutput.c. And, either we should avoid calling
do_line_change for avoid_paste resp. PREV_WHITE in scan_translation_unit if
file is different, or maybe_print_line should do the
if (src_line >= print.src_line && src_line < print.src_line + 8)
optimization only if it is the same file.
As PR41445 has been in already in 4.5 and nobody complained about e.g.
# 1 "pr48248-2.C"
# 1 ""
# 1 ""
# 1 "pr48248-2.C"
# 1 "pr48248.h" 1
enum E { B };
# 2 "pr48248-2.C" 2
# 17 "pr48248-2.C"
void
foo ()
{
(void)
# 3 "pr48248.h"
B
# 20 "pr48248-2.C"
;
a;
}
(where # 3 "pr48248.h" doesn't say that the header is being entered, just
temporarily jumps to it), I'd probably prefer the latter choice, as it gives
more correct locus info.
[Bug other/48318] Memory access error by "build/genhooks"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 Markus Elfring changed: What|Removed |Added Keywords||build --- Comment #1 from Markus Elfring 2011-03-28 16:11:02 UTC --- I assume that an output from the command "dmesg" like the following belongs to the reported situation. [37489.218661] genhooks[4926]: segfault at 60fa40 ip 0060fa40 sp 7fffd3ab7bc8 error 15 in genhooks[60c000+4000]
[Bug c++/48296] [C++0x] constexpr member function cannot use the class type it belongs as parameter type or return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48296 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|constexpr member function |[C++0x] constexpr member |cannot use the class type |function cannot use the |it belongs as parameter |class type it belongs as |type or return type |parameter type or return ||type --- Comment #1 from Paolo Carlini 2011-03-28 16:11:00 UTC --- Adding Jason in CC.
[Bug other/48318] New: Memory access error by "build/genhooks"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 Summary: Memory access error by "build/genhooks"? Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: markus.elfr...@web.de Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu I try to generate the current GCC software for my openSUSE 11.4 system. Unfortunately, I stumble on the following German message. "... /bin/sh /home/elfring/Projekte/GNU/GCC/Quellen/4.6.0/gcc/../move-if-change tmp-optionlist optionlist echo timestamp > s-options build/genhooks \ /home/elfring/Projekte/GNU/GCC/Quellen/4.6.0/gcc/doc/tm.texi.in > tmp-tm.texi gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genconstants \ build/genconstants.o build/read-md.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a /bin/sh: Zeile 1: 29541 Speicherzugriffsfehler build/genhooks /home/elfring/Projekte/GNU/GCC/Quellen/4.6.0/gcc/doc/tm.texi.in > tmp-tm.texi make[3]: *** [s-tm-texi] Fehler 139 make[3]: *** Warte auf noch nicht beendete Prozesse... rm gcc.pod make[3]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl/gcc' make[2]: *** [all-stage1-gcc] Fehler 2 make[2]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl' make[1]: *** [stage1-bubble] Fehler 2 make[1]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl' make: *** [all] Fehler 2" How can this "memory access error"/"segmentation fault" be resolved? I would like to use the configuration parameters "--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr/local".
[Bug go/48312] [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48312 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.28 15:51:34 Ever Confirmed|0 |1 --- Comment #1 from Ian Lance Taylor 2011-03-28 15:51:34 UTC --- Sorry, I forgot about this issue when I updated the library.
[Bug tree-optimization/48195] ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48195 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #2 from Martin Jambor 2011-03-28 15:15:15 UTC --- Mine.
[Bug c++/48289] [4.5/4.6/4.7 regression] -pedantic breaks std::move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48289 --- Comment #3 from Jason Merrill 2011-03-28 15:06:32 UTC --- Author: jason Date: Mon Mar 28 15:06:28 2011 New Revision: 171607 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171607 Log: Revert: PR c++/48289 * pt.c (build_non_dependent_expr): Keep dereferences outside the NON_DEPENDENT_EXPR. Removed: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/move1.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/pt.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/48317] New: SCCVN does not handle vector constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48317
Summary: SCCVN does not handle vector constructors
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
SCCVN does not handle CONSTRUCTORs well (they simply get put into a
reference-kind
single operand). This sucks for things like
vect_cst_.239_4355 = {pretmp.88_1931, pretmp.88_1931};
which the vectorizer generates (or which can happen via intrinsics or
generic vector support even earlier).
Not sure how to handle this variable-size code though.
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
--- Comment #4 from Jonathan Wakely 2011-03-28
14:26:35 UTC ---
slightly further reduced:
template
inline void
bind(Functor&& f, ArgTypes&& a) { }
template
void func( T )
{}
int main( int, char** )
{
bind( func, 0 );
}
this is certainly not a libstdc++ bug (std::bind matches the signature require
by the C++0x draft)
I think the parameter is a non-deduced context, because the argument is an
overload set containing one or more function templates ([temp.deduct.call p6)
So I think this is actually invalid and G++ is right to reject it.
[Bug c/44384] builtin_object_size_ treatment of multidimensional arrays is unexpected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44384 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2011-03-28 14:05:34 UTC --- __builtin_object_size is a builtin for -D_FORTIFY_SOURCE checking, it is not a generic object size computation function, and for strcpy IMHO we don't want to treat each dimension as a field separator.
[Bug tree-optimization/48316] New: missed CSE / reassoc with array offsets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48316
Summary: missed CSE / reassoc with array offsets
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
int
foo (int *p, int i)
{
int i1 = i + 1;
int i2 = i + 2;
return p[i1] + p[i2];
}
int
bar (int *p, unsigned long i)
{
unsigned long i1 = i + 1;
unsigned long i2 = i + 2;
return p[i1] + p[i2];
}
For both testcases (the latter being the more "optimal" input due to
pointer-plus-expr constraints) we miss to CSE the multiplication
of i by 4 which makes the memory references not trivially independent
(based on the same pointer, offsetted by different constants). Such
a case causes vectorization for alias checks being inserted for
gfortran.dg/reassoc_4.f with --param max-completely-peeled-insns=4000
IL on x86_64 is
:
i1_2 = i_1(D) + 1;
i2_3 = i_1(D) + 2;
D.2702_4 = (long unsigned int) i1_2;
D.2703_5 = D.2702_4 * 4;
D.2704_7 = p_6(D) + D.2703_5;
D.2705_8 = MEM[(int *)D.2704_7];
D.2706_9 = (long unsigned int) i2_3;
D.2707_10 = D.2706_9 * 4;
D.2708_11 = p_6(D) + D.2707_10;
D.2709_12 = MEM[(int *)D.2708_11];
D.2701_13 = D.2705_8 + D.2709_12;
return D.2701_13;
vs.
:
i1_2 = i_1(D) + 1;
i2_3 = i_1(D) + 2;
D.2694_4 = i1_2 * 4;
D.2695_6 = p_5(D) + D.2694_4;
D.2696_7 = MEM[(int *)D.2695_6];
D.2697_8 = i2_3 * 4;
D.2698_9 = p_5(D) + D.2697_8;
D.2699_10 = MEM[(int *)D.2698_9];
D.2693_11 = D.2696_7 + D.2699_10;
return D.2693_11;
For the reassoc_4.f testcase the question is whether either SCEV or
data-dependence can be enhanced to handle the cases (the multiplications
are in BB2, outside of any loop).
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248 --- Comment #3 from joerg.rich...@pdv-fs.de 2011-03-28 13:51:55 UTC --- (In reply to comment #2) > Can't reproduce this, neither with g++ 4.5, nor trunk. Did you delete the empty lines?
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2011-03-28 13:47:05 UTC --- Can't reproduce this, neither with g++ 4.5, nor trunk.
[Bug debug/48315] New: ICE in mem_loc_descriptor, at dwarf2out.c:13899
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48315 Summary: ICE in mem_loc_descriptor, at dwarf2out.c:13899 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: armv5tejl-unknown-linux-gnueabi Target: armv5tejl-unknown-linux-gnueabi Build: armv5tejl-unknown-linux-gnueabi Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla2.f90 -B/hom e/dave/gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/ -B/home/dave/gn u/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/.libs -I/home/dave/gnu/gc c/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp -I/home/dave/gnu/gcc/gcc/libg omp/testsuite/.. -fmessage-length=0 -fopenmp -O3 -g -B/home/dave/gnu/gcc/objd ir/armv5tejl-unknown-linux-gnueabi/./libgomp/../libgfortran/.libs -L/home/dave /gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/.libs -lgomp -L/home/d ave/gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/../libgfortran/.lib s -lgfortran -lm -o ./vla2.exe(timeout = 300) /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla2.f90: In function ' foo': /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla2.f90:127:0: interna l compiler error: in mem_loc_descriptor, at dwarf2out.c:13899 FAIL: libgomp.fortran/vla2.f90 -O3 -g (internal compiler error) FAIL: libgomp.fortran/vla2.f90 -O3 -g (test for excess errors) -bash-3.2$ gcc/xgcc -Bgcc/ -v Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: armv5tejl-unknown-linux-gnueabi Configured with: ../gcc/configure --host=armv5tejl-unknown-linux-gnueabi --target=armv5tejl-unknown-linux-gnueabi --build=armv5tejl-unknown-linux-gnueabi --enable-languages=c,c++,fortran,objc,obj-c++ --enable-checking=release --enable-shared --enable-threads --disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch --prefix=/home/dave/opt/gnu/gcc/gcc-4.6.0 --with-gmp=/home/dave/opt/gnu --with-as=/home/dave/opt/gnu/bin/as --with-ld=/home/dave/opt/gnu/bin/ld Thread model: posix gcc version 4.7.0 20110325 (experimental) [trunk revision 171528] (GCC) Similar fails: FAIL: libgomp.fortran/vla6.f90 -O3 -g (internal compiler error) FAIL: libgomp.fortran/vla6.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/vla8.f90 -O3 -g (internal compiler error) FAIL: libgomp.fortran/vla8.f90 -O3 -g (test for excess errors)
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 --- Comment #6 from Tobias Burnus 2011-03-28 13:21:30 UTC --- ==1823== Invalid read of size 1 ==1823==at 0x4C32E7: gfc_check_vardef_context (expr.c:4377) ==1823==by 0x4CBC25: compare_actual_formal (interface.c:2291) ==1823==by 0x4CD48B: gfc_arglist_matches_symbol (interface.c:2813) ==1823==by 0x4CD6F4: gfc_search_interface (interface.c:2842) ==1823==by 0x50D2A2: resolve_call (resolve.c:3204) The issue - or at least cause - for the segfault is the following code in gfc_check_vardef_context: if (!pointer && e->expr_type == EXPR_FUNCTION && e->symtree->n.sym->result->attr.pointer) The problem is that e->symtree->n.sym->result == NULL. The symbol itself is "get_d_string". If one uses gdb's "set e->symtree->n.sym->result = e->symtree->n.sym" and continues, one gets the expected error: Error: There is no specific subroutine for the generic 'set' at (1) One problem seems to be that "get_d_string" is a generic interface - and not a specific one: (gdb) p e->symtree->n.sym->attr.generic $1 = 1 The specific interface has properly the result variables set: (gdb) p e->symtree->n.sym->generic->sym->name $3 = 0x2e876280 "get_d_string_p" (gdb) p e->symtree->n.sym->generic->sym->result $4 = (struct gfc_symbol *) 0x1281280 Calling gfc_check_vardef_context for an generic interface seems to be questionable.
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from H.J. Lu 2011-03-28 13:19:01 UTC --- Fixed.
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276 --- Comment #3 from hjl at gcc dot gnu.org 2011-03-28 13:14:56 UTC --- Author: hjl Date: Mon Mar 28 13:14:47 2011 New Revision: 171604 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171604 Log: Add -fno-pic to gcc.target/i386/pr47502-2.c. 2011-03-28 H.J. Lu PR testsuite/48276 * gcc.target/i386/pr47502-2.c: Add -fno-pic. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr47502-2.c
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson 2011-03-28 13:09:15 UTC --- (In reply to comment #2) > Created attachment 23791 [details] > generated assembler > > On line 114, the generates assembler code refers to .LPIC4, which does not > exists. Indeed. If I compile with -mcpu=arm9tdmi as your assembly file indicates then I lose several lines of code, including the .LPIC4 label and a strcmp() call, but the reference to .LPIC4 remained. Normally I have -march=armv5te -mtune=xscale, and in that case the .LPIC4 label and surrounding code is not lost. Works(*) with gcc-4.4.5 and 4.5.2, so it's a regression. (*) Had to eliminate some apparent C1X-isms from the test case though.
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276
--- Comment #2 from Dominique d'Humieres 2011-03-28
12:52:43 UTC ---
> Please try
>
> ...
> -/* { dg-options "-O2" } */
> +/* { dg-options "-O2 -fno-pic" } */
> ...
It does fix the failure, thanks.
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276
H.J. Lu changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com
--- Comment #1 from H.J. Lu 2011-03-28 12:44:50
UTC ---
Please try
diff --git a/gcc/testsuite/gcc.target/i386/pr47502-2.c
b/gcc/testsuite/gcc.target/i386/pr47502-2.c
index 1f57ea0..a8dc1ca 100644
--- a/gcc/testsuite/gcc.target/i386/pr47502-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr47502-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fno-pic" } */
int
foo (int how, const void *set, void *oset)
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
--- Comment #3 from Jonathan Wakely 2011-03-28
12:43:12 UTC ---
It's not the _Bind constructor, it's the bind() call itself, this demonstrates
the problem:
template
inline
void
bind(_Functor&& __f, _ArgTypes&&... __args) { }
template void func( T )
{}
int main( int, char** )
{
bind( func, 0 );
}
we might just need to overload std::bind for function types
std::bind() in 4.5 was defined differently as it didn't support rvalues
properly, so didn't show the problem
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-28 12:40:06 UTC --- > I don't think thread_leak_test.c was tested before. In that case, please try to compile it with the same flags used for one of the other tests (e.g, leak_test.c) to check if the problem is with my dg conversion or elsewhere. In any case, if this wasn't tested before, it's not a regression. Thanks. Rainer
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #2 from Gerhard Heift 2011-03-28 12:34:31 UTC --- Created attachment 23791 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23791 generated assembler On line 114, the generates assembler code refers to .LPIC4, which does not exists.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #2 from H.J. Lu 2011-03-28 12:31:35 UTC --- (In reply to comment #1) > Could you please check if this test worked before my patch? It may have > been that the failure simply went unnoticed. > I don't think thread_leak_test.c was tested before.
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 --- Comment #2 from Jonathan Wakely 2011-03-28 12:24:23 UTC --- The example can be modified to work by passing a pointer, so the template argument isn't deduced as a function type: std::bind( &func, 0 );
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.28 12:17:25 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-03-28 12:17:25 UTC --- The example should work. I'm travelling today but will check the code later to see why the F&& constructor is being chosen instead of the const F& one.
[Bug c/12742] Type alignment is lost if const is added to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 Richard Guenther changed: What|Removed |Added CC||jepler at unpythonic dot ||net --- Comment #4 from Richard Guenther 2011-03-28 12:02:40 UTC --- *** Bug 42098 has been marked as a duplicate of this bug. ***
[Bug c/42098] gcc does not honor alignment specification for qualified typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Richard Guenther 2011-03-28 12:02:40 UTC --- dup. *** This bug has been marked as a duplicate of bug 12742 ***
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 Richard Guenther changed: What|Removed |Added Blocks||37954 --- Comment #17 from Richard Guenther 2011-03-28 11:58:50 UTC --- PR37954 looks like a dup for arm.
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
Richard Guenther changed:
What|Removed |Added
Target|x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
||i?86-*-*
Component|target |middle-end
Known to fail||2.95.2
--- Comment #16 from Richard Guenther 2011-03-28
11:57:36 UTC ---
Also broken at least since GCC 2.95 on i?86 with
struct colour
{
unsigned char red;
unsigned char green;
unsigned char blue;
};
void print_colour(struct colour col) __attribute__((regparm(3)));
void
foo(struct colour *c)
{
print_colour(*c);
}
[Bug libobjc/48314] New: Make the new symbols weak symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48314 Summary: Make the new symbols weak symbols Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org Hello, gcc 4.6 introduces a lot of new symbols like objc_setProperty, objc_sync_enter etc. Those are often already provided since they were always missing, but support for e.g. @synchronized was always there. This creates conflicts now when using gcc 4.6, thus I would suggest to make those weak symbols in 4.6.1.
[Bug lto/48309] gcc -flto -fuse-linker-plugin generates crashing executables on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48309 --- Comment #3 from Dmitry Gorbachev 2011-03-28 11:35:37 UTC --- (In reply to comment #2) Gordon Magnusson wrote: > C:\bugreport>ld -v > GNU ld (GNU Binutils) 2.21.51.20110326
[Bug libstdc++/48313] New: std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
Summary: std::bind with template function
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat > t.cc << EOF
#include
template void func( T )
{}
int main( int, char** )
{
std::bind( func, 0 );
}
EOF
$ g++ t.cc -std=gnu++0x
t.cc: In function 'int main(int, char**)':
t.cc:8:27: error: cannot bind 'void(int)' lvalue to 'void (&&)(int)'
...
This is with GCC 4.6.0. This works with GCC 4.5.2.
[Bug debug/48229] 4.5.x should produce unambiguous DW_AT_accessibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 Jan Kratochvil changed: What|Removed |Added Summary|DW_TAG_type_unit has no |4.5.x should produce |DW_AT_producer |unambiguous ||DW_AT_accessibility --- Comment #7 from Jan Kratochvil 2011-03-28 11:21:41 UTC --- In such case only the gcc-4.5.x branch should start to produce DW_AT_accessibility unambiguously (explicitly) at least in the -gdwarf-4 mode. This way it will not remain a long term regression testsuite problem.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-28 11:21:20 UTC --- >> supposed to test? pr46940_0.c fails because "only weak aliases are supported" >> on darwin and the other tests pass even without plugin support. > > They are various tests for previously existing bugs (mostly ICEs). Of course > they now work. But Dominique's point that all those tests have dg-require-linker-plugin, but passed on Darwin even without the lto-plugin. Rainer
[Bug middle-end/48310] ask a question about expand_used_vars in cfgexpand.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48310 --- Comment #2 from shushengyu 2011-03-28 11:20:03 UTC --- Oh,sorry!I am not know the rule well. Can you introduce someone who would like to give me some help to me? At 2011-03-28 17:47:06，"rguenth at gcc dot gnu.org" wrote: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48310 > >Richard Guenther changed: > > What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > >--- Comment #1 from Richard Guenther 2011-03-28 >09:47:01 UTC --- >Please ask questions on the GCC mailinglists, not via bugzilla. > >-- >Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email >--- You are receiving this mail because: --- >You reported the bug.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #24 from Richard Guenther 2011-03-28 11:18:44 UTC --- (In reply to comment #20) > > AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. > > given that Mike has approved, > > if someone could chip in with a test on x86-64-darwin10, I would think you > > could apply it. > > I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on > top > of revision 171401 without failures for the tests ran by lto.exp (full test by > tomorrow). > > Now I wonder what are the tests > > gcc/testsuite/gcc.dg/lto/20100722-1_0.c > gcc/testsuite/gcc.dg/lto/20110201-1_0.c > gcc/testsuite/gcc.dg/lto/pr46940_0.c > gcc/testsuite/gcc.dg/lto/pr47188_0.c > gcc/testsuite/gcc.dg/pr43157.c > > supposed to test? pr46940_0.c fails because "only weak aliases are supported" > on darwin and the other tests pass even without plugin support. They are various tests for previously existing bugs (mostly ICEs). Of course they now work.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-28 11:11:09 UTC --- > --- Comment #20 from Dominique d'Humieres > 2011-03-24 18:46:41 UTC --- >> AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. >> given that Mike has approved, >> if someone could chip in with a test on x86-64-darwin10, I would think you >> could apply it. > > I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on > top > of revision 171401 without failures for the tests ran by lto.exp (full test by > tomorrow). Thanks. Based on Iain's and your testing and Mike's approval, I've applied the patch (slightly adapted to match the gcc.c form). > Now I wonder what are the tests > > gcc/testsuite/gcc.dg/lto/20100722-1_0.c > gcc/testsuite/gcc.dg/lto/20110201-1_0.c > gcc/testsuite/gcc.dg/lto/pr46940_0.c > gcc/testsuite/gcc.dg/lto/pr47188_0.c > gcc/testsuite/gcc.dg/pr43157.c > > supposed to test? pr46940_0.c fails because "only weak aliases are supported" > on darwin and the other tests pass even without plugin support. No idea. You'll have to ask the patch authors. This whole LTO and lto-plugin business remains a mystery to me. Rainer
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-03/msg01890.htm ||l CC||ro at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #22 from Rainer Orth 2011-03-28 11:08:39 UTC --- Fixed for 4.7.0.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #21 from Rainer Orth 2011-03-28 11:07:02 UTC --- Author: ro Date: Mon Mar 28 11:06:58 2011 New Revision: 171598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171598 Log: PR target/48245 * config/darwin.h (LINK_COMMAND_SPEC_A): Use LINK_PLUGIN_SPEC. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h
[Bug c/48305] [4.7 Regression] ice at -O0: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48305 --- Comment #2 from Jakub Jelinek 2011-03-28 10:55:56 UTC --- Created attachment 23790 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23790 gcc47-pr48305.patch Untested fix.
[Bug tree-optimization/48295] Incorrect code generated with dynamic floating point rounding mode switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48295 --- Comment #4 from joseph at codesourcery dot com 2011-03-28 10:50:44 UTC --- On Mon, 28 Mar 2011, rguenth at gcc dot gnu.org wrote: > Btw, your testcase would be kindof invalid as you are not using the > documented standard way of accessing fenv but using inline-asm (and > we don't have a special clobber that tells GCC you touched the FP > control word). You mark the asm as reading and clobbering fpcr - that register name already exists in GCC, and it's a bug that glibc's fpu_control.h doesn't use it, though I suppose you'd need to add the "mxcsr" name as well. When -frounding-math is actually properly implemented it ought to be taught about target-specific registers representing rounding modes (and likewise exception status) so it knows how asms interact with the floating-point state. (Non-const, non-pure function calls will also need to be presumed to interact with the state in unknown ways since they may end up calling fenv.h functions.)
[Bug target/47553] ARM neon vld1q_lane_u8 & co. don't accept lanes >= 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 rsand...@gcc.gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from rsandifo at gcc dot gnu.org 2011-03-28 10:49:10 UTC --- Fixed in 4.5, 4.6 and trunk.
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290 --- Comment #4 from Richard Guenther 2011-03-28 10:38:27 UTC --- Thanks Ira.
[Bug go/48312] New: [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48312 Summary: [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01] Created attachment 23789 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23789 Minimal patch to get fd_rtems.go to compile. After the latest libgo import, the network-related libgo tests hang on Solaris 10 and 11/x86. To even get libgo to compile, I needed the attached patch to fd_rtems.go (which should better be called fd_select.go since this is what it really is). Even after that, the http, rpc, and websocket tests just hang in select, as can be seen in the pstack output from the http test: 8131:./a.out - lwp# 1 / thread# 1 fe35b3ab lwp_park (0, 0, 0) fe354e03 cond_wait_queue (de221678, de221660, 0, fe355329) + 63 fe3553a1 __cond_wait (de221678, de221660, 8045158, fe3553e9) + 89 fe3553f7 cond_wait (de221678, de221660, 80451a8, fe35542d) + 27 fe355442 pthread_cond_wait (de221678, de221660, 80451c8, fe3f7500, 18, 8045100) + 24 fe64467c __go_receive_acquire (de221660, 0, 8045218, fe641cb9, 80451f8, 80451f8) + 7c fe6447f1 __go_receive_small_closed (de221660, 0, 0, fe87d6c0, 16) + 41 fe64489d __go_receive_small (de221660, de22c500, 0, 809eaea, 14, 1) + 2d fe7fd1cd libgo_testing.testing.RunTests (8088b38, de40, 30, 30, fefa0810, fee70018) + 21d fe7fd481 libgo_testing.testing.Main (8088b38, de40, 30, 30, de20ebf0, 0) + 81 08088cb4 main.main (4d9060de, 8045720, 80453f0, feffb93c, 8045400, de20) + 48 080958ef main (1, 8045434, 804543c, 8045428, 80640c2, 80956f0) + 1df 08064123 _start (1, 8045788, 0, 8045790, 804579e, 80457aa) + 83 - lwp# 24 / thread# 24 fe35b3ab lwp_park (0, 0, 0) fe354e03 cond_wait_queue (de217f68, de217f50, 0, fe355329) + 63 fe3553a1 __cond_wait (de217f68, de217f50, cdefea68, fe3553e9) + 89 fe3553f7 cond_wait (de217f68, de217f50, de217f50, fe35542d) + 27 fe355442 pthread_cond_wait (de217f68, de217f50, 5a5b497, 321, 8056414, 100) + 24 fe64467c __go_receive_acquire (de217f50, 0, 0, 807e3b8, cdefeb00, fefc0744) + 7c fe643d4e __go_receive_big (de217f50, cdefeb50, de229300, fe6494b7, fedf3f40, de234f20) + 3e 080809b2 libgo_http.http.roundTrip.pN27_libgo_http.http.persistConn (cdefec08, de23f840, de229300, 4, 809c52c, 4) + 112 0807e6b9 libgo_http.http.RoundTrip.pN25_libgo_http.http.Transport (cdefeccc, de20eb60, de229300, fe6494b7, de230005, 11) + 301 0806b2c3 http.send (cdefedb8, de229300, 80a4268, de20eb60, 0, fe3f3000) + 249 0806b5d6 libgo_http.http.Get.pN22_libgo_http.http.Client (cdefee38, de200568, de234f60, 16, cdf00a3c, 0) + 1de 0806b38d libgo_http.http.Get (cdefeee8, de23, 16, fe350f13, 0, fe3f3000) + 4e 08088f87 go.http_test.TestClient (de22c5d0, 0, fee60200, fe353c8c, fe87d6c0, fe8cb584) + 89 fe7fc595 testing.tRunner (de22c5d0, de222348, fe87d6c0, 80bc468, fe8cb584, fe87d6c0) + 25 fe7fc25a testing.$thunk0 (de22c5e0, fe3f3000, cdefefd8, fe35a535, fe3f9e00, fee62000) + 1a fe641b41 start_go_thread (de21b380, fe3f3000, cdefefe8, fe35b079) + 81 fe35b0cc _thrp_setup (cdf00a40) + 9d fe35b370 _lwp_start (cdf00a40, 0, 0, 0, 0, 0) - lwp# 25 / thread# 25 fe35f4a7 pollsys (ce00ed00, 1, 0, 0) fe30afeb pselect (5, de22a000, 0, 0, 0, 0) + 193 fe30b2f1 select (5, de22a000, 0, 0, 0, fefc0744) + 79 fe7fb3f1 libgo_syscalls.syscall.Select (ce00ee40, 5, de22a000, de22a080, 0, 0) + 41 fe6b9301 libgo_net.net.WaitFD.pN22_libgo_net.net.pollster (ce00ef14, de2300a0, de201570, 0, 0, fe3f3000) + 221 fe6c1515 libgo_net.net.Run.pN24_libgo_net.net.pollServer (de201570, 0, fe87d6c0, 80bc440, fe8cb584, fe87d6c0) + e5 fe6b5843 net.$thunk0 (de232288, fe3f3000, ce00efd8, fe35a535, fe3f9e00, fee62000) + 13 fe641b41 start_go_thread (de23f140, fe3f3000, ce00efe8, fe35b079) + 81 fe35b0cc _thrp_setup (cdf00240) + 9d fe35b370 _lwp_start (cdf00240, 0, 0, 0, 0, 0) - lwp# 26 / thread# 26 fe35b3ab lwp_park (0, 0, 0) fe354e03 cond_wait_queue (de221b58, de221b40, 0, fe355329) + 63 fe3553a1 __cond_wait (de221b58, de221b40, cddffc58, fe3553e9) + 89 fe3553f7 cond_wait (de221b58, de221b40, cddffc98, fe35542d) + 27 fe355442 pthread_cond_wait (de221b58, de221b40, 1, fe87d6c0, 72, fe87d6c0) + 24 fe64467c __go_receive_acquire (de221b40, 0, fe50f9e3, fef70018, 3, 0) + 7c fe6447f1 __go_receive_small_closed (de221b40, 0, 0, fe87d6c0, de229280) + 41 fe64489d __go_receive_small (de221b40, de229200, 72, de201570, fe87d6c0, de229280) + 2d fe6ba741 libgo_net.net.WaitRead.pN24_libgo_net.net.pollServer (de20157
[Bug target/47553] ARM neon vld1q_lane_u8 & co. don't accept lanes >= 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 --- Comment #4 from rsandifo at gcc dot gnu.org 2011-03-28 10:32:12 UTC --- Author: rsandifo Date: Mon Mar 28 10:32:09 2011 New Revision: 171597 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171597 Log: gcc/ PR target/47553 * config/arm/predicates.md (neon_lane_number): Accept 0..15. gcc/testsuite/ PR target/47553 * gcc.target/arm/neon-vld-1.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/arm/neon-vld-1.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/arm/predicates.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290
--- Comment #3 from Ira Rosen 2011-03-28 10:30:55 UTC
---
I am going to test this patch. It checks that if we have a phi in outer loop in
the basic block after the inner loop, then this phi is really inner loop's exit
phi, i.e., its operand is defined in the inner loop.
Index: tree-vect-loop.c
===
--- tree-vect-loop.c(revision 171466)
+++ tree-vect-loop.c(working copy)
@@ -1184,11 +1184,11 @@ vect_analyze_loop_operations (loop_vec_i
print_gimple_stmt (vect_dump, phi, 0, TDF_SLIM);
}
+ /* Inner-loop loop-closed exit phi in outer-loop vectorization
+ (i.e. a phi in the tail of the outer-loop). */
if (! is_loop_header_bb_p (bb))
{
- /* inner-loop loop-closed exit phi in outer-loop vectorization
- (i.e. a phi in the tail of the outer-loop).
- FORNOW: we currently don't support the case that these phis
+ /* FORNOW: we currently don't support the case that these phis
are not used in the outerloop (unless it is double reduction,
i.e., this phi is vect_reduction_def), cause this case
requires to actually do something here. */
@@ -1202,6 +1202,32 @@ vect_analyze_loop_operations (loop_vec_i
"Unsupported loop-closed phi in outer-loop.");
return false;
}
+
+ /* If PHI is used in the outer loop, we check that its operand
+ is defined in the inner loop. */
+ if (STMT_VINFO_RELEVANT_P (stmt_info))
+{
+ tree phi_op;
+ gimple op_def_stmt;
+
+ if (gimple_phi_num_args (phi) != 1)
+return false;
+
+ phi_op = PHI_ARG_DEF (phi, 0);
+ if (TREE_CODE (phi_op) != SSA_NAME)
+return false;
+
+ op_def_stmt = SSA_NAME_DEF_STMT (phi_op);
+ if (!op_def_stmt || !vinfo_for_stmt (op_def_stmt))
+return false;
+
+ if (STMT_VINFO_RELEVANT (vinfo_for_stmt (op_def_stmt))
+!= vect_used_in_outer
+ && STMT_VINFO_RELEVANT (vinfo_for_stmt (op_def_stmt))
+ != vect_used_in_outer_by_reduction)
+return false;
+}
+
continue;
}
