[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 --- Comment #5 from Yukhin Kirill 2011-09-28 07:30:46 UTC --- (In reply to comment #4) > I have no problem with > > /export/gnu/import/git/gcc-release/configure --enable-clocale=gnu > --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ i686-linux > --prefix=/usr/gcc-4.6.2-corei7 --with-local-prefix=/usr/local > --enable-gnu-indirect-function --with-arch=corei7 --with-cpu=corei7 > --with-fpmath=sse > > on gcc-4_6-branch at revision 179242. That it strange. Build fails from first svn 4.6 branch revision. Trunk had the same problem which was fixed on 20110729 between svn revisions 176852 176905.
[Bug c++/49855] [4.6/4.7 Regression] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.2 --- Comment #3 from Richard Guenther 2011-09-28 08:19:14 UTC --- #6 0x0071468c in cxx_eval_constant_expression (call=0x0, t=0x2ab38b10, allow_non_constant=1 '\001', addr=0 '\000', non_constant_p=0x7fffcbc7 "") at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/semantics.c:7179 warning: Source file is more recent than executable. 7179 return fold (t); (gdb) call debug_generic_expr (t) (int) 1.5e+6 should be a FIX_TRUNC_EXPR not a NOP_EXPR.
[Bug c++/49855] [4.6/4.7 Regression] internal compiler error: in fold_convert_const_int_from_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855 --- Comment #4 from Richard Guenther 2011-09-28 08:21:46 UTC --- Built via #4 0x00696c37 in build_nop (type=0x2ab4a498, expr=0x2cef96c0) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/typeck.c:4686 #5 0x00590d07 in tsubst_copy_and_build (t=0x2ab38ae0, args=0x0, complain=1, in_decl=0x0, function_p=0 '\000', integral_constant_expression_p=1 '\001') at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/pt.c:12636 #6 0x005539b4 in fold_non_dependent_expr_sfinae (expr=0x2ab38ae0, complain=1) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/pt.c:5226 #7 0x005539ee in fold_non_dependent_expr (expr=0x2ab38ae0) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/pt.c:5240 #8 0x005c5211 in store_init_value (decl=0x2ab561e0, init=0x2cef96c0, flags=11) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/typeck2.c:691 #9 0x004ef608 in check_initializer (decl=0x2ab561e0, init=0x2cef96c0, flags=11, cleanup=0x7fffd058) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/decl.c:5443 #10 0x004f26ae in cp_finish_decl (decl=0x2ab561e0, init=0x2cef96c0, init_const_expr_p=1 '\001', asmspec_tree=0x0, flags=11) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/decl.c:5892
[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485 --- Comment #7 from vries at gcc dot gnu.org 2011-09-28 08:48:05 UTC --- Author: vries Date: Wed Sep 28 08:48:00 2011 New Revision: 179309 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179309 Log: 2011-09-28 Tom de Vries PR testsuite/50485 * gcc.target/i386/sse4_1-blendps.c: Include . (TEST): Initialize src3 with random floats. * gcc.target/i386/sse4_1-blendps-2.c (sse4_1_test): Remove field i from union src3. Initialize src3 with random floats. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendps-2.c trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c
[Bug testsuite/50485] gcc.target/i386/sse4_1-blendps.c fails spuriously on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50485 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | --- Comment #8 from vries at gcc dot gnu.org 2011-09-28 08:50:33 UTC --- patch committed, closing bug.
[Bug fortran/50546] New: gfortran should not accept missing operator (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50546 Bug #: 50546 Summary: gfortran should not accept missing operator (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not accept missing operator (r178939) module m interface assignment(=) end interface end module use m, only : operator(+) end
[Bug fortran/50547] New: dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547 Bug #: 50547 Summary: dummy procedure argument of PURE shall be PURE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! dummy procedure argument of PURE shall be PURE ! Fortran 95 12.6 at page 212 lines 23-24 ! Fortran 2003 C1269 ! Fortran 2008 C1279 pure function f(proc) interface function proc() end end interface end
[Bug fortran/50548] New: gfortran -fcheck=all run time would be nice to detect different shapes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50548 Bug #: 50548 Summary: gfortran -fcheck=all run time would be nice to detect different shapes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran -fcheck=all run time would be nice to detect different shapes type t character,pointer :: c(:) end type type(t) :: u allocate(u%c(1)) u%c(1)='q' if(all(u%c==(/'q','w'/))) stop 'error' ! here end
[Bug fortran/50549] New: should detect different type parameters in structure constructors (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50549 Bug #: 50549 Summary: should detect different type parameters in structure constructors (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! should detect different type parameters in structure constructors (r178939) interface function f1() character(1),pointer :: f1 end end interface type t character(2), pointer :: p2 end type character(1), pointer :: p1 type(t) u u=t(p1)! different character length u=t(f1()) ! type parameters are different (Fortran 95 section 4.4.4) end
[Bug fortran/50550] New: does not recognize pointer variable at initialization (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550 Bug #: 50550 Summary: does not recognize pointer variable at initialization (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! does not recognize pointer variable at initialization (r178939) pointer pi,pr,pl,pc,pcmplx integer :: pi=>null() real :: pr=>null() logical :: pl=>null() character :: pc=>null() complex :: pcmplx=>null() end
[Bug fortran/50551] New: Argumentless NULL() cannot be used with assumed-length dummy (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50551 Bug #: 50551 Summary: Argumentless NULL() cannot be used with assumed-length dummy (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! Argumentless NULL() cannot be used with assumed-length dummy (r178939) ! Fortran 95 corrigendum 2 page 91 line 41 interface subroutine sub(x) pointer x character(*) x end subroutine end interface call sub(null()) ! null() cannot be used with assumed length dummy argument end
[Bug fortran/50552] New: type name cannot be statement function dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552 Bug #: 50552 Summary: type name cannot be statement function dummy argument (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! type name cannot be statement function dummy argument (r178939) type t real g end type f(t)=0 ! this should not be accepted end
[Bug fortran/50553] New: statement function cannot be target (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553 Bug #: 50553 Summary: statement function cannot be target (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! statement function cannot be target (r178939) f(x)=x target f end
[Bug fortran/50554] New: INQUIRE cannot redefine DO index (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554 Bug #: 50554 Summary: INQUIRE cannot redefine DO index(r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! INQUIRE cannot redefine DO index(r178939) do I=1,10 inquire(iolength=I) n end do end
[Bug fortran/50555] New: synonymous namelist/statement function dummy argument not allowed (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 Bug #: 50555 Summary: synonymous namelist/statement function dummy argument not allowed (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! synonymous namelist/statement function dummy argument not allowed (r178939) namelist /i/ j f(i)=0 end
[Bug fortran/50556] New: cannot save namelist group name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556 Bug #: 50556 Summary: cannot save namelist group name Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! cannot save namelist group name namelist /i/ ii save i end
[Bug fortran/50514] gfortran should check ISHFT & ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514 --- Comment #2 from Vittorio Zecca 2011-09-28 09:20:40 UTC --- I meant checking static expressions at compilation time, as in my example. This has no cost at run time. You proposed a run time check that still should be done if requested with a kind of -fcheck option. By the way, gfortran is already checking consistency of static arguments to intrinsic functions, it is that just these one are left unchecked.
[Bug tree-optimization/50557] New: [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 Bug #: 50557 Summary: [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: izamya...@gmail.com After the fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749 (http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176984) I observed a degradation for the attached test. (~9% on Core) Before the fix RA managed to use registers for code related to line #30. After the fix an order of operations has been changed and this apparently led to change in live ranges and hence to increased register pressure. Asm snippet for fast case # 4long.c:30 .loc 1 30 0 movl8(%ecx), %esi xorl%edi, %edi addl%eax, %esi movl52(%esp), %eax adcl%edx, %edi mull8(%ebp) addl%eax, %esi adcl%edx, %edi Asm snippet for slow case # 4long.c:30 .loc 1 30 0 movl52(%esp), %eax mull8(%ebp) movl%eax, (%esp) movl8(%ecx), %eax movl%edx, 4(%esp) xorl%edx, %edx addl%eax, (%esp) adcl%edx, 4(%esp) addl%esi, (%esp) adcl%edi, 4(%esp) gcc is: Target: x86_64-unknown-linux-gnu Configured with: ../configure --disable-bootstrap --enable-languages=c,c++ --prefix=/export/users/izamyati/build/ Thread model: posix gcc version 4.7.0 20110731 (experimental) (GCC) Compilation flags: -O2 -mssse3 -mfpmath=sse -ffast-math -m32
[Bug fortran/50554] INQUIRE cannot redefine DO index (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554 Tobias Burnus changed: What|Removed |Added Keywords||accepts-invalid, diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-28 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus 2011-09-28 10:42:40 UTC --- Confirmed. We need to add a gfc_check_do_variable in io.c's gfc_match_inquire.
[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 Richard Guenther changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541 --- Comment #2 from janus at gcc dot gnu.org 2011-09-28 11:14:16 UTC --- (In reply to comment #1) > This one is trivial: Unfortunately this causes one testsuite regression: FAIL: gfortran.dg/func_derived_4.f90 -O0 (test for excess errors) Reduced test case: module class_field implicit none interface msh module procedure msh end interface contains function msh() integer, pointer :: msh end function end module What is special about this, is that the generic and the specific procedure share the same name. I think the problem is that we only have one symbol for both, which triggers the conflict. Possible solutions: * (quick'n'dirty) refine the check to only raise a conflict if there is no specific procedure with the same name * (cleaner but harder) introduce separate symbols for generics (in a separate symtree), which might also solve our problems with 'constructors' (cf. PR 39427) For specifics and generics with the same name, see also PR 42418.
[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50326 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Martin Jambor 2011-09-28 11:51:35 UTC --- This is now fixed.
[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 --- Comment #1 from Igor Zamyatin 2011-09-28 11:52:18 UTC --- Created attachment 25373 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25373 testcase
[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 --- Comment #2 from William J. Schmidt 2011-09-28 12:13:50 UTC --- The fix for 49749 is intended to remove dependencies between loop iterations. One possibility would be to condition the changes on the presence of -funroll-loops. Another would be to limit the changes to loops containing fewer blocks or otherwise measuring simpler control flow. To help make a good decision here, can you please try your test case with -funroll-loops before and after the fix for 49749?
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #117 from Ruben Van Boxem 2011-09-28 12:14:38 UTC --- Thanks for the effort! Any chance of this being backported to older branches? Seems quite useful for the future.
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460 Richard Guenther changed: What|Removed |Added Keywords||diagnostic --- Comment #7 from Richard Guenther 2011-09-28 12:23:15 UTC --- Btw, this is equivalent to a missing diagnostic, it's correctly not trapping similar as to if it didn't know anything about the object that is refered to. Indeed when I disable the folding during gimplification CCP comes along and does : str1.0_1 = str1; D.2732_2 = str1.0_1 + 5; - D.2733_3 = &a.buf1 + 4; - __dest_7 = (char * restrict) D.2733_3; __src_8 = (const char * restrict) D.2732_2; - D.2747_9 = __builtin_object_size (__dest_7, 1); - D.2746_10 = __builtin___strcpy_chk (__dest_7, __src_8, D.2747_9); - D.2746_12 = D.2746_10; - D.2734_4 = 0; - return D.2734_4; + D.2746_10 = __builtin___strcpy_chk (&MEM[(void *)&a + 4B], __src_8, 6); + return 0; which is good, as the address is invariant. So, short of moving the objsize pass way earlier (which I'm sure we don't want to do), I don't see a good way to recover this diagnostic. One possibility is to make sure try_move_mult_to_index handles the case of &a.buf1 + 4, instead of just &a.buf1[0] + 4. I have a patch for that.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #118 from Jonathan Wakely 2011-09-28 12:21:31 UTC --- (In reply to comment #117) > Any chance of this being backported to older branches? Seems quite useful for > the future. I don't think this (very good, but quite major) change qualifies for stable release branches. If someone is (perhaps foolishly) relying on __cplusplus==1 in 4.5.3 we should not break their code if they upgrade to 4.5.4, they should reasonably expect only bug fixes in that upgrade
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #119 from Paolo Carlini 2011-09-28 12:23:51 UTC --- If you ask me, no way.
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #25 from Jan Hubicka 2011-09-28 12:38:29 UTC --- Thanks for gold support. GCC support is now posted at http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01818.html We miss the GNU LD variant http://sourceware.org/bugzilla/show_bug.cgi?id=13229 Dave, HJ, would be possible to look into that?
[Bug ada/50558] New: Illegal program not detected (record component with no supplied value) and invalid access to atomic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50558 Bug #: 50558 Summary: Illegal program not detected (record component with no supplied value) and invalid access to atomic variable Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: eu...@debian.org Created attachment 25374 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25374 File that triggers the bug The following invalid program (component 'Reserved' does not have default value) compiles with no error (gcc 4.6.1 and 4.7.0 (snapshot) on Debian): package Pkg is type Byte is mod 2**8; type Reserved_24 is mod 2**24; type Data_Record is record Data : Byte; Reserved : Reserved_24; end record; for Data_Record use record Data at 0 range 0 .. 7; Reserved at 0 range 8 .. 31; end record; for Data_Record'Size use 32; for Data_Record'Alignment use 4; end Pkg; package Pkg.Reg is Data_Register : Data_Record; pragma Atomic (Data_Register); end Pkg.Reg; with Pkg.Reg; procedure Test is begin Pkg.Reg.Data_Register := ( Data => 255, others => <> -- expected error: no value supplied for component "Reserved" ); end Test; gnat gives expected error message if definition of Data_Register moved to Pkg. Representation clause for Data_Record and pragma Atomic is not required to trigger this bug, but with them strange assembler code generated at leas on x86_64 and cortex-m3: _ada_test: movl$0, pkg__reg__data_register(%rip) movb$-1, pkg__reg__data_register(%rip) ret _ada_test: ldr r3, .L2 movsr2, #0 str r2, [r3, #0] movsr2, #255 strbr2, [r3, #0] bx lr Note that atomic variable is accessed twice. I'm not yet sure if this bug can be reproduced by a valid program.
[Bug ada/50558] Illegal program not detected (record component with no supplied value) and invalid access to atomic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50558 --- Comment #1 from Eugeniy Meshcheryakov 2011-09-28 13:08:48 UTC --- Created attachment 25375 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25375 Invalid program correctly detected This is test program with definition of Data_Register moved to parent package. gnat correctly detects invalid program: % gnatmake test.adb gcc-4.6 -c test.adb test.adb:5:25: no value supplied for component "Reserved" gnatmake: "test.adb" compilation error
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #112 from Jan Hubicka 2011-09-28
13:33:03 UTC ---
OK, the problem turns out to be configure issue. Configure script greps asm
output and with slim LTO it does not find there what it expects disabling
hidden visibilities. No surprise this leads to a performance disaster. I use
the following hack:
diff -r 06b2977afb85 configure.in
--- a/configure.in Fri Sep 09 23:25:02 2011 -0400
+++ b/configure.in Wed Sep 28 15:30:56 2011 +0200
@@ -3035,7 +3035,7 @@
int foo __attribute__ ((visibility ("hidden"))) = 1;
EOF
ac_cv_visibility_hidden=no
- if ${CC-cc} -Werror -S conftest.c -o conftest.s >/dev/null
2>&1; then
+ if ${CC-cc} -Werror -S -fno-lto conftest.c -o conftest.s
>/dev/null 2>&1; then
if egrep '\.(hidden|private_extern).*foo' conftest.s
>/dev/null; then
ac_cv_visibility_hidden=yes
fi
@@ -3051,7 +3051,7 @@
int foo __attribute__ ((visibility ("default"))) = 1;
EOF
ac_cv_visibility_default=no
-if ${CC-cc} -fvisibility=hidden -Werror -S conftest.c -o
conftest.s >/dev/null 2>&1; then
+if ${CC-cc} -fvisibility=hidden -Werror -S -fno-lto
conftest.c -o conftest.s >/dev/null 2>&1; then
if ! egrep '\.(hidden|private_extern).*foo' conftest.s
>/dev/null; then
ac_cv_visibility_default=yes
fi
@@ -3070,7 +3070,7 @@
int foo_default = 1;
EOF
ac_cv_visibility_pragma=no
- if ${CC-cc} -Werror -S conftest.c -o conftest.s
>/dev/null 2>&1; then
+ if ${CC-cc} -Werror -S -fno-lto conftest.c -o conftest.s
>/dev/null 2>&1; then
if egrep '\.(hidden|private_extern).*foo_hidden'
conftest.s >/dev/null; then
if ! egrep '\.(hidden|private_extern).*foo_default'
conftest.s > /dev/null; then
ac_cv_visibility_pragma=yes
@@ -3092,7 +3092,7 @@
}
EOF
ac_cv_have_visibility_class_bug=no
- if ! ${CXX-g++} ${CXXFLAGS} ${DSO_PIC_CFLAGS}
${DSO_LDOPTS} -S -o conftest.S conftest.c > /dev/null 2>&1 ; then
+ if ! ${CXX-g++} ${CXXFLAGS} ${DSO_PIC_CFLAGS}
${DSO_LDOPTS} -S -fno-lto -o conftest.S conftest.c > /dev/null 2>&1 ; then
ac_cv_have_visibility_class_bug=yes
else
if test `egrep -c '@PLT|\\$stub' conftest.S` = 0;
then
@@ -3116,7 +3116,7 @@
}
EOF
ac_cv_have_visibility_builtin_bug=no
- if ! ${CC-cc} ${CFLAGS} ${DSO_PIC_CFLAGS} ${DSO_LDOPTS}
-O2 -S -o conftest.S conftest.c > /dev/null 2>&1 ; then
+ if ! ${CC-cc} ${CFLAGS} ${DSO_PIC_CFLAGS} ${DSO_LDOPTS}
-O2 -S -fno-lto -o conftest.S conftest.c > /dev/null 2>&1 ; then
ac_cv_have_visibility_builtin_bug=yes
else
if test `grep -c "@PLT" conftest.S` = 0; then
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460 --- Comment #8 from Richard Guenther 2011-09-28 13:47:16 UTC --- Author: rguenth Date: Wed Sep 28 13:47:12 2011 New Revision: 179313 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179313 Log: 2011-09-28 Richard Guenther PR middle-end/50460 * fold-const.c (try_move_mult_to_index): Handle &a.array the same as &a.array[0]. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Richard Guenther 2011-09-28 13:47:57 UTC --- Fixed^WWorked around.
[Bug ada/50558] Illegal program not detected (record component with no supplied value) and invalid access to atomic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50558 --- Comment #2 from Eugeniy Meshcheryakov 2011-09-28 13:51:43 UTC --- Output with -gnatG looks different for two programs. For good.ada: with pkg; procedure test is begin T1b : pkg__data_record := ( data => 255); pkg.pkg__data_register := T1b; end test; test.adb:5:25: no value supplied for component "Reserved" For test.ada: with pkg; with pkg.pkg__reg; procedure test is begin pkg.pkg__reg.pkg__reg__data_register := ( data => 255); return; end test; But manually adding a temporary variable does not help.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #120 from Ruben Van Boxem 2011-09-28 13:58:03 UTC --- OK, somewhat understandable to keep evil legacy code compiling. Last plea for Standards conformance: What about only setting the correct define if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=gnu++*?
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #121 from Marc Glisse 2011-09-28 14:20:09 UTC --- (In reply to comment #120) > Last plea for Standards conformance: What about only setting the correct > define > if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=gnu++*? I don't think so. First, that would be weird. And this isn't just about switching a #define, it comes with a lot of other changes. Besides, it wouldn't help you at all. The only thing that the value of __cplusplus can be good for now is distinguishing between C++03 and C++11, but even trunk doesn't set the C++11 value, and my hope is that it won't set it until C++11 support is essentially complete.
[Bug c++/49949] wrong sign for product of complex and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 Paolo Carlini changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Paolo Carlini 2011-09-28 14:57:26 UTC --- I can reproduce the problem with gcc4.5.x and 4.6.x, but mainline (would be 4.7.0) is fine. Did it ever work for you with older compilers? Because if isn't a regression, I'm afraid that not much will happen. But would be still interesting to understand what fixed the problem in mainline...
[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus 2011-09-28 15:02:02 UTC --- (In reply to comment #2) > What is special about this, is that the generic and the specific procedure > share the same name. I think the problem is that we only have one symbol for > both, which triggers the conflict. I think one could solve this at parse time. When parsing POINTER and sym->attr.generic and gfc_ns_current->proc_name != sym, we set the attribute to an interface block. Ditto when parsing "INTERFACE ": If one has already sym->attr.pointer, it is a bug. That should work without further changes. Regarding the constructor patch (PR 39427): At least with my current draft patch does not use a different symbol.
[Bug c++/49949] wrong sign for product of complex and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 Paolo Carlini changed: What|Removed |Added CC||hjl.tools at gmail dot com Severity|minor |normal --- Comment #7 from Paolo Carlini 2011-09-28 15:10:47 UTC --- HJ, any chance you can find what fixed this? Doesn't seem a regression, but it's an annoying issue anyway, if the patch is simple...
[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 Stupachenko Evgeny changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #6 from Stupachenko Evgeny 2011-09-28 15:17:04 UTC --- First good svn revision on trunk: 176871 Corresponding commit: commit 6b4db1bd8cef61c66671c8249c21f6fdc8ccce06 Author: hjl Date: Thu Jul 28 14:29:38 2011 + Set need_64bit_hwint to yes for x86 targets. gcc/ 2011-07-28 H.J. Lu * config.gcc: Set need_64bit_hwint to yes for x86 targets. libcpp/ 2011-07-28 H.J. Lu * configure.ac: Set need_64bit_hwint to yes for x86 targets. * configure: Regenerated. gcc-4.6 build with corresponding patch passed.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #122 from Jonathan Wakely 2011-09-28 15:34:22 UTC --- (In reply to comment #120) > Last plea for Standards conformance: What about only setting the correct > define > if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=gnu++*? No. If you want the new behaviour then you have to wait for the new release.
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749
--- Comment #7 from Paolo Carlini 2011-09-28
15:35:22 UTC ---
First blush, I would say this is malformed code, even if we produce "only" a
warning with -Wreturn-type. And after all we produce only a warning also for
false substituted to flag in the conditional or if we remove the conditional
altogether: why nobody is complaining that we don't just reject:
bool fn_bad(bool flag)
{
}
? If we check the standard carefully (we/I should), I bet it says that here we
have undefined behavior (with all its implications) irrespective of the actual
flow at run-time, even if diagnostics is not required.
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749 --- Comment #8 from Jonathan Wakely 2011-09-28 15:41:27 UTC --- Yep, [stmt.return]/2 "Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function."
[Bug c++/49949] wrong sign for product of complex and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #8 from H.J. Lu 2011-09-28 15:54:09 UTC --- (In reply to comment #0) > With the -O2 flag and in a very specialized circumstance, the product of a > complex and a double has the wrong sign. > > The problem arises when the blitz++ array library is used. > (http://www.oonumerics.org/blitz/) Unfortunately, I could not prune out all > the > references to the unnecessary C++ standard libraries. The size of the .ii file > is therefore pretty big. I hope the report will still be useful. > > The output of the executable gcc_complex_bug should be > > (-0.0,-1.0)x100.0=(0.0,100.0) > I also got (-0.0,-1.0)x100.0=(-0.0,-100.0) with GCC 4.7.0 revision 179164. Why should we get (0.0,100.0)?
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749 Paolo Carlini changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #9 from Paolo Carlini 2011-09-28 15:57:08 UTC --- Good. Are we sure that means "statically" so to speak? Or that flowing should be instead read as something happening at run-time? I cannot fully convince myself. Are there other uses of "flowing" in the standard which clarify the reading? Anyway, in case nobody said it already, on x86_64-linux we *do* return true when flag is true, in all the active release branches, and all in all I agree that it seems a "safer" behavior but I cannot quickly see if I can reproduce the issue for arm-unknown-linux-uclibc...
[Bug ada/50558] Legal program rejected (record component with no supplied value) and invalid access to atomic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50558 --- Comment #3 from Eugeniy Meshcheryakov 2011-09-28 15:58:00 UTC --- After reading Ada 2005 rationale I think that the program in attachment 25374 is valid (components with no default values should be left undefined) and the other one is invalid (but I cannot find confirmation in RM, in any case one of the programs is invalid). Then gnat produces incorrect code for atomic variable in valid code.
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749 --- Comment #10 from Jonathan Wakely 2011-09-28 16:01:45 UTC --- FWIW, the reflector thread starting with c++std-core-12400 has lots of rationale why a diagnostic isn't required. One reason is C compatibility as it's only undefined in C if the return value is used by the caller (which is what I was thinking of in comment 1). Another reason is that it's not always possible to tell at compile-time if it will ever be reached, e.g. there might be a call to a function that will never return, but doesn't have attribute((noreturn)), or a call to a function which always throws.
[Bug c++/49949] wrong sign for product of complex and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #9 from Paolo Carlini 2011-09-28 16:02:05 UTC --- HJ, I think the correct output, showing that we are *not* miscompiling or something is: (-0.0,-1.0)x100.0=(-0.0,-100.0) exactly what you are seeing. The problem is, with 4.6 we get: (-0.0,-1.0)x100.0=(0.0,100.0) which is wrong. When that changed?
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749 --- Comment #11 from Jonathan Wakely 2011-09-28 16:05:21 UTC --- To answer your specific question, flowing isn't defined, neither is "the flow of control", but my reading is it means at runtime, for the reasons in my previous comment. If the compiler can prove at compile-time it will happen, then maybe the as-if rule applies, but it gets tricky in some cases and that's probably why GCC only makes it a warning.
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749 --- Comment #12 from Paolo Carlini 2011-09-28 16:13:33 UTC --- Ok, thanks Jonathan. Thus, let's see first if somebody can actually reproduce the issue!
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749 --- Comment #13 from Paolo Carlini 2011-09-28 16:23:40 UTC --- Of course if Davide could try something more recent than 4.4.4, it would be useful. Note that on Linux even current 4.4 branch is Ok.
[Bug c++/49126] timevar_stack faild because define_label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49126 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Paolo Carlini 2011-09-28 16:29:57 UTC --- Cannot reproduce.
[Bug c++/50559] New: g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559 Bug #: 50559 Summary: g++ bails out after seeing overflow in an enumeration value Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dnetserrs...@gmail.com Created attachment 25376 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25376 preprocessed output of a file with overflowing enum constant values
[Bug c++/50559] g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559 --- Comment #1 from dnetserrspam at gmail dot com 2011-09-28 17:24:18 UTC --- When g++ compiles the attached code it complains (correctly) that the value for GREEN overflows. Then it reports that it is confused by earlier errors and bails out.
[Bug c++/50559] g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559 --- Comment #2 from Andrew Pinski 2011-09-28 17:27:25 UTC --- Hmm, it does not ICE on the trunk.
[Bug c++/50559] g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559
--- Comment #3 from Andrew Pinski 2011-09-28
17:27:41 UTC ---
Reduced testcase:
typedef enum ColorTag { RED = 2147483647, GREEN, BLUE } Color;
int main()
{
Color x = GREEN;
return 0;
}
[Bug c++/48914] #pragma GCC diagnostic ignored "-Wc++0x-compat" doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 --- Comment #2 from Paolo Carlini 2011-09-28 17:34:44 UTC --- So far have been able to figure out that diagnostic_classify_diagnostic apparently sets correctly context->n_classification_history to 1 when the pragma is parsed, but then is found == 0 in diagnostic_report_diagnostic.
[Bug c++/50559] g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #4 from Daniel Krügler 2011-09-28 17:54:55 UTC --- (In reply to comment #3) > Reduced testcase: Just to be sure: Is this testcase rejected? If so, this seems in violation to the C++(03) standard based on 7.2 p4: "[..] Otherwise the type is the same as the type of the initializing value of the preceding enumerator unless the incremented value is not representable in that type, in which case the type is an unspecified integral type sufficient to contain the incremented value." The discussed enumeration should fit when the underlying type would be unsigned long. Please ignore this comment, if my preconditions are not satisfied ;-)
[Bug c++/50559] g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559 --- Comment #5 from Andrew Pinski 2011-09-28 17:56:47 UTC --- (In reply to comment #4) > (In reply to comment #3) > > Reduced testcase: > > Just to be sure: Is this testcase rejected? If so, this seems in violation to > the C++(03) standard based on 7.2 p4: It is not rejected on the trunk.
[Bug web/50297] Bugzilla suffers an internal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50297 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-28 CC||LpSolit at netscape dot net Ever Confirmed|0 |1 Severity|normal |critical --- Comment #1 from Frédéric Buclin 2011-09-28 18:01:05 UTC --- Confirmed. I'll investigate.
[Bug c++/49949] wrong sign for product of complex and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #10 from H.J. Lu 2011-09-28 18:03:50 UTC --- It is fixed by revision 172430: http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00625.html
[Bug c++/50559] g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559 --- Comment #6 from Jonathan Wakely 2011-09-28 18:21:52 UTC --- probably related to PR 48536
[Bug c++/50560] New: g++ optimization -O3 is removing symbols from templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50560 Bug #: 50560 Summary: g++ optimization -O3 is removing symbols from templates Classification: Unclassified Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: marktrinh.j...@gmail.com Created attachment 25377 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25377 sample source files to reproduce the problem gcc 4.5.1: When compiling/linking my sample library, it seems that the optimization level -O3 is not finding symbols where -O2 & -O1 works just fine. make g++ -g -fPIC -Wall -O3 -c -o bug_Option.o bug_Option.cpp g++ -g -fPIC -Wall -O3 -c -o UseOption.o UseOption.cpp g++ -g -shared -Wl,-z,defs -g -shared -o libOption.so bug_Option.o UseOption.o UseOption.o: In function `foo()': /tmp/bug/UseOption.cpp:4: undefined reference to `Option, std::allocator > >::Option()' collect2: ld returned 1 exit status make: *** [libOption.so] Error 1 I've attached my code. change the GNUmakefile CXXFLAGS to -O2 to see it work.
[Bug c++/50559] g++ bails out after seeing overflow in an enumeration value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50559
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
--- Comment #7 from Jonathan Wakely 2011-09-28
18:25:47 UTC ---
definitely a dup, adding int main(){E e = EI_2;} to the testcase of PR 48536
reproduces the bailout.
*** This bug has been marked as a duplicate of bug 48536 ***
[Bug c++/48536] [C++0x] Automatic Enumerator Incrementation is not compliant with Clause 7.2/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48536 Jonathan Wakely changed: What|Removed |Added CC||dnetserrspam at gmail dot ||com --- Comment #5 from Jonathan Wakely 2011-09-28 18:25:47 UTC --- *** Bug 50559 has been marked as a duplicate of this bug. ***
[Bug web/50297] Bugzilla suffers an internal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50297
--- Comment #2 from Frédéric Buclin 2011-09-28
18:28:31 UTC ---
I just enabled Bugzilla debug mode, and the relevant error is:
undef error - Insecure dependency in parameter 3 of
DBI::db=HASH(0xb097df4)->selectrow_hashref method call while running with -T
switch at Bugzilla/Object.pm line 93. at Bugzilla/Object.pm line 93
Bugzilla::Object::_init('Bugzilla::Attachment', 23798) called at
Bugzilla/Object.pm line 58 Bugzilla::Object::new('Bugzilla::Attachment', 23798)
called at Bugzilla/Template.pm line 274
Bugzilla::Template::get_attachment_link(23798, 'attachment 23798') called at
Bugzilla/Template.pm line 230 Bugzilla::Template::quoteUrls('Created attachment
23798\x{a}partially reduced testcase\x{a}\x{a}Compiler...',
'Bugzilla::Bug=HASH(0xb180258)', 'Bugzilla::Comment=HASH(0xb3a22a4)') called at
Bugzilla/Template.pm line 698 Bugzilla::Template::__ANON__('Created attachment
23798\x{a}partially reduced testcase\x{a}\x{a}Compiler...') called at
template/en/default/bug/comments.html.tmpl line 188 eval {...} called at
template/en/default/bug/comments.html.tmpl line 121
[Bug c++/50560] g++ optimization -O3 is removing symbols from templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50560 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely 2011-09-28 18:31:23 UTC --- definitions of templates need to be visible in every file which instantiates them
[Bug c++/50560] g++ optimization -O3 is removing symbols from templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50560 --- Comment #2 from Jonathan Wakely 2011-09-28 18:37:37 UTC --- your hack to allow "separately compiled template components" isn't valid C++, but you can make the code valid by putting an explicit instantiation declaration in the header: extern template class Option; and an explicit instantiation definition in bug_Option.cpp (after all the members have been defined) template class Option;
[Bug web/50297] Bugzilla suffers an internal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50297 --- Comment #3 from Frédéric Buclin 2011-09-28 19:19:28 UTC --- This is totally crazy. Perl complains that the attachment ID is tainted if you are logged out, but not if you are logged in. And the error comes right *after* a call to detaint_natural(), whose job is to detaint the data!! I suspect this is a bug in Perl 5.8.5 itself. I cannot reproduce with Perl 5.12.3.
[Bug fortran/50547] dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||accepts-invalid
Last reconfirmed||2011-09-28
CC||janus at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2011-09-28 19:20:26 UTC ---
We do have such a check, we just need to trigger it. Draft patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 179310)
+++ gcc/fortran/resolve.c (working copy)
@@ -269,8 +269,12 @@ resolve_formal_arglist (gfc_symbol *proc)
if (sym->attr.if_source != IFSRC_UNKNOWN)
resolve_formal_arglist (sym);
- if (sym->attr.subroutine || sym->attr.external || sym->attr.intrinsic)
+ if (sym->attr.subroutine || sym->attr.function || sym->attr.external
+ || sym->attr.intrinsic || sym->attr.flavor == FL_PROCEDURE)
{
+ /* Some checks for dummy procedures. */
+
+ /* Check for F08:C1279. */
if (gfc_pure (proc) && !gfc_pure (sym))
{
gfc_error ("Dummy procedure '%s' of PURE procedure at %L must "
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Jason Merrill 2011-09-28 19:26:19 UTC --- 14.9.2/8: Only invalid types and expressions in the immediate context of the function type and its template parameter types can result in a deduction failure. [ Note: The evaluation of the substituted types and expressions can result in side effects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-defined functions, etc. Such side effects are not in the “immediate context” and can result in the program being ill-formed. — end note ]
[Bug c++/49913] ICE from -O2 -fgraphite-identity : extract_range_from_binary_expr, at tree-vrp.c:2318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49913 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Paolo Carlini 2011-09-28 19:29:27 UTC --- Worksforme with today's (r179319) 4.7. Please try again, and, in case, feel free to re-open.
[Bug c++/50560] g++ optimization -O3 is removing symbols from templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50560 --- Comment #3 from Mark 2011-09-28 19:38:05 UTC --- Thanks for the quick response. Your solution works.
[Bug web/50297] Bugzilla suffers a taint issue when viewing bug 48333 while being logged out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50297 Frédéric Buclin changed: What|Removed |Added Summary|Bugzilla suffers an |Bugzilla suffers a taint |internal error |issue when viewing bug ||48333 while being logged ||out Severity|critical|major --- Comment #4 from Frédéric Buclin 2011-09-28 19:38:40 UTC --- The error doesn't occur with all bugs having attachments in them. For instance, I could view bug 28382 without any problem. So the good news is that this problem seems to affect a few bugs at most.
[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 --- Comment #7 from Yukhin Kirill 2011-09-28 19:42:52 UTC --- Anybody but me and Evgeny can confirm that? I've tried really general path of build it and got fail to compare different stages...
[Bug fortran/50514] gfortran should check ISHFT & ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514
--- Comment #3 from Steve Kargl
2011-09-28 19:45:48 UTC ---
On Wed, Sep 28, 2011 at 09:20:40AM +, zeccav at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514
>
> --- Comment #2 from Vittorio Zecca 2011-09-28
> 09:20:40 UTC ---
> I meant checking static expressions at compilation time, as in my example.
> This has no cost at run time.
I know want you meant.
> You proposed a run time check that still should be done if requested with a
> kind of -fcheck option.
I disagree.
> By the way, gfortran is already checking consistency of static arguments to
> intrinsic functions, it is that just these one are left unchecked.
Yes, I know. I wrote some of the code.
Index: testsuite/gfortran.dg/ishft_3.f90
===
--- testsuite/gfortran.dg/ishft_3.f90(revision 179208)
+++ testsuite/gfortran.dg/ishft_3.f90(working copy)
@@ -1,11 +1,38 @@
! { dg-do compile }
+! PR fortran/50514
program ishft_3
- integer i, j
- write(*,*) ishftc( 3, 2, 3 )
- write(*,*) ishftc( 3, 2, i )
- write(*,*) ishftc( 3, i, j )
- write(*,*) ishftc( 3, 128 ) ! { dg-error "exceeds BIT_SIZE of first" }
- write(*,*) ishftc( 3, 0, 128 ) ! { dg-error "exceeds BIT_SIZE of first" }
- write(*,*) ishftc( 3, 0, 0 )! { dg-error "Invalid third argument" }
- write(*,*) ishftc( 3, 3, 2 )! { dg-error "exceeds third argument" }
+
+ implicit none
+
+ integer j, m
+
+ m = 42
+ !
+ ! These should compile.
+ !
+ j = ishft(m, 16)
+ j = ishft(m, -16)
+ j = ishftc(m, 16)
+ j = ishftc(m, -16)
+ !
+ ! These should issue an error.
+ !
+ j = ishft(m, 640)! { dg-error "absolute value of SHIFT" }
+ j = ishftc(m, 640) ! { dg-error "absolute value of SHIFT" }
+ j = ishft(m, -640) ! { dg-error "absolute value of SHIFT" }
+ j = ishftc(m, -640) ! { dg-error "absolute value of SHIFT" }
+
+ ! abs(SHIFT) must be <= SIZE
+
+ j = ishftc(m, 1, 2)
+ j = ishftc(m, 1, 2)
+ j = ishftc(m, -1, 2)
+ j = ishftc(m, -1, 2)
+
+ j = ishftc(m, 10, 2)! { dg-error "absolute value of SHIFT" }
+ j = ishftc(m, 10, 2)! { dg-error "absolute value of SHIFT" }
+ j = ishftc(m, -10, 2)! { dg-error "absolute value of SHIFT" }
+ j = ishftc(m, -10, 2)! { dg-error "absolute value of SHIFT" }
+
+ j = ishftc(m, 1, -2) ! { dg-error "must be positive" }
end program
Index: fortran/check.c
===
--- fortran/check.c(revision 179208)
+++ fortran/check.c(working copy)
@@ -318,6 +318,22 @@ less_than_bitsize1 (const char *arg1, gf
{
gfc_extract_int (expr2, &i2);
i3 = gfc_validate_kind (BT_INTEGER, expr1->ts.kind, false);
+
+ /* For ISHFT[C], |shift| <= bit_size(i). */
+ if (strncmp (arg2, "ISHFT", 5) == 0)
+{
+ if (i2 < 0)
+i2 = -i2;
+
+ if (i2 > gfc_integer_kinds[i3].bit_size)
+{
+ gfc_error ("The absolute value of SHIFT at %L must be less "
+ "than or equal to BIT_SIZE('%s')",
+ &expr2->where, arg1);
+ return FAILURE;
+}
+}
+
if (or_equal)
{
if (i2 > gfc_integer_kinds[i3].bit_size)
@@ -1961,6 +1977,9 @@ gfc_check_ishft (gfc_expr *i, gfc_expr *
|| type_check (shift, 1, BT_INTEGER) == FAILURE)
return FAILURE;
+ if (less_than_bitsize1 ("I", i, "ISHFT", shift, true) == FAILURE)
+return FAILURE;
+
return SUCCESS;
}
@@ -1972,7 +1991,35 @@ gfc_check_ishftc (gfc_expr *i, gfc_expr
|| type_check (shift, 1, BT_INTEGER) == FAILURE)
return FAILURE;
- if (size != NULL && type_check (size, 2, BT_INTEGER) == FAILURE)
+ if (size != NULL)
+{
+ int i2, i3;
+
+ if (type_check (size, 2, BT_INTEGER) == FAILURE)
+return FAILURE;
+
+ if (less_than_bitsize1 ("I", i, "SIZE", size, true) == FAILURE)
+return FAILURE;
+
+ gfc_extract_int (size, &i3);
+ if (i3 <= 0)
+{
+ gfc_error ("SIZE at %L must be positive", &size->where);
+ return FAILURE;
+}
+
+ gfc_extract_int (shift, &i2);
+ if (i2 < 0)
+i2 = -i2;
+
+ if (i2 > i3)
+{
+ gfc_error ("The absolute value of SHIFT at %L must be less than "
+ "or equal to SIZE at %L", &shift->where, &size->where);
+ return FAILURE;
+}
+}
+ else if (less_than_bitsize1 ("I", i, "ISHFTC", shift, true) == FAILURE)
return FAILURE;
return SUCCESS;
[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2011-09-28 20:00:54 UTC --- The cases in comment #0 are rather easily fixable in the current implementation. However, the harder case will be the following: integer :: j => null() pointer :: j end because when parsing the init, we don't know yet whether the object is a pointer or not (which means the check would have to be deferred to resolution stage). Looking at F08:R505 and friends, I don't see an obvious reason why any of the cases listed here should be forbidden.
[Bug c++/48420] Missed -Wconversion-null warning when passing const bool to T*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48420 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-28 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-09-28 20:03:34 UTC --- Interestingly, in C++0x mode it works, obviously thanks to the work on constexpr. Do you really want it for C++98 too? ;)
[Bug c++/48420] Missed -Wconversion-null warning when passing const bool to T*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48420 --- Comment #2 from Paolo Carlini 2011-09-28 20:05:32 UTC --- Oops, sorry, got confused, in C++0x it's an hard error. Uhmmm.
[Bug fortran/50553] statement function cannot be target (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||accepts-invalid
Last reconfirmed||2011-09-28
CC||janus at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2011-09-28 20:13:50 UTC ---
Simple patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 179310)
+++ gcc/fortran/symbol.c(working copy)
@@ -684,6 +684,7 @@
{
case PROC_ST_FUNCTION:
conf2 (dummy);
+ conf2 (target);
break;
case PROC_MODULE:
[Bug c++/45278] -Wextra doesn't warn about (pointer < 0 ).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45278 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Known to fail|| --- Comment #2 from Paolo Carlini 2011-09-28 20:40:03 UTC --- On it.
[Bug middle-end/50561] New: [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561 Bug #: 50561 Summary: [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net getting this with trunk r179143, on Ubuntu 11.10/x86-64: /usr/lib/gcc-snapshot/bin/x86_64-linux-gnu-gcc -O2 -floop-flatten -floop-strip-mine -c ~/src/trees.i trees.c: In function 'init_block': trees.c:414:13: internal compiler error: in psct_dynamic_dim, at graphite-poly.h:659 It doesn't happen with -O1, or if you remove either of the loop options. This doesn't happen with 4.6.1. Pre-processed source is attached, but it quick to reproduce with zlib 1.2.3.4 sources.
[Bug middle-end/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561 --- Comment #1 from Matt Hargett 2011-09-28 20:59:07 UTC --- Created attachment 25378 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25378 pre-processed source of the file that triggers the ICE
[Bug middle-end/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561 Matt Hargett changed: What|Removed |Added Severity|normal |major
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527 --- Comment #7 from Paolo Carlini 2011-09-28 21:09:59 UTC --- Thanks, the "usual" misinterpretation, in other terms (honestly, in this specific case I didn't look at the actual code closely enough to even try to figure out myself).
[Bug c++/42356] confused compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #6 from Paolo Carlini 2011-09-28 21:21:40 UTC --- For the record, ICC also thinks it's ambiguous.
[Bug other/50562] New: configure: --without-newlib does not disable libgloss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50562
Bug #: 50562
Summary: configure: --without-newlib does not disable libgloss
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jsten...@cisco.com
While running the top level configure from latest trunk to build a Solaris
cross compiler on a Linux host, if I pass in --without-newlib, libgloss is not
disabled. This causes the Solaris cross build to fail since libgloss won't
build for Solaris crosses on Linux hosts.
configure already provides the --without-newlib flag, and we would like to use
this to cleanly disable both libgloss and newlib, but we currently cannot since
only newlib is disabled with this flag, not libgloss.
The reason libgloss is not disabled is that this code in configure:
# Recognize --with-newlib/--without-newlib.
case ${with_newlib} in
no) skipdirs="${skipdirs} target-newlib" ;;
Does not disable libgloss. Later on in configure, if noconfigdirs includes
newlib, libgloss is disabled. So this appears to be an inconsistency between
the way noconfigdirs and skipdirs are treated.
Thus, when calling configure as follows:
../gcc/configure --build=x86_64-linux --target=sparc-sun-solaris2.10
--host=x86_64-linux --enable-languages=c,c++ --enable-targets=sparc-\
sun-solaris2.10,sparcv9-sun-solaris2.10 --with-gnu-ld --with-gnu-as
--enable-multilib --enable-threads=solaris --disable-nls --without-newlib
I still see libgloss being built during the subsequent make:
libgloss/libnosys/fstat.c:6:19: fatal error: _ansi.h: No such file or directory
I propose the following diff to fix this issue so that --without-newlib also
disables libgloss.
Index: configure.ac
===
--- configure.ac(revision 179288)
+++ configure.ac(working copy)
@@ -276,7 +276,7 @@
# Recognize --with-newlib/--without-newlib.
case ${with_newlib} in
- no) skipdirs="${skipdirs} target-newlib" ;;
+ no) skipdirs="${skipdirs} target-newlib target-libgloss" ;;
yes) skipdirs=`echo " ${skipdirs} " | sed -e 's/ target-newlib / /'` ;;
esac
Index: configure
===
--- configure (revision 179288)
+++ configure (working copy)
@@ -2823,7 +2823,7 @@
# Recognize --with-newlib/--without-newlib.
case ${with_newlib} in
- no) skipdirs="${skipdirs} target-newlib" ;;
+ no) skipdirs="${skipdirs} target-newlib target-libgloss" ;;
yes) skipdirs=`echo " ${skipdirs} " | sed -e 's/ target-newlib / /'` ;;
esac
[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #2 from Paolo Carlini 2011-09-28 21:28:34 UTC --- In the C++11 times I don't think we are going to work on this .. Are we?
[Bug fortran/50553] statement function cannot be target (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553 --- Comment #2 from janus at gcc dot gnu.org 2011-09-28 21:28:59 UTC --- The patch regtests cleanly. I'm going to commit as obvious.
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |daniel.kruegler at ||googlemail dot com --- Comment #7 from Paolo Carlini 2011-09-28 21:31:35 UTC --- What happened to issue Core/983?
[Bug c++/41431] &main should be allowed within unevaluated operands.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41431 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #1 from Paolo Carlini 2011-09-28 21:34:31 UTC --- Fixed in 4.5.x or even earlier.
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 --- Comment #8 from Daniel Krügler 2011-09-28 21:36:53 UTC --- (In reply to comment #7) > What happened to issue Core/983? It was originally accepted but later found out to be the wrong solution, therefore it became fixed again by CWG 1121.
[Bug fortran/50547] dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547 --- Comment #2 from janus at gcc dot gnu.org 2011-09-28 21:40:30 UTC --- This patch causes one testsuite failure on elemental_args_check_2.f90, due to a slightly changed error message.
[Bug bootstrap/49486] [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49486 --- Comment #2 from Kazumoto Kojima 2011-09-28 21:43:06 UTC --- Author: kkojima Date: Wed Sep 28 21:43:01 2011 New Revision: 179320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179320 Log: PR target/49486 * config/sh/sh.md (negdi2): Move expansion into split to allow more combination options. Add T_REG clobber. (abssi2): New expander. (*negdi2, *abssi2, *negabssi2): New insns. (cneg): Change from insn to insn_and_split. Rename to negsi_cond. Add alternative for non-SH4. * gcc.target/sh/pr49468-si.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr49468-si.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 --- Comment #9 from Paolo Carlini 2011-09-28 21:48:08 UTC --- Excellent, then could you possibly comment on the implication for this PR? (for you it's easy, I'm sure)
[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40056 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||WORKSFORME --- Comment #4 from Paolo Carlini 2011-09-28 21:52:27 UTC --- In any case, 'W' with current 4.5.x, 4.6.x and mainline.
[Bug c++/38980] missing -Wformat warning on const char format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38980 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2011-09-28 21:58:03 UTC --- Jakub, can you have a look to this?
[Bug c++/45278] -Wextra doesn't warn about (pointer < 0 ).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45278 --- Comment #3 from paolo at gcc dot gnu.org 2011-09-28 22:04:51 UTC --- Author: paolo Date: Wed Sep 28 22:04:48 2011 New Revision: 179321 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179321 Log: /cp 2011-09-28 Paolo Carlini PR c++/45278 * typeck.c (cp_build_binary_op): With -Wextra, warn for ordered comparison of pointer with zero. /testsuite 2011-09-28 Paolo Carlini PR c++/45278 * g++.dg/warn/Wextra-3.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wextra-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/45278] -Wextra doesn't warn about (pointer < 0 ).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45278 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Paolo Carlini 2011-09-28 22:05:55 UTC --- Fixed for 4.7.0.
