[Bug target/46353] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46353 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.08 08:09:05 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-11-08 08:09:05 UTC --- __builtin_fma is now emitted as FMA_EXPR. BTW: -ffp-contract=off didn't help to prevent this transformation.
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352 --- Comment #18 from Andrey Belevantsev abel at gcc dot gnu.org 2010-11-08 08:11:43 UTC --- Author: abel Date: Mon Nov 8 08:11:38 2010 New Revision: 166429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166429 Log: PR rtl-optimization/45352 * sel-sched.c (find_best_expr): Do not set pneed_stall when the variable_issue hook is not implemented. (fill_insns): Remove dead variable stall_iterations. (init_seqno_1): Force EBB start for resetting sched cycles on any successor blocks of the rescheduled region. (sel_sched_region_1): Use bitmap_bit_p instead of bitmap_clear_bit. (reset_sched_cycles_in_current_ebb): Add debug printing. New variable issued_insns. Advance state when we have issued issue_rate insns. gcc.dg/pr45352.c, gcc.dg/pr45352-1.c, gcc.dg/pr45352-2.c: New tests. gcc.target/i386/pr45352.c, gcc.target/i386/pr45352-1.c, gcc.target/i386/pr45352-2.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/pr45352-1.c trunk/gcc/testsuite/gcc.dg/pr45352-2.c trunk/gcc/testsuite/gcc.dg/pr45352.c trunk/gcc/testsuite/gcc.target/i386/pr45352-1.c trunk/gcc/testsuite/gcc.target/i386/pr45352-2.c trunk/gcc/testsuite/gcc.target/i386/pr45352.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog
[Bug target/46353] [4.6 regression] fma testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46353 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2010-11-08 08:13:40 UTC --- (In reply to comment #1) __builtin_fma is now emitted as FMA_EXPR. Oops, this comment was intended for problems with [1] FAIL: gcc.dg/torture/builtin-math-2.c -O0 scan-tree-dump-times original fma 3 [1] http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00594.html
[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46316
--- Comment #16 from davidxl xinliangli at gmail dot com 2010-11-08 08:18:31
UTC ---
The revised patch:
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c(revision 166426)
+++ gcc/tree-vrp.c(working copy)
@@ -3403,13 +3403,18 @@ adjust_range_with_scev (value_range_t *v
{
value_range_t maxvr = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
double_int dtmp;
- dtmp = double_int_mul (tree_to_double_int (step),
- double_int_sub (loop-nb_iterations_upper_bound,
- double_int_one));
+ bool unsigned_p = TYPE_UNSIGNED (TREE_TYPE (step));
+ int overflow = 0;
+
+ dtmp = double_int_mul_with_sign (tree_to_double_int (step),
+ double_int_sub (
+ loop-nb_iterations_upper_bound,
+ double_int_one),
+ unsigned_p, overflow);
tem = double_int_to_tree (TREE_TYPE (init), dtmp);
/* If the multiplication overflowed we can't do a meaningful
adjustment. */
- if (double_int_equal_p (dtmp, tree_to_double_int (tem)))
+ if (!overflow double_int_equal_p (dtmp, tree_to_double_int (tem)))
{
extract_range_from_binary_expr (maxvr, PLUS_EXPR,
TREE_TYPE (init), init, tem);
Index: gcc/double-int.c
===
--- gcc/double-int.c(revision 166426)
+++ gcc/double-int.c(working copy)
@@ -718,6 +718,19 @@ double_int_mul (double_int a, double_int
return ret;
}
+/* Returns A * B. If the operation overflows according to UNSIGNED_P,
+ *OVERFLOW is set to nonzero. */
+
+double_int
+double_int_mul_with_sign (double_int a, double_int b,
+ bool unsigned_p, int *overflow)
+{
+ double_int ret;
+ *overflow = mul_double_with_sign (a.low, a.high, b.low, b.high,
+ret.low, ret.high, unsigned_p);
+ return ret;
+}
+
/* Returns A + B. */
double_int
Index: gcc/double-int.h
===
--- gcc/double-int.h(revision 166426)
+++ gcc/double-int.h(working copy)
@@ -132,6 +132,7 @@ double_int_fits_in_uhwi_p (double_int cs
2 * HOST_BITS_PER_WIDE_INT bits. */
double_int double_int_mul (double_int, double_int);
+double_int double_int_mul_with_sign (double_int, double_int, bool, int *);
double_int double_int_add (double_int, double_int);
double_int double_int_sub (double_int, double_int);
double_int double_int_neg (double_int);
[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 08:24:22 UTC --- I don't think this is a P1, the warning is reported, just with differing locus.
[Bug fortran/46356] [OOP] Erroneous procedure/intent error and ICE for class dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46356 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2010.11.08 08:31:03 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Erroneous procedure/intent |[OOP] Erroneous |error and ICE for class |procedure/intent error and |dummy argument |ICE for class dummy ||argument --- Comment #1 from janus at gcc dot gnu.org 2010-11-08 08:31:03 UTC --- (In reply to comment #0) The following example, when compiled with gfortran 4.6 built from trunk source 166232 (20101103), rejects the following code with a dubious errror (PROCEDURE attribute conflicts with INTENT attribute in 'pvec') before the compiler dies with an ICE. Confirmed. Thanks for reporting.
[Bug tree-optimization/45971] [4.6 Regression] ice in vect_update_ivs_after_vectorizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45971
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08
08:43:51 UTC ---
Slightly more reduced testcase:
void
foo (int *x, int *y)
{
int i;
for (i = 0; i 11; i++)
y[i] = (x[i] == 1) ? i + 1 : -(i + 1);
}
The following:
void
bar (int *x, int *y)
{
int i;
for (i = 0; i 64; i++)
y[i] = (x[i] == 1) ? i + 1 : -(i + 1);
}
ICEs with
internal compiler error: in get_initial_def_for_induction, at
tree-vect-loop.c:2659
instead.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #10 from janus at gcc dot gnu.org 2010-11-08 09:04:03 UTC --- Author: janus Date: Mon Nov 8 09:03:50 2010 New Revision: 166430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166430 Log: 2010-11-08 Janus Weil ja...@gcc.gnu.org PR fortran/46344 * trans-types.c (gfc_copy_dt_decls_ifequal): Handle CLASS components. 2010-11-08 Janus Weil ja...@gcc.gnu.org PR fortran/46344 * gfortran.dg/class_28.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_28.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #11 from janus at gcc dot gnu.org 2010-11-08 09:20:48 UTC --- r166430 fixes the test cases in comment #0 and #4 and the one in PR 46345. However, the problem in comment #5 persists. Reduced test case: module m type t1 end type type t2 class(t1), allocatable :: c end type type(t1) :: w end module m end module m 1 Internal Error at (1): write_symbol(): bad module symbol 'w' The error seems to be sensitive to the first letter of the type(t1) variable. All names starting with 'w'-'z' fail, others seem to work. Also the error disappears when adding implicit none, so it seems to be connected to implicit typing.
[Bug bootstrap/46358] New: i686-pc-linux-gnu bootstrap failure in r166429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46358 Summary: i686-pc-linux-gnu bootstrap failure in r166429 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org ../../gcc/gcc/config/i386/i386.c: In function ‘ix86_expand_split_stack_prologue’: ../../gcc/gcc/config/i386/i386.c:11174:4: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] ../../gcc/gcc/config/i386/i386.c:11175:4: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] ../../gcc/gcc/config/i386/i386.c:11205:4: error: left shift count = width of type [-Werror] cc1: all warnings being treated as errors make[3]: *** [i386.o] Error 1
[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-08 09:30:11 UTC --- (In reply to comment #11) Last patch: http://gcc.gnu.org/ml/fortran/2010-11/msg00052.html Review comments by Ian Taylor were: * More macros now refer to magic variables which must be in scope when the macro is used, namely pfile and iso. * Code in the generic backend is now calling cpp_define, which is in libcpp. This was not the case before. It does not seem appropriate for languages like Java and Ada which do not use the C preprocessor at all.
[Bug fortran/46356] [OOP] Erroneous procedure/intent error and ICE for class dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46356 --- Comment #2 from janus at gcc dot gnu.org 2010-11-08 09:32:26 UTC --- Reduced test case: IMPLICIT NONE TYPE :: ParentVector INTEGER :: a END TYPE ParentVector CONTAINS SUBROUTINE vector_operation(pvec) CLASS(ParentVector), INTENT(INOUT) :: pvec(:) print *,pvec(1)%a END SUBROUTINE END Note: This error is due to the fact that gfortran currently does not really support CLASS arrays (which hopefully will change soon).
[Bug bootstrap/46358] i686-pc-linux-gnu bootstrap failure in r166429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46358 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Target||i686-pc-linux-gnu CC||iant at google dot com --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-11-08 09:32:18 UTC --- The first two warnings are because allocate is HOST_WIDE_INT, 32 bit signed, and 0x is unsigned. The third is a shift of a 32 bit value by 32. It appears these were introduced in r166427: 2010-11-07 Ian Lance Taylor i...@google.com PR target/46089 * config/i386/i386.c (split_stack_fn_large): New static variable. (ix86_expand_split_stack_prologue): Handle large model.
[Bug middle-end/44206] [4.6 Regression] ICE: Inline clone with address taken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44206 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 10:09:10 UTC --- Fixed.
[Bug c++/46170] [4.4/4.5/4.6 Regression] g++ wrongly rejects pointer-to-member in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46170 --- Comment #21 from Dodji Seketeli dodji at gcc dot gnu.org 2010-11-08 10:16:19 UTC --- jason at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org writes: --- Comment #19 from Jason Merrill jason at gcc dot gnu.org 2010-11-02 16:36:01 UTC --- I think we can avoid the extra patch for 4.4 by just removing the code that changes c_inhibit_evaluation_warnings; let's do that. If we do that then the test template/sfinae25.C accompanying the patch fails by emitting the warning: sfinae25.C:12: warning: division by zero I suppose this is precisely what the code changing c_inhibit_evaluation_warnings in tsubst_template_arg was meant to address, isn't it?
[Bug c++/46156] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11370 with -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46156 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 10:35:27 UTC --- And apparently went away in http://gcc.gnu.org/viewcvs?root=gccview=revrev=166167 Guess we just want to add the testcase into the testsuite, unless the r166167 change would only make this issue latent.
[Bug bootstrap/46358] [4.6 Regression] i686-pc-linux-gnu bootstrap failure in r166429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46358 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.6.0 Summary|i686-pc-linux-gnu bootstrap |[4.6 Regression] |failure in r166429 |i686-pc-linux-gnu bootstrap ||failure in r166429
[Bug target/46357] Unnecessary movzx instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46357 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 10:44:31 UTC --- We always use zero/sign-extending moves to avoid partial register stalls.
[Bug tree-optimization/46355] [4.5/4.6 Regression] ICE: SIGSEGV in create_preheader (cfgloopmanip.c:1336) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46355 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.5.2 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 10:45:56 UTC --- Mine.
[Bug target/28627] [cygwin/mingw32] Missing dllimport diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28627 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2010-11-08 10:49:44 UTC --- Author: ktietz Date: Mon Nov 8 10:49:38 2010 New Revision: 166431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166431 Log: 2010-11-08 Kai Tietz kai.ti...@onevision.com PR target/28627 * g++.dg/ext/dllimport7.C: Adjust second error check and allow test for x86_64 mingw, too. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/dllimport7.C
[Bug c++/46156] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11370 with -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46156 --- Comment #4 from Marc Glisse marc.glisse at normalesup dot org 2010-11-08 11:01:03 UTC --- (In reply to comment #3) And apparently went away in http://gcc.gnu.org/viewcvs?root=gccview=revrev=166167 Guess we just want to add the testcase into the testsuite, unless the r166167 change would only make this issue latent. Our testsuite shows: internal compiler error: in tsubst_copy, at cp/pt.c:11677 for some code with a compiler from 11/05. I am already trying to reduce another bug, but if you think it is necessary I may look at producing another reduced testcase later.
[Bug c++/45399] [C++0x] Warning for \0 in raw strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45399 --- Comment #2 from Kay Hayen kayhayen at gmx dot de 2010-11-08 11:03:31 UTC --- Created attachment 22319 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22319 Warning for \0 in raw strings test case Well, here it is. Use like this: g++ -c -std=c++0x raw.c++ Best regards, Kay Hayen
[Bug libstdc++/46359] New: [4.6 Regression] symbol missing from 4.6 libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46359 Summary: [4.6 Regression] symbol missing from 4.6 libstdc++ Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org When dynamically linking against current trunk libstdc++ on ppc[64]-linux or s390x-linux a ppl library linked against gcc-4.5 branch libstdc++ I get /usr/lib/libstdc++.so.6: undefined reference to `std::ostreambuf_iteratorchar, std::char_traitschar std::num_putchar, std::ostreambuf_iteratorchar, std:: char_traitschar ::_M_insert_floatlong double(std::ostreambuf_iteratorcha r, std::char_traitschar , std::ios_base, char, char, long double) const' collect2: ld returned 1 exit status make[3]: *** [lto1] Error 1 when linking lto1 (or cc1 or whatever).
[Bug libstdc++/46359] [4.6 Regression] symbol missing from 4.6 libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46359 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64-*-linux, ||powerpc-*-linux, ||s390x-*-linux Target Milestone|--- |4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 11:09:30 UTC --- It works ok on x86_64, i586 and ia64.
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08
11:11:56 UTC ---
Smaller testcase:
b.f90:
module pr43808
type :: a
integer, allocatable :: i(:)
end type a
type :: b
type (a), allocatable :: at(:)
end type b
contains
subroutine foo(y)
type(b) :: y(2)
forall (j=1:2,k=1:4, y(1)%at(j)%i(k) .ne. y(2)%at(j)%i(k))
y(1)%at(j)%i(k) = 999
end subroutine foo
end module pr43808
c.f90:
use pr43808
type(a) :: x(2)
type(b) :: y(2)
x(1) = a((/1,2,3,4/))
x(2) = a((/1,2,3,4/)+10)
y(1) = b((/x(1),x(2)/))
y(2) = b((/x(1),x(2)/))
call foo(y)
end
./f951 -quiet -g b.f90; ./f951 -quiet -g -fipa-reference -fschedule-insns
-fno-schedule-insns2 -fstrict-aliasing -fverbose-asm c.f90; gfortran -o b{,.s}
c.s; ./b; echo $?
Segmentation fault (core dumped)
139
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 11:27:33 UTC --- As usual this might be as well a type-merging problem in the Frontend.
[Bug libstdc++/46359] [4.6 Regression] symbol missing from 4.6 libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46359 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-08 11:37:21 UTC --- is this Bug 46221 ?
[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333 --- Comment #19 from Jay jay.krell at cornell dot edu 2010-11-08 11:50:35 UTC --- Hey, g++ 4.0 doesn't even like all of the code. You have to try all targets to uncover some of it. target=alpha-dec-vms: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -W missing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc -I../../g cc-4.5/gcc/. -I../../gcc-4.5/gcc/../include -I../../gcc-4.5/gcc/../libcpp/includ e -I/Users/jay/dev2/cm3/m3-sys/m3cc/AMD64_DARWIN-ALPHA32_VMS/./gmp -I/Users/jay/ dev2/cm3/m3-sys/m3cc/gcc-4.5/gmp ../../gcc-4.5/gcc/vmsdbgout.c -o vmsdbgout .o ../../gcc-4.5/gcc/vmsdbgout.c:1944: error: integer constant is too large for 'lo ng' type ../../gcc-4.5/gcc/vmsdbgout.c: In function 'int write_modbeg(int)': ../../gcc-4.5/gcc/vmsdbgout.c:746: error: invalid conversion from 'unsigned int' to 'DST_LANGUAGE' ../../gcc-4.5/gcc/vmsdbgout.c: In function 'int write_rtnbeg(int, int)': ../../gcc-4.5/gcc/vmsdbgout.c:825: error: invalid conversion from 'int' to '_DST _TYPE' make: *** [vmsdbgout.o] Error 1 jbook2:python jay$ g++ -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enabl e-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/includ e/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5493)
[Bug libstdc++/46359] [4.6 Regression] symbol missing from 4.6 libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46359 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 11:54:21 UTC --- It looks like so. *** This bug has been marked as a duplicate of bug 46221 ***
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 11:54:21 UTC --- *** Bug 46359 has been marked as a duplicate of this bug. ***
[Bug bootstrap/46358] [4.6 Regression] i686-pc-linux-gnu bootstrap failure in r166429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46358 --- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-11-08 11:56:09 UTC --- Created attachment 22320 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22320 List of unexpected failures
[Bug bootstrap/46358] [4.6 Regression] i686-pc-linux-gnu bootstrap failure in r166429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46358 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Priority|P1 |P3 URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-11/msg00720.htm ||l Target Milestone|4.6.0 |--- --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-11-08 11:57:56 UTC --- bootstrap finished successfully with the patch. No unexpected libstdc++-v3 failures. Unexpected failures for C / C++ are pretty much what they were last week - See attachment.
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 12:03:23 UTC --- I will investigate this a bit now.
[Bug middle-end/46360] New: [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46360 Summary: [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Created attachment 22321 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22321 preprocessed source The package ebook-tools fails to build with /usr/bin/gcc -Depub_EXPORTS -Wall -W -Wno-long-long -Wundef -Wcast-align -Werror-implicit-function-declaration -Wchar-subscripts -Wpointer-arith -Wwrite-strings -Wformat-security -Wmissing-format-attribute -Wshadow -fno-common -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIC -I/usr/src/packages/BUILD/ebook-tools-0.2.0/src/libepub -I/usr/include/libxml2 -o CMakeFiles/epub.dir/epub.o -c /usr/src/packages/BUILD/ebook-tools-0.2.0/src/libepub/epub.c /usr/src/packages/BUILD/ebook-tools-0.2.0/src/libepub/epub.c: In function 'epub_open': /usr/src/packages/BUILD/ebook-tools-0.2.0/src/libepub/epub.c:19:3: internal compiler error: in release_defs, at tree-ssanames.c:313 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. and the cause is -Wwrite-strings as the attached testcase shows ./cc1 -quiet ~/epub.i -m32 -Wwrite-strings /usr/src/packages/BUILD/ebook-tools-0.2.0/src/libepub/epub.c: In function 'epub_open': /usr/src/packages/BUILD/ebook-tools-0.2.0/src/libepub/epub.c:19:15: internal compiler error: in release_defs, at tree-ssanames.c:313 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/46208] redundant extensions of argument registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46208 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-08 12:15:02 UTC --- Author: ebotcazou Date: Mon Nov 8 12:14:51 2010 New Revision: 166433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166433 Log: PR target/46208 * config/sparc/sparc.c (TARGET_PROMOTE_PROTOTYPES): Delete. (sparc_promote_prototypes): Likewise. (sparc_promote_function_mode): Promote in 32-bit mode as well. (sparc_return_in_memory): Remove superfluous parentheses. (sparc_struct_value_rtx): Fix long lines. (sparc_function_value_1): Promote in 32-bit mode as well. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c
[Bug middle-end/46360] [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46360 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Target Milestone|--- |4.6.0
[Bug bootstrap/46358] [4.6 Regression] i686-pc-linux-gnu bootstrap failure in r166429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46358 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.6.0
[Bug c++/45399] [C++0x] Warning for \0 in raw strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45399 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-08 12:19:12 UTC --- The null character is not part of the basic source character set, so it's implementation-defined how a null in the source file is translated - so arguably a warning is appropriate. I tend to agree it's not necessarily useful for raw strings. (In reply to comment #0) Also please consider it a bug. What else is the purpose of raw strings other than to contain binary blobs? There are lots of uses other than binary data, e.g. writing regular expressions without needing to escape every backslash.
[Bug c++/45399] [C++0x] Warning for \0 in raw strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45399 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-08 12:26:16 UTC --- The motivating examples in the original raw strings proposal are for simplifying regular expressions and HTML markup, there's no mention of binary blobs. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2053.html
[Bug web/46361] New: bugzilla: mid-air collision message is misleading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46361 Summary: bugzilla: mid-air collision message is misleading Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org For PR46358, I added the keyword patch, the patch URL, and a comment, and then proceded to add en attachment. Instead of handling the attachement addition as part of the transaction, it was done separately. I then went back to the page where I added keyword, URL and comment, to commit these changes. I then got a mid-air collision warning, but it said that the other changes were: no changes have been made. I thought that this was a weird way to refer to my adding of the attachment, and as re-doing that is less work then the keyword/URL/comment, I went ahead with the change submission. It turned out later that the attachment was still fine, but I had overridden the changes that Richard Guenther had made earlier.
[Bug bootstrap/46362] New: [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46362 Summary: [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: dave.k...@gcc.gnu.org, i...@google.com Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 Since the lto-plugin has been converted to the simple-object interface and is always enabled on ELF targets, mainline doesn't bootstrap any longer on IRIX 6.5: /vol/gcc/src/hg/trunk/local/lto-plugin/lto-plugin.c: In function 'claim_file_handler': /vol/gcc/src/hg/trunk/local/lto-plugin/lto-plugin.c:829: error: expected ')' before 'PRIx64' cc1: warnings being treated as errors /vol/gcc/src/hg/trunk/local/lto-plugin/lto-plugin.c:830: error: too few arguments for format make[3]: *** [lto-plugin.lo] Error 1 make[3]: Leaving directory `/var/gcc/regression/trunk/6.5-gcc/build/lto-plugin' The problem is this piece of code: int t = asprintf (objname, %...@0x% PRIx64, file-name, (int64_t) file-offset); IRIX 6.5 only defines PRIx64 in inttypes.h inside __c99. Unless we compile the lto-plugin in C99 mode (which isn't guaranteed to be available in the bootstrap compiler), this won't work. Besides, the plugin is useless on IRIX 6.5 anyway since neither gold nor gld work (cf. PR target/43533).
[Bug web/46363] New: [bugzilla] WAITING state confirms bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46363 Summary: [bugzilla] WAITING state confirms bug Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Changing Status to WAITING causes the bug to be confirmed, as can be seen by the first two changes in http://gcc.gnu.org/bugzilla/show_activity.cgi?id=45399 I expect WAITING state to be independent of whether it's been confirmed, so that the sequence UNCONFIRMED-WAITING-UNCONFIRMED doesn't affect whether the bug has been confirmed.
[Bug target/46191] [4.5/4.6 regression] Non-absolute names in libgcc_s.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46191 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|WAITING |NEW
[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333 --- Comment #20 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-08 13:12:11 UTC --- There really is absolutely no point experimenting with this option anywhere other than on trunk. Maybe we should just disable it on 4.5 branch; it's a GCC-developer-only option at this point. *Many* problems with C++ compatibility have been fixed on trunk since 4.5 branched. See Joern's work on fixing problems building different targets with --enable-werror-always (many of the problems fixed are C++ compatibility warnings). No such fixes will be backported to 4.5 branch. Since we're now in development stage 3, I expect that the default build will not be C++ until after 4.6 branches, which means that C++ fixes will not be backported to 4.6 branch either once that branch is created. Bug reports and fixes for such issues are only useful for trunk, and they are only useful when each separate problem (each problem with a genuinely different cause) is reported as a separate well-defined bug report; omnibus issues mixing different problems are useless, although meta-bugs marked as depending on the individual C++-compatibility bugs can be useful. As it happens we have such a bug: bug 44433. So when you have a well-defined issue verified to exist on trunk and to be distinct from all existing bugs, only then file a separate bug for that issue and mark it as blocking bug 44433.
[Bug c++/46364] New: basic_string.h:541:32: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46364
Summary: basic_string.h:541:32: internal compiler error:
Segmentation fault
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kir...@shutemov.name
Created attachment 22322
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22322
preprocessed source
$ cat test.cc
#include string
void a() throw (int);
void b(std::string const );
void c(std::string *e)
{
b();
try {
a();
} catch (...) {
*e = ;
}
}
void d() {
c(0);
}
$ g++ -c -O3 test.cc
In file included from
/usr/lib/gcc/i586-alt-linux/4.5.1/../../../../include/c++/4.5.1/string:53:0,
from test.cc:1:
/usr/lib/gcc/i586-alt-linux/4.5.1/../../../../include/c++/4.5.1/bits/basic_string.h:
In function ‘void c(std::string*)’:
/usr/lib/gcc/i586-alt-linux/4.5.1/../../../../include/c++/4.5.1/bits/basic_string.h:541:32:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.altlinux.org for instructions.
Preprocessed source stored into /tmp/.private/kas/cc9BCz1h.out file, please
attach this to your bugreport.
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 13:32:24 UTC --- The first issue I see is that we reclaim the cgraph nodes that constitute aliases (even though they are TREE_PUBLIC): Reclaiming functions: wobbly jelly The 2nd issue is that in remove_unreachable_alias_pairs we remove pairs for decls that are !DECL_EXTERNAL (huh, I supposed that's to be for _targets_ that are not external!). As we have reclaimed jelly, the target for wobbly isn't available and thus we remove the alias. Now, alias-pairs are indeed a complete mess and need to be re-done properly integrated with cgraph/varpool and ipa-references. I have a ha^Wpatch that makes us emit instead ./cc1 -quiet t.c -O -fdump-ipa-all-details t.c:4:13: error: 'wobbly' aliased to undefined symbol 'jelly' haha, because find_decl_and_mark_needed is stupid as well. Bah. We really need to avoid throwing away the cgraph node. But the cgraph code is messy^2 as well. Bah. I have a pa^Whack.
[Bug c++/45383] [4.5/4.6 Regression] Implicit conversion to pointer does no longer automatically generate operator== and operator!=.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45383 Simon number.cruncher at ntlworld dot com changed: What|Removed |Added CC||number.cruncher at ntlworld ||dot com --- Comment #3 from Simon number.cruncher at ntlworld dot com 2010-11-08 13:46:44 UTC --- I'd just like to confirm this bug on Fedora 14 (gcc (GCC) 4.5.1 20100924) which is currently preventing me from compiling a large 3D graphics commercial library.
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug bootstrap/46365] New: [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46365 Summary: [4.6 Regression] Failed to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 166427 gave ../../src-trunk/gcc/config/i386/i386.c: In function 'ix86_expand_split_stack_prologue': ../../src-trunk/gcc/config/i386/i386.c:11174:4: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] ../../src-trunk/gcc/config/i386/i386.c:11175:4: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] ../../src-trunk/gcc/config/i386/i386.c:11205:4: error: left shift count = width of type [-Werror] cc1: all warnings being treated as errors make[6]: *** [i386.o] Error 1 Revision 166420 is OK.
[Bug bootstrap/46365] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46365 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.08 14:11:46 CC||iant at google dot com Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 14:11:46 UTC --- It is caused by revision 166427: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00314.html
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 14:18:29 UTC --- Created attachment 22323 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22323 patch Patch. Testing on x86_64-linux, testing elsewhere is appreciated.
[Bug rtl-optimization/46366] New: gcc.target/i386/pr45352-2.c failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46366 Summary: gcc.target/i386/pr45352-2.c failed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: a...@gcc.gnu.org On Linux/x86-64, I got FAIL: gcc.target/i386/pr45352-2.c (test for excess errors)
[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45894 --- Comment #5 from Dodji Seketeli dodji at gcc dot gnu.org 2010-11-08 14:27:46 UTC --- I think the example is invalid in c++ 2003 as [temp.param/9] says that a function template shall not have any default template argument. It's valid in c++0x though as that rule has been relaxed. FWIW, Trying the code with without -Wall and with c++0x is accepted by current trunk. -Wall with -std=c++0x crashes it too. Without -Wall and without -std=c++0x the code is rejected by trunk. The crash happens while looking at the expression FOO::BAR because we want to emit warnings about variables access in undefined sequencing conditions. For that finish_expr_stmt passes the expression FOO::Bar (represented as the BASELINK Jakub referred to), to verify_sequence_points which at some point tries to see if the TEMPLATE_ID_EXPR representing FOO::BAR is an lvalue. Then lvalue_kind crashes because it doesn't expect a tree without a TYPE [TEMPLATE_ID_EXPR doesn't have a type] as Jakub noted. I think the fix looks correct (assuming it passes regtests), as it 1/robustifies lvalue_kind 2/makes it return clk_none and IMHO rightfully so as we can't say at this point if the TEMPLATE_ID_EXPR (which is just a syntactic representation) is an lvalue or not. To be able to decide on the lvalueness we'd need something more typed at this point, I suppose.
[Bug bootstrap/46365] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46365 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 14:28:23 UTC --- Dup. *** This bug has been marked as a duplicate of bug 46358 ***
[Bug bootstrap/46358] [4.6 Regression] i686-pc-linux-gnu bootstrap failure in r166429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46358 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 14:28:23 UTC --- *** Bug 46365 has been marked as a duplicate of this bug. ***
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 --- Comment #14 from Peter Bergner bergner at gcc dot gnu.org 2010-11-08 14:36:32 UTC --- I'll give it a spin on powerpc64-linux.
[Bug tree-optimization/46367] New: [4.6 Regression] ICE during cgraph edge cloning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367 Summary: [4.6 Regression] ICE during cgraph edge cloning Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org The package xbase fails to build with g++ -DHAVE_CONFIG_H -I. -I/usr/src/packages/BUILD/xbase-2.0.0 -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -MT expproc.lo -MD -MP -MF .deps/expproc.Tpo -c expproc.cpp -fPIC -DPIC -o .libs/expproc.o g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. Where on the preprocessed source you can see that -O -m32 is enough: ./cc1plus -quiet -O ~/expproc.ii -o /dev/null -m32 Segmentation fault (gdb) bt #0 0x00a6d01d in gimple_statement_structure (gs=Cannot access memory at address 0x7f7feff8 ) at /space/rguenther/src/svn/trunk/gcc/gimple.h:1110 #1 0x00a6cfe2 in gimple_ops (gs=0x74cec500) at /space/rguenther/src/svn/trunk/gcc/gimple.h:1655 #2 0x00a71ec8 in gimple_op (gs=0x74cec500, i=1) at /space/rguenther/src/svn/trunk/gcc/gimple.h:1670 #3 0x00a74497 in gimple_call_fn (gs=0x74cec500) at /space/rguenther/src/svn/trunk/gcc/gimple.h:2001 #4 0x00a73f95 in gimple_call_fndecl (gs=0x74cec500) at /space/rguenther/src/svn/trunk/gcc/gimple.h:2043 #5 0x00a73eef in gimple_call_flags (stmt=0x74cec500) at /space/rguenther/src/svn/trunk/gcc/gimple.c:1781 #6 0x00cc0f32 in gimple_call_nothrow_p (s=0x74cec500) at /space/rguenther/src/svn/trunk/gcc/gimple.h:2302 #7 0x00cc0e7f in stmt_could_throw_p (stmt=0x74cec500) at /space/rguenther/src/svn/trunk/gcc/tree-eh.c:2530 #8 0x00cc124b in stmt_can_throw_external (stmt=0x74cec500) at /space/rguenther/src/svn/trunk/gcc/tree-eh.c:2581 #9 0x00f747b8 in cgraph_create_edge_1 (caller=0x7fffef5bb580, callee=0x74ce4c60, call_stmt=0x74cec500, count=0, freq=0, nest=65505) at /space/rguenther/src/svn/trunk/gcc/cgraph.c:1021 #10 0x00f748cc in cgraph_create_edge (caller=0x7fffef5bb580, callee=0x74ce4c60, call_stmt=0x74cec500, count=0, freq=0, nest=65505) at /space/rguenther/src/svn/trunk/gcc/cgraph.c:1042 #11 0x00f774c8 in cgraph_clone_edge (e=0x7fffef5bab60, n=0x7fffef5bb580, call_stmt=0x74cec500, stmt_uid=0, count_scale=0, freq_scale=1, loop_nest=27584, update_original=0 '\000') at /space/rguenther/src/svn/trunk/gcc/cgraph.c:2102 #12 0x00f778b6 in cgraph_clone_node (n=0x7fffef5bb2c0, decl=0x74ef4c00, count=0, freq=0, loop_nest=27584, update_original=0 '\000', redirect_callers=0x0) at /space/rguenther/src/svn/trunk/gcc/cgraph.c:2179 #13 0x00f8ff28 in cgraph_clone_inlined_nodes (e=0x7fffef5babc8, duplicate=1 '\001', update_original=0 '\000') at /space/rguenther/src/svn/trunk/gcc/ipa-inline.c:283 #14 0x00f9004f in cgraph_clone_inlined_nodes (e=0x7fffef5babc8, duplicate=1 '\001', update_original=0 '\000') at /space/rguenther/src/svn/trunk/gcc/ipa-inline.c:306 #15 0x00f9004f in cgraph_clone_inlined_nodes (e=0x7fffef5ba888, duplicate=1 '\001', update_original=0 '\000') ... appearantly the call stmt is invalid.
[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||i?86-*-linux Target Milestone|--- |4.6.0
[Bug fortran/46344] [4.6 Regression] [OOP] ICE with allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46344 --- Comment #12 from janus at gcc dot gnu.org 2010-11-08 14:39:01 UTC --- (In reply to comment #11) The error seems to be sensitive to the first letter of the type(t1) variable. All names starting with 'w'-'z' fail, others seem to work. Also the error disappears when adding implicit none, so it seems to be connected to implicit typing. After some more research I came to the conclusion that it's rather a resolution problem: Sometimes symbols for class containers and vtabs are generated at resolution stage. If this happens while traversing a namespace's symbol tree, symbols are being added and the tree is rearranged, so that the traversing routine may miss some symbols! This is also the reason why this error occurs so randomly: It depends on how the tree is being rearranged and whether we're lucky enough to still resolve all symbols!
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08
14:39:51 UTC ---
The problem seems to be that on the c.f90:
...
D.1548.i.data = 0B;
atmp.7.dtype = 3113;
atmp.7.dim[0].stride = 1;
atmp.7.dim[0].lbound = 0;
atmp.7.dim[0].ubound = 1;
D.1691_62 = (void * restrict) A.8[0];
atmp.7.data = D.1691_62;
atmp.7.offset = 0;
D.1692_63 = atmp.7.data;
MEM[(struct a[2] *)D.1692_63][0] = x[0];
D.1693_64 = atmp.7.data;
MEM[(struct a[2] *)D.1693_64][1] = x[1];
Partition 10: size 96 align 16
A.8, offset 0
A.20, offset 0
a.0, offset 0
D.1548, offset 0
(thus D.1548 and A.8 share stack slot) and we have in *.asmcons:
// This is D.1548.i.data = 0B;
(insn 250 249 251 18 (set (mem/s/f/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -384 [0xfe80])) [3 D.1548.i.data+0 S8
A64])
(const_int 0 [0])) c.f90:5 62 {*movdi_internal_rex64}
(nil))
...
// This is D.1691_62 = (void * restrict) A.8[0];
(insn 255 254 256 18 (parallel [
(set (reg/f:DI 116 [ D.1691 ])
(plus:DI (reg/f:DI 20 frame)
(const_int -384 [0xfe80])))
(clobber (reg:CC 17 flags))
]) c.f90:6 253 {*adddi_1}
(nil))
// This is atmp.7.data = D.1691_62;
(insn 256 255 257 18 (set (mem/s/f/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -192 [0xff40])) [3 atmp.7.data+0 S8
A64])
(reg/f:DI 116 [ D.1691 ])) c.f90:6 62 {*movdi_internal_rex64}
(nil))
...
// This is D.1692_63 = atmp.7.data;
(insn 258 257 260 18 (set (reg/f:DI 117 [ D.1692 ])
(mem/s/f/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -192 [0xff40])) [3 atmp.7.data+0 S8
A64])) c.f90:6 62 {*movdi_internal_rex64}
(nil))
// These two are start of MEM[(struct a[2] *)D.1692_63][0] = x[0];
(insn 260 258 261 18 (set (reg:DI 332)
(mem/s:DI (symbol_ref:DI (x.1518) [flags 0x2] var_decl
0x7ff967060140 x) [6 x+0 S8 A256])) c.f90:6 62 {*movdi_internal_rex64}
(nil))
(insn 261 260 262 18 (set (mem/s:DI (reg/f:DI 117 [ D.1692 ]) [6 MEM[(struct
a[2] *)D.1692_63]+0 S8 A64])
(reg:DI 332)) c.f90:6 62 {*movdi_internal_rex64}
(nil))
Now sched1 unfortunately schedules insn 250 after insn 261 (and whole bunch of
other insns) and as D.1548 and A.8 share stack space, this means overwriting
first 8 bytes in A.8 with NULL.
This all is with current trunk, ./f951 -quiet -fdump-tree-optimized -g
-fipa-reference -fschedule-insns -fno-schedule-insns2 -fstrict-aliasing
-fverbose-asm c.f90 on x86_64-linux.
D.1548 is:
var_decl 0x71ac9140 D.1548
type record_type 0x71cd69d8 a asm_written BLK
size integer_cst 0x71cccb40 constant 384
unit size integer_cst 0x71cc7dc0 constant 48
align 64 symtab -238246416 alias set 6 canonical type 0x71cd69d8
fields field_decl 0x71cd85f0 i type record_type 0x71cd6dc8
array1_integer(kind=4)
BLK file c.f90 line 1 col 0 size integer_cst 0x71cccb40 384
unit size integer_cst 0x71cc7dc0 48
align 64 offset_align 128
offset integer_cst 0x71bdb438 constant 0
bit offset integer_cst 0x71bdbb40 constant 0 context
record_type 0x71cd69d8 a
pointer_to_this pointer_type 0x71abf690 chain type_decl
0x71abd170 D.1516
used ignored BLK file c.f90 line 5 col 0 size integer_cst 0x71cccb40
384 unit size integer_cst 0x71cc7dc0 48
align 64 context function_decl 0x71cd7100 MAIN__
(mem/s/c:BLK (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -384 [0xfe80])) [6 D.1548+0 S48 A64]) chain
var_decl 0x71ac1aa0 a.3
.
In the MEM[(struct a[2] *)D.1692_63][0] = x[0]; stmt LHS is:
array_ref 0x71c14630
type record_type 0x71cd69d8 a asm_written BLK
size integer_cst 0x71cccb40 constant 384
unit size integer_cst 0x71cc7dc0 constant 48
align 64 symtab -238246416 alias set 6 canonical type 0x71cd69d8
fields field_decl 0x71cd85f0 i type record_type 0x71cd6dc8
array1_integer(kind=4)
BLK file c.f90 line 1 col 0 size integer_cst 0x71cccb40 384
unit size integer_cst 0x71cc7dc0 48
align 64 offset_align 128
offset integer_cst 0x71bdb438 constant 0
bit offset integer_cst 0x71bdbb40 constant 0 context
record_type 0x71cd69d8 a
pointer_to_this pointer_type 0x71abf690 chain type_decl
0x71abd170 D.1516
arg 0 mem_ref 0x71adca80
type array_type 0x71ac63f0 type record_type 0x71cd69d8 a
BLK
size integer_cst 0x71cccbb8 constant 768
unit size integer_cst 0x71cc7e38 constant 96
align 64 symtab 0 alias set 6 canonical type 0x71ac63f0 domain
integer_type 0x71abf888
pointer_to_this pointer_type
[Bug middle-end/46368] New: [4.6 Regression] ICE in make_decl_rtl, at varasm.c:1033
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46368 Summary: [4.6 Regression] ICE in make_decl_rtl, at varasm.c:1033 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Target: i?86-*-linux Created attachment 22324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22324 preprocessed source The package yast2-pkg-bindings fails to build with g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/YaST2 -DY2LOG=\Pkg\ -DSUSEVERSION=\\ -DLOCALEDIR=\/usr/share/YaST2/locale\ -fno-inline -Woverloaded-virtual -DZYPP_BASE_LOGGER_LOGGROUP=\Pkg\ -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG -std=gnu++0x -DHAVE_CXX0X -Wall -Wformat=2 -MT Package.lo -MD -MP -MF .deps/Package.Tpo -c Package.cc -fPIC -DPIC -o .libs/Package.o Package.cc: In member function 'YCPValue PkgFunctions::GetPackages(const YCPSymbol, const YCPBoolean)': Package.cc:1489:58: internal compiler error: in make_decl_rtl, at varasm.c:1033 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. where the preprocessed source shows plain -O0 is enough to trigger the bug: ./cc1plus -quiet ~/Package.ii -o /dev/null -m32 -std=gnu++0x Package.cc: In member function 'YCPValue PkgFunctions::GetPackages(const YCPSymbol, const YCPBoolean)': Package.cc:1489:58: internal compiler error: in make_decl_rtl, at varasm.c:1033 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) call debug_tree (decl) var_decl 0x7134a5a0 D.204121 type record_type 0x70123c78 YCPNull type_5 QI size integer_cst 0x77ed34b0 constant 8 unit size integer_cst 0x77ed34d8 constant 1 align 8 symtab 0 alias set -1 canonical type 0x70123c78 fields type_decl 0x70109508 YCPNull type record_type 0x70123d20 YCPNull nonlocal decl_4 VOID file /usr/include/YaST2/ycp/YCPElement.h line 124 col 15 align 1 context record_type 0x70123c78 YCPNull result record_type 0x70123c78 YCPNull context translation_unit_decl 0x77edf958 D.1 full-name class YCPNull X() X(constX) this=(X) n_parents=0 use_template=0 interface-unknown pointer_to_this pointer_type 0x702f4bd0 reference_to_this reference_type 0x702ed150 chain type_decl 0x70111cf0 YCPNull addressable ignored QI file /usr/include/YaST2/ycp/YCPValue.h line 288 col 75 size integer_cst 0x77ed34b0 8 unit size integer_cst 0x77ed34d8 1 align 8 context function_decl 0x7fffeec4e700 PkgCommit chain var_decl 0x7fffee3b2a00 D.230722 (gdb) call debug_gimple_stmt (stmt) D.266801_72 = D.204121;
[Bug middle-end/46368] [4.6 Regression] ICE in make_decl_rtl, at varasm.c:1033
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46368 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug middle-end/46360] [4.6 Regression] ICE in release_defs, at tree-ssanames.c:313
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46360 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.08 14:50:25 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 14:50:25 UTC --- It is caused by revision 164438: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00734.html
[Bug c++/46369] New: [4.6 Regression] ICE: unexpected expression '((unsigned char*)*r)[24]' of kind bit_field_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46369 Summary: [4.6 Regression] ICE: unexpected expression '((unsigned char*)*r)[24]' of kind bit_field_ref Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Target: i?86-*-linux Created attachment 22325 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22325 preprocessed source The package yast2-hardware-detection-2.17.1 fails with ./cc1plus -quiet ~/HwParse.ii -m32 -std=c++0x HwParse.cc: In member function 'YCPMap HwProbe::resource_type2map(const res_any_t*, const char**)': HwParse.cc:219:71: internal compiler error: unexpected expression '((unsigned char*)*r)[24]' of kind bit_field_ref Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/46369] [4.6 Regression] ICE: unexpected expression '((unsigned char*)*r)[24]' of kind bit_field_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46369 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.11.08 14:53:32 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 14:53:32 UTC --- Please provide expproc.ii.
[Bug fortran/46370] New: [OOP] ALLOCATE: Error allocating CLASS coarrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46370 Summary: [OOP] ALLOCATE: Error allocating CLASS coarrays Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Based on the test case at http://j3-fortran.org/doc/meeting/193/10-209r1.txt The following program (compile with -fcoarray=single) is rejected with: allocate (t :: a[*]) 1 Error: Unexpected coarray designator at (1) It works with TYPE instead of CLASS. type t end type t class(t), allocatable :: a[:] allocate (t :: a) end
[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 15:02:02 UTC --- Created attachment 22326 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22326 preprocessed source Hm, it seems initial attachment doesn't work.
[Bug tree-optimization/46367] [4.6 Regression] ICE during cgraph edge cloning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0
[Bug fortran/46371] New: [OOP] SELECT TYPE: scalar coarray variable is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46371 Summary: [OOP] SELECT TYPE: scalar coarray variable is rejected Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: do...@gcc.gnu.org Example has been taken from the interpretation request at http://j3-fortran.org/doc/meeting/193/10-209r1.txt ; the IR does not contain a suggested edits. The following program, which needs two images at run time is regarded as valid (with select 1 commented out) - if the ALLOCATE is not commented out. (The ALLOCATE statement is commented-out because of PR 46370.) Using gfortran -fcorarray=single, it fails with: select type(o_foo)! 3 VALID 1 Error: Selector in SELECT TYPE at (1) is not a named variable; use associate-name= module m type :: foo integer :: i = 0 end type end module m program p use m type(foo), allocatable :: o_foo[:] integer :: j ! allocate(foo :: o_foo[*]) if (this_image() == 1) then !select type(a = o_foo[2])! 1 INVALID ! type is(foo) ! j = a%i !end select !select type(a = o_foo) ! 2 VALID ! type is(foo) ! j = a[2]%i ! end select select type(o_foo)! 3 VALID type is(foo) j = o_foo[2]%i end select end if end program p
[Bug target/46372] New: format '%f' expects type 'double', but argument 3 has type 'float'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46372
Summary: format '%f' expects type 'double', but argument 3 has
type 'float'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: corse...@gcc.gnu.org
I am facing the warning from the subject when compiling this snippet below with
avr-*gcc's:
-- snip --
#include stdio.h
int main()
{
float f = 2.0;
fprintf( stdout, %f\n, f );
}
-- snip --
# avr-rtems4.10-gcc -O2 -o foo -c foo.c -Wall
foo.c: In function 'main':
foo.c:6: warning: format '%f' expects type 'double', but argument 3 has type
'float'
# avr-rtems4.10-gcc --version
avr-rtems4.10-gcc (GCC) 4.4.5 20101001 (RTEMS
gcc-4.4.5-2.fc13/newlib-1.18.0-17.fc13)
# avr-gcc -O2 -o foo -c foo.c -Wall
foo.c: In function 'main':
foo.c:6:3: warning: format '%f' expects type 'double', but argument 3 has type
'float'
# avr-gcc --version
avr-gcc (Fedora 4.5.1-2.fc13) 4.5.1
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 15:21:41 UTC --- Indeed, for x: (mem/s:DI (reg/f:DI 117 [ D.1692 ]) [6 MEM[(struct a[2] *)D.1692_63]+0 S8 A64]) mem: (mem/s/f/c:DI (plus:DI (reg/f:DI 20 frame) (const_int -384 [0xfe80])) [3 D.1548.i.data+0 S8 A64]) rtx_refs_may_alias_p (x, mem, 0) returns 0. indirect_ref_may_alias_decl_p is called with base1 the MEM_REF and base2 VAR_DECL D.1548. And the problem is that may_be_aliased is false for D.1548. Sure, it doesn't have address taken. But as expansion decided to share its slot together with other variables and those are may_be_aliased, this of course breaks. I wonder whether expansion shouldn't somehow make sure that if at least one var in the partition is may_be_aliased, all of them are. Be it by not merging vars that have different may_be_aliased, or by say marking the non-addressable vars TREE_ADDRESSABLE if anything in the partition is addressable. Richard?
[Bug middle-end/46368] [4.6 Regression] ICE in make_decl_rtl, at varasm.c:1033
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46368 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 15:27:33 UTC --- I'll look at this.
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08
15:32:03 UTC ---
(In reply to comment #6)
Indeed, for
x:
(mem/s:DI (reg/f:DI 117 [ D.1692 ]) [6 MEM[(struct a[2] *)D.1692_63]+0 S8
A64])
mem:
(mem/s/f/c:DI (plus:DI (reg/f:DI 20 frame)
(const_int -384 [0xfe80])) [3 D.1548.i.data+0 S8 A64])
rtx_refs_may_alias_p (x, mem, 0)
returns 0.
indirect_ref_may_alias_decl_p is called with base1 the MEM_REF and base2
VAR_DECL D.1548.
And the problem is that may_be_aliased is false for D.1548. Sure, it doesn't
have address taken. But as expansion decided to share its slot together with
other variables and those are may_be_aliased, this of course breaks.
I wonder whether expansion shouldn't somehow make sure that if at least one
var
in the partition is may_be_aliased, all of them are. Be it by not merging
vars
that have different may_be_aliased, or by say marking the non-addressable vars
TREE_ADDRESSABLE if anything in the partition is addressable.
Richard?
We do this already, see cfgexpand.c:add_partitioned_vars_to_ptset and
update_alias_info_with_stack_vars and alias.c:ao_ref_from_mem:
/* If this is a reference based on a partitioned decl replace the
base with an INDIRECT_REF of the pointer representative we
created during stack slot partitioning. */
if (TREE_CODE (base) == VAR_DECL
! TREE_STATIC (base)
cfun-gimple_df-decls_to_pointers != NULL)
{
void *namep;
namep = pointer_map_contains (cfun-gimple_df-decls_to_pointers, base);
if (namep)
ref-base = build_simple_mem_ref (*(tree *)namep);
}
and we try to handle this particular case in update_alias_info_with_stack_vars:
/* Make all points-to sets that contain one member of a partition
contain all members of the partition. */
if (decls_to_partitions)
{
unsigned i;
struct pointer_set_t *visited = pointer_set_create ();
bitmap temp = BITMAP_ALLOC (NULL);
for (i = 1; i num_ssa_names; i++)
{
...
So you say that for some reason this doesn't work.
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-08 15:35:38 UTC --- I will still have a look.
[Bug libfortran/46373] New: fflush called when reading from a string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46373 Summary: fflush called when reading from a string Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: e01reyn...@gmail.com When reading a integer from a string (ie READ(string,'(I3)') number) it calls fflush from flush_if_preconnected routine inside data_transfer_init routine. It causes me trouble in a C thread waiting for keyboard calling getc. Is there a valid reason for calling fflush while reading a string ?
[Bug c/46374] New: Add nooverflow attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46374
Summary: Add nooverflow attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lfs...@gmail.com
When representing a small width unsigned integer in a larger width register,
the compiler has to clear the upper bits of the register before many
expressions, notably shift rights and comparisons. Consider the additional
instructions that have to be inserted in the following code, as opposed to a
signed version in a cpu that always passes parameters in full registers, such
as the ARM.
bool
f (uint16_t x, uint16_t y)
{
return x + 8 == y - 17;
}
It would be helpful if the compiler provided something such as a type attribute
nooverflow that would indicate no overflow involving values of the
corresponding unsigned type may occur. This way, not only this problem is
solved, but optimizations analogous to the ones involving signed values would
apply to these unsigned ones (such as turning for (i = 1; i != 0; ++i) into an
infinite loop).
I respect you possible decision to ignore this report. This is a mere
suggestion. Also, if you consider this a bad idea, please explain why.
Thank you for your attention.
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 15:38:21 UTC --- Ah, if (optimize) update_alias_info_with_stack_vars (); explains that. Guess it should be if (optimize || ...). if (optimize || flag_strict_aliasing) would work for this testcase, but not sure if things still wouldn't break for -O0 -fschedule-insns or similar.
[Bug c/35649] Incorrect printf warning: expect double has float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||corsepiu at gcc dot gnu.org --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-08 15:39:05 UTC --- *** Bug 46372 has been marked as a duplicate of this bug. ***
[Bug target/46372] format '%f' expects type 'double', but argument 3 has type 'float'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46372 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-08 15:39:05 UTC --- This is a dup of the older bug 35649 which some other targets have the same issue. *** This bug has been marked as a duplicate of bug 35649 ***
[Bug c/46374] Add nooverflow attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46374
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-08
15:41:30 UTC ---
That code is really:
bool
f (uint16_t x, uint16_t y)
{
return ((int)x) + 8 == ((int)y) - 17;
}
--- CUT ---
There should be no zero extends in that code because the ABI requires them to
be zero extended already. If there is then that is the bug and really a
nooverflow attribute is not required there.
[Bug c/46374] Add nooverflow attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46374
--- Comment #2 from Luís Fernando Schultz Xavier da Silveira lfsxs0 at gmail
dot com 2010-11-08 15:48:47 UTC ---
(In reply to comment #1)
That code is really:
bool
f (uint16_t x, uint16_t y)
{
return ((int)x) + 8 == ((int)y) - 17;
}
I am very sorry. I forgot the implicit conversion rules.
Please consider:
bool
f (uint16_t x, uint16_t y)
{
x+= 8;
y-= 17;
return x == y;
}
[Bug tree-optimization/45948] [4.6 Regression] ICE: SIGSEGV in find_uses_to_rename_use (tree-ssa-loop-manip.c:1242) with -O -fstrict-overflow -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45948 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org |gnu.org | --- Comment #3 from Sebastian Pop spop at gcc dot gnu.org 2010-11-08 15:49:36 UTC --- Mine.
[Bug debug/46375] New: [4.6 Regression] -fcompare-debug failure (length) with -O -fgcse -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46375 Summary: [4.6 Regression] -fcompare-debug failure (length) with -O -fgcse -fno-tree-dominator-opts Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22327 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22327 reduced testcase Compiler output: $ gcc -fgcse -fno-tree-dominator-opts -fcompare-debug -O pr46375.c gcc: error: pr46375.c: -fcompare-debug failure (length) $ diff pr46375.*gkd 53a54 (code_label 5 0 0 5 [0 uses]) Tested revisions: r166414 - fail r165699 - OK 4.5 r165781 - OK
[Bug target/46208] redundant extensions of argument registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46208 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-08 16:04:18 UTC --- (In reply to comment #4) * config/sparc/sparc.c (TARGET_PROMOTE_PROTOTYPES): Delete. I was just looking into the same problem with MIPS too. I almost think TARGET_PROMOTE_PROTOTYPES in all targets be removed but that is up to each target maintainer.
[Bug fortran/45636] Failed to fold simple Fortran string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #26 from Steve Ellcey sje at cup dot hp.com 2010-11-08 16:08:19 UTC --- The mempcpy is not inlined with -Os. Presumbably because that would increase the size of the resulting object.
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #94 from John David Anglin danglin at gcc dot gnu.org 2010-11-08 16:39:09 UTC --- In doing a 2.6.36 kernel build with d...@mx3210:~/opt/gnu/gcc64/bin$ ./hppa64-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=./hppa64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/dave/opt/gnu/gcc64/libexec/gcc/hppa64-linux-gnu/4.6.0/lto-wrapper Target: hppa64-linux-gnu Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/bin/hppa64-linux-gnu-as --with-gnu-ld --with-ld=/usr/bin/hppa64-linux-gnu-ld --disable-shared --disable-nls --prefix=/home/dave/opt/gnu/gcc64 --disable-threads --disable-target-libiberty --disable-libmudflap --disable-libssp --build=hppa-linux-gnu --host=hppa-linux-gnu --target=hppa64-linux-gnu --enable-languages=c --disable-bootstrap Thread model: single gcc version 4.6.0 20101108 (experimental) [trunk revision 166433] (GCC) I get the following assertion failure: CC fs/ioctl.o fs/ioctl.c: In function 'do_vfs_ioctl': fs/ioctl.c:601:1: internal compiler error: in update_df, at fwprop.c:877 Please submit a full bug report,
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 16:38:55 UTC --- Created attachment 22328 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22328 gcc46-pr43808-1.patch One possible fix (so far untested).
[Bug target/43808] [4.6 Regression] -fipa-reference -fschedule-insns -fstrict-aliasing causes two gfortran check failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43808 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 16:39:39 UTC --- Created attachment 22329 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22329 gcc46-pr43808-2.patch Another possible fix (also untested).
[Bug lto/46376] New: LTO, MinGW and virtual base classes don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46376 Summary: LTO, MinGW and virtual base classes don't work together Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: rodrigorivasco...@gmail.com
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #95 from dave at hiauly1 dot hia.nrc.ca 2010-11-08 17:00:41 UTC --- CC fs/ioctl.o fs/ioctl.c: In function 'do_vfs_ioctl': fs/ioctl.c:601:1: internal compiler error: in update_df, at fwprop.c:877 Please submit a full bug report, Here is full compile command: hppa64-linux-gnu-gcc -Wp,-MD,fs/.ioctl.o.d -nostdinc -isystem /home/dave/opt/gnu/gcc64/lib/gcc/hppa64-linux-gnu/4.6.0/include -I/home/dave/linux/linux-2.6.36.y/arch/parisc/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -pipe -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000 -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(ioctl) -DKBUILD_MODNAME=KBUILD_STR(ioctl) -c -o fs/ioctl.o fs/ioctl.c Attached preprocessed source.
[Bug libfortran/46373] fflush called when reading from a string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46373 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.11.08 17:05:08 CC||kargl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org 2010-11-08 17:05:08 UTC --- See the documentation that comes with gfortran. You can use * GFORTRAN_UNBUFFERED_ALL:: Don't buffer I/O for all units. * GFORTRAN_UNBUFFERED_PRECONNECTED:: Don't buffer I/O for preconnected units. to control the buffering of IO.
[Bug rtl-optimization/46366] gcc.target/i386/pr45352-2.c failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46366
--- Comment #1 from Andrey Belevantsev abel at gcc dot gnu.org 2010-11-08
17:05:38 UTC ---
Sorry, I have checked that the test doesn't ICE but missed the additional
warnings. How about the below patch, do you think it makes sense? I have
verified that the test still ICEs without the PR45352 patch.
Index: gcc/testsuite/gcc.target/i386/pr45352-2.c
===
--- gcc/testsuite/gcc.target/i386/pr45352-2.c (revision 166441)
+++ gcc/testsuite/gcc.target/i386/pr45352-2.c (working copy)
@@ -55,7 +55,7 @@
picture-f_motion.ref
[0]
[0]
- = forward_reference_frame-base + (offset ? picture-pitches[0] : 0);
+ = (char) (long) (forward_reference_frame-base + (offset ?
picture-pitches[0] : 0));
picture-f_motion.ref[0][1] = (offset);
if (picture-picture_structure)
picture-pitches[0] = picture-pitches[1] = 1;
@@ -90,7 +90,7 @@
mpeg2_xvmc_slice
(mpeg2dec_accel_t * accel, picture_t * picture, int code, uint8_t buffer,int
mba_inc)
{
- xine_xvmc_t * xvmc = bitstream_init (picture, buffer);
+ xine_xvmc_t * xvmc = (xine_xvmc_t *) (long) bitstream_init (picture, (void
*) (long) buffer);
slice_xvmc_init (picture, code);
while (1)
{
[Bug lto/46376] LTO, MinGW and virtual base classes don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46376
--- Comment #1 from Rodrigo Rivas rodrigorivascosta at gmail dot com
2010-11-08 17:07:11 UTC ---
Sorry for the previous empty body... my dog ate my keyboard ;-)
Anyway, the following code fails when compiled with MinGW:
$ i686-mingw32msvc-g++ -v
Using built-in specs.
COLLECT_GCC=i686-mingw32msvc-g++
COLLECT_LTO_WRAPPER=/home/rodrigo/local/mingw/libexec/gcc/i686-mingw32msvc/4.6.0/lto-wrapper
Target: i686-mingw32msvc
Configured with: ../configure --prefix=/home/rodrigo/local/mingw
--target=i686-mingw32msvc --build=i686-linux --with-sysroot=/home/rodrigo/local
--enable-lto --enable-languages=c,c++,lto --enable-multilib=no
--with-system-zlib=yes --enable-threads --disable-nls --with-arch-32=i686
--disable-sjlj-exceptions
Thread model: win32
gcc version 4.6.0 20101108 (experimental) (GCC)
*** File: test.h
#ifndef TEST_H_INCLUDED
#define TEST_H_INCLUDED
struct VBase
{
virtual ~VBase()
{
}
};
struct MyClass : virtual public VBase
{
};
#endif /* TEST_H_INCLUDED */
*** File: test.cpp
#include test.h
int main()
{
MyClass x;
return 0;
}
*** File: foo.cpp
#include test.h
int main()
{
MyClass x;
return 0;
}
*** File: bar.cpp
#include test.h
int bar()
{
MyClass x;
return 0;
}
$ i686-mingw32msvc-g++ -flto *.cpp
test.h:11:8: error: '_ZTv0_n12_N7MyClassD1Ev' has already been defined
test.h:11:8: note: previously defined here
test.h:11:8: error: '_ZTv0_n12_N7MyClassD0Ev' has already been defined
test.h:11:8: note: previously defined here
lto-wrapper: i686-mingw32msvc-g++ returned 1 exit status
collect2: lto-wrapper returned 1 exit status
However, with a native build of the exactly same GCC revision it compiles and
links correctly.
This *may* be a duplicate of Bug 45343.
Regards.
Rodrigo
[Bug target/46357] Unnecessary movzx instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46357 --- Comment #2 from Justin Lebar justin.lebar+bug at gmail dot com 2010-11-08 17:08:36 UTC --- (In reply to comment #1) We always use zero/sign-extending moves to avoid partial register stalls. Sure, but the whole instruction on line 10 is unnecessary.
[Bug rtl-optimization/46366] gcc.target/i386/pr45352-2.c failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46366
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 17:13:24
UTC ---
The testcase looks invalid to me:
static bitstream_init (picture_t * picture, void *start)
{
picture-bitstream_ptr = start;
}
...
xine_xvmc_t * xvmc = bitstream_init (picture, buffer);
[Bug c++/46364] basic_string.h:541:32: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46364 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.08 17:22:28 CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.5.2 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 17:22:28 UTC --- It is caused by revision 154200: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00421.html and fixed on trunk by revision 160019: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01078.html
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #96 from Mikael Pettersson mikpe at it dot uu.se 2010-11-08 17:24:29 UTC --- (In reply to comment #88) I also tested the patch on armv5tejl-unknown-linux-gnueabi. The ICE in function '__popcountsi2' is still there, so this must be a separate issue. I have bisected the __popcountsi2 ICE on arm, and it's caused by the infamous r164552. That revision has recently been reverted, so current trunk should hopefully be better.
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #97 from H.J. Lu hjl.tools at gmail dot com 2010-11-08 17:30:36 UTC --- (In reply to comment #96) (In reply to comment #88) I also tested the patch on armv5tejl-unknown-linux-gnueabi. The ICE in function '__popcountsi2' is still there, so this must be a separate issue. I have bisected the __popcountsi2 ICE on arm, and it's caused by the infamous r164552. That revision has recently been reverted, so current trunk should hopefully be better. I suggest you open a bug report, if there isn't one already, and make it depend on PR 46257 so that Bernds can double check it when he works on the proper fix.
[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45894 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-08 17:40:15 UTC --- Created attachment 22331 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22331 gcc46-pr45894.patch Ok, I'll bootstrapp/regtest this then.
