[Bug target/48767] compiler error: Segmentation fault with set void in va_arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48767 --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-05-30 06:03:35 UTC --- It isn't a regression, is it? My gcc-4.2 segfaults too for that testcase.
[Bug target/49186] optimize problem with unsigned long long value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49186 --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-05-30 06:05:04 UTC --- (In reply to comment #4) Could you backport each branches? I'll do so.
3-yr-old infloop in dwarf2out.c
coverity pointed out the infinite loop below.
I guess it is unreachable or at least hard to reach,
or it would have been reported/fixed before now:
17605 if (index TREE_CODE (index) == RANGE_EXPR)
17606 {
17607 int count = tree_low_cst (TREE_OPERAND (index, 1), 0)
17608 - tree_low_cst (TREE_OPERAND (index, 0),
0);
Event loop_top: Top of the loop.
Event loop_condition: 0 count must remain true for the loop to continue.
Also see events:[loop_bottom]
17609 while (count 0)
17610 {
17611 if (val)
17612 memcpy (array + curpos, array + pos, fieldsize);
Event loop_bottom: Bottom of the loop.
Also see events:[loop_top][loop_condition]
17613 curpos += fieldsize;
17614 }
17615 }
[Bug tree-optimization/49199] [4.7 Regression] ICE: in vect_create_epilog_for_reduction at tree-vect-loop.c:3445 with -O -fno-tree-scev-cprop -ftree-vectorize -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49199 --- Comment #3 from irar at gcc dot gnu.org 2011-05-30 07:15:35 UTC --- Author: irar Date: Mon May 30 07:15:31 2011 New Revision: 174425 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174425 Log: PR tree-optimization/49199 * tree-vect-loop.c (vect_is_slp_reduction): Check that the non-reduction operands are either defined in the loop or by induction. Added: trunk/gcc/testsuite/gcc.dg/vect/no-scevccp-pr49199.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/tree-vect-loop.c
[Bug middle-end/49201] [4.7 Regression] ice in tree_add_const_value_attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49201 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-30 07:27:47 UTC --- Fixed then.
[Bug tree-optimization/49218] Incorrect optimization of a 'for' loop creates an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218
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 2011-05-30
08:31:24 UTC ---
Can be reproduced on x86_64-linux too, with:
#ifdef __x86_64__
typedef __int128 L;
#else
typedef long long L;
#endif
float f;
int
main ()
{
L i = f;
if (i = 10)
do
{
++i;
asm ();
}
while (i != 11);
return 0;
}
at -O2.
[Bug c++/49227] New: ice in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49227 Summary: ice in inline_small_functions Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the package itpp-4.0.6 with the latest 4.7 snapshot 20110528 on a Fedora Linux x86_64 box. The compiler said ../../itpp/protocol/tcp.cpp:1932:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1348 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug c++/49227] ice in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49227 --- Comment #1 from dcb dcb314 at hotmail dot com 2011-05-30 08:37:39 UTC --- Created attachment 24393 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24393 gzipped C++ source code
[Bug bootstrap/49228] New: gcc fails to compile on darwin (with lto)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49228 Summary: gcc fails to compile on darwin (with lto) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch compiling gcc on darwin stops at /Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/prev-gcc/xgcc -B/Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/prev-gcc/ -B/usr/local/x86_64-apple-darwin10.7.0/bin/ -B/usr/local/x86_64-apple-darwin10.7.0/bin/ -B/usr/local/x86_64-apple-darwin10.7.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.7.0/include -isystem /usr/local/x86_64-apple-darwin10.7.0/sys-include-c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -mdynamic-no-pic -flto=jobserver -frandom-seed=1 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I../.././gcc -I../.././gcc/c-family -I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber../.././gcc/c-family/c-common.c -o c-family/c-common.o /var/folders/Ur/UrR7agy72RWuJU+BYnMxQU+++TQ/-Tmp-//ccISnqXM.s:287338:FATAL:too many sections (maximum 255) /Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/prev-gcc/xgcc -v Using built-in specs. COLLECT_GCC=/Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/prev-gcc/xgcc Target: x86_64-apple-darwin10.7.0 Configured with: ./configure --enable-languages=c,c++,fortran --enable-lto --with-build-config=bootstrap-lto CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden' Thread model: posix gcc version 4.7.0 20110528 (experimental) (GCC) it is the first time I try lto on MAC removing -flto compile
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130 --- Comment #6 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-05-30 08:44:43 UTC --- Another issue is with DMGL_VERBOSE. nm -C does not use DMGL_VERBOSE: libstdc++.so.6.0.16.debug 000a4e50 t bool __gnu_cxx::operator==char*, std::string(__gnu_cxx::__normal_iteratorchar*, std::string const, __gnu_cxx::__normal_iteratorchar*, std::string const) But the DIE uses DMGL_VERBOSE: 21836e2: Abbrev Number: 29 (DW_TAG_subprogram) 1836e4 DW_AT_name: (indirect string, offset: 0x2e3f0): operator==char*, std::basic_stringchar 1188ab4: Abbrev Number: 103 (DW_TAG_subprogram) 188ab5 DW_AT_specification: 0x1836e2 1193100: Abbrev Number: 129 (DW_TAG_subprogram) 193102 DW_AT_abstract_origin: 0x188ab4 193106 DW_AT_low_pc : 0xa4e50
[Bug c++/49225] [C++0x] Weird SFINAE behavior with variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49225 --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-05-30 08:46:33 UTC --- I did some further investigation of this. The problem seems *not* to be located in __my_and_, but it seems that the compiler expands is_sameT, U... for different T, U to the specialization is_sameT, T in this scenario - which is obviously incorrect. This could be concluded after either removing the is_sameT, T definition or by changing its value to false. When removing the definition, the occurring error message reveals, that the instantiation of is_sameA, A instead of is_sameint, A is tried, thus pointing to an incorrect expansion that does ignore the _Args1 expansion.
[Bug target/45263] registers used in __do_global_ctors can get clobbered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263 --- Comment #15 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-30 08:53:15 UTC --- Author: gjl Date: Mon May 30 08:53:12 2011 New Revision: 174427 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174427 Log: PR target/45263 * config/avr/libgcc.S (__do_global_ctors, __do_global_dtors): Don't use r20 around calls of __tablejump_elpm__ Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/avr/libgcc.S
[Bug tree-optimization/49227] [4.7 Regression] ice in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49227 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|c++ |tree-optimization Target Milestone|--- |4.7.0 Summary|ice in |[4.7 Regression] ice in |inline_small_functions |inline_small_functions
[Bug tree-optimization/49218] Incorrect optimization of a 'for' loop creates an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2011-05-30 09:00:46 UTC --- Triggered by r163724: Author: rguenth Date: Wed Sep 1 11:39:55 2010 New Revision: 163724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163724 Log: 2010-09-01 Richard Guenther rguent...@suse.de * tree-vrp.c (adjust_range_with_scev): Use number of iteration estimate. (vrp_visit_phi_node): Delay using SCEV till we balloon the range. (execute_vrp): Compute number of iteration estimates. * cfgloop.h (estimate_numbers_of_iterations_loop): Adjust prototype. * tree-flow.h (estimate_numbers_of_iterations): Likewise. * tree-data-ref.c (estimated_loop_iterations): Adjust. * tree-ssa-loop-niter.c (estimate_numbers_of_iterations_loop): Infer loop bounds from undefined behavior based on a new parameter. (estimate_numbers_of_iterations): Likewise. (scev_probably_wraps_p): Adjust. * tree-ssa-loop.c (tree_ssa_loop_bounds): Likewise. The original C++ test case stopped failing on trunk with r171450: Author: rguenth Date: Fri Mar 25 11:59:19 2011 New Revision: 171450 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171450 Log: 2011-03-25 Richard Guenther rguent...@suse.de * passes.c (init_optimization_passes): Add FRE pass after early SRA. but that's accidental: the C test case still fails after this, and the C++ one fails if compiled with -O2 -fno-tree-fre.
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de 2011-05-30 09:02:55 UTC --- On Fri, 27 May 2011, hubicka at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-27 21:37:46 UTC --- Hmm, so shall I still try the patch? The ICE is now more common. We used to fail twice during mozilla build, now we fail about approximately 5 different shared libraries. The patch isn't complete. It at least misses walking DECL_ORIGINAL_TYPE in free-lang-data.
[Bug tree-optimization/49199] [4.7 Regression] ICE: in vect_create_epilog_for_reduction at tree-vect-loop.c:3445 with -O -fno-tree-scev-cprop -ftree-vectorize -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49199 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-05-30 09:08:52 UTC --- Fixed.
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #15 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-05-30 09:11:08 UTC --- (In reply to comment #13) Moreover, I think that this test case is in fact invalid, cf. PR 48887. Hm. I see; I wonder, is this something that was added in F2008 or was it present in F2003?
[Bug bootstrap/49228] gcc fails to compile on darwin (with lto)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49228 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-30 09:11:59 UTC --- This is a duplicate of pr48086. If you want to use lto on darwin, you have to revert to Xcode 3.2.5 or try the patch in http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01695.html (see pr48108). *** This bug has been marked as a duplicate of bug 48086 ***
[Bug tree-optimization/49218] Incorrect optimization of a 'for' loop creates an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30
09:13:17 UTC ---
I'm going to test
@@ -3423,11 +3423,14 @@ adjust_range_with_scev (value_range_t *v
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 (!overflow double_int_equal_p (dtmp, tree_to_double_int (tem)))
+adjustment. Likewise if the unsigned result doesn't fit in the type
+of the induction variable. */
+ if (!overflow
+ double_int_fits_to_tree_p (TREE_TYPE (init), dtmp)
+ (unsigned_p || dtmp.high 0))
{
+ tem = double_int_to_tree (TREE_TYPE (init), dtmp);
extract_range_from_binary_expr (maxvr, PLUS_EXPR,
TREE_TYPE (init), init, tem);
/* Likewise if the addition did. */
[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48086 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #25 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-30 09:11:59 UTC --- *** Bug 49228 has been marked as a duplicate of this bug. ***
[Bug c++/49225] [C++0x] Weird SFINAE behavior with variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49225 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-30 09:20:30 UTC --- Thanks Daniel. Depending on how this issue is resolved - at this point I'm pretty sure it's an actual issue - given also the inconsistency vs the static_assert, I will actually use something similar in the library.
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-30 09:22:25 UTC --- (In reply to comment #13) Moreover, I think that this test case is in fact invalid, cf. PR 48887. We are talking about comment 4, aren't we? (That test case fails with ifort 12 as sm2 is not allocatable. It (and the one in PR 48887) compiles with crayftn, but I have not checked whether the resulting code makes sense.)
[Bug bootstrap/49228] gcc fails to compile on darwin (with lto)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49228 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-30 09:28:50 UTC --- If you want to keep most of Xcode 3.2.6, but live dangerously with lto, you can also do what I have done: i.e., replace Apple Inc version cctools-795~45, GNU assembler version 1.38 of 3.2.6 with Apple Inc version cctools-782~33, GNU assembler version 1.38 from 3.2.5. The relevant beasts are in /usr/libexec/gcc/darwin/x86_64 and /usr/libexec/gcc/darwin/i386/. Use at your own risk!-)
[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-30 09:35:44 UTC --- (In reply to comment #15) I see; I wonder, is this something that was added in F2008 or was it present in F2003? If you talk about that associate-names don't inherit the allocate attribute from the selector: That's not new. Cf. F2003, 16.4.1.5 Construct association and F2008, 16.5.1.6. A quote from the latter can be found in bug 48887 comment 0.
[Bug middle-end/49210] [4.7 regression] verify_gimple fails building ada/einfo.o at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49210 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 #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 10:47:43 UTC --- We have calls that assign iftmp.2_37 = boolean_subtype2.is_string_type.part (id_3(D)); integer_type 0x75b5c0a8 boolean_subtype2__b___XDLU_0__1 type boolean_type 0x77ee3dc8 boolean sizes-gimplified public visited unsigned QI size integer_cst 0x77ed3f80 constant visited 8 unit size integer_cst 0x77ed3fa0 constant 1 align 8 symtab 0 alias set 5 canonical type 0x77ee3dc8 precision 8 min integer_cst 0x77ee85e0 0 max integer_cst 0x77ee8600 255 RM size integer_cst 0x77ee8640 1 RM max integer_cst 0x77ee8620 1 sizes-gimplified public visited unsigned QI size integer_cst 0x77ed3f80 8 unit size integer_cst 0x77ed3fa0 1 align 8 symtab 0 alias set 5 canonical type 0x75b5c0a8 precision 8 min integer_cst 0x75b6c800 0 max integer_cst 0x75b6c820 255 RM size integer_cst 0x77ee8640 1 RM min integer_cst 0x77ee85e0 0 RM max integer_cst 0x77ee8620 1 chain type_decl 0x77f128a0 boolean_subtype2__b___XDLU_0__1 (the function result type) to boolean_type 0x77ee3dc8 boolean sizes-gimplified public visited unsigned QI size integer_cst 0x77ed3f80 type integer_type 0x77ee30a8 bit_size_type constant visited 8 unit size integer_cst 0x77ed3fa0 type integer_type 0x77ee3000 size_type constant 1 align 8 symtab 0 alias set 5 canonical type 0x77ee3dc8 precision 8 min integer_cst 0x77ee85e0 0 max integer_cst 0x77ee8600 255 RM size integer_cst 0x77ee8640 1 RM max integer_cst 0x77ee8620 1 where only for the type of the LHS we know it's two-valued. This is exposed during inlining triggered by function splitting.
[Bug middle-end/49210] [4.7 regression] verify_gimple fails building ada/einfo.o at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49210 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 11:13:41 UTC --- I think a similar case could be constructed with restrict qualified pointers. I have a patch.
[Bug tree-optimization/49218] Incorrect optimization of a 'for' loop creates an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 11:15:25 UTC --- Author: rguenth Date: Mon May 30 11:15:20 2011 New Revision: 174429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174429 Log: 2011-05-30 Richard Guenther rguent...@suse.de PR tree-optimization/49218 * tree-vrp.c (adjust_range_with_scev): Properly check whether overflow occured. * gcc.c-torture/execute/pr49218.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr49218.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/49218] Incorrect optimization of a 'for' loop creates an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 11:17:38 UTC --- Author: rguenth Date: Mon May 30 11:17:35 2011 New Revision: 174430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174430 Log: 2011-05-30 Richard Guenther rguent...@suse.de PR tree-optimization/49218 * tree-vrp.c (adjust_range_with_scev): Properly check whether overflow occured. * gcc.c-torture/execute/pr49218.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49218.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-vrp.c
[Bug c++/49229] New: [C++0x][SFINAE] ICE with variadics and depending non-type default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49229
Summary: [C++0x][SFINAE] ICE with variadics and depending
non-type default parameter
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110528 (experimental) in C++0x mode produces an ICE with the
following program at the line marked with #:
//-
extern void* enabler;
templatebool, class = void
struct enable_if {};
templateclass T
struct enable_iftrue, T {
typedef T type;
};
templateclass... Bn
struct and_;
templateclass B1
struct and_B1 : B1 {};
templateclass, class
struct is_same {
static constexpr bool value = false;
};
templateclass T
struct is_sameT, T {
static constexpr bool value = true;
};
templateclass... T
struct S {
templateclass... U,
typename enable_ifand_is_sameT, U...::value::type* = enabler
S(U...){} // #
};
Sbool s(0);
//-
internal compiler error: tree check: expected tree_vec, have error_mark in
comp_template_args, at cp/pt.c:6534
This bug is possibly related to bug 49225.
[Bug tree-optimization/49218] Incorrect optimization of a 'for' loop creates an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49218 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 Known to fail||4.6.0 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 11:20:06 UTC --- Fixed.
[Bug c++/49229] [C++0x][SFINAE] ICE with variadics and depending non-type default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49229
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-05-30 11:26:28 UTC ---
[Possibly of interest for Paolo as well]
Some observations: Other binary traits that do not lead to a degenerate
specialization as is_same does, do not produce this ICE. E.g. given
templateclass, class
struct is_blubb {
static constexpr bool value = false;
};
template
struct is_blubbbool, bool {
static constexpr bool value = true;
};
and a constrained c'tor of S like this
templateclass... T
struct S {
templateclass... U,
typename enable_ifand_is_blubbT, U...::value::type* = enabler
S(U...){}
};
Sbool s(0);
As expected, this program is rejected as expected, but does not produce an ICE.
[Bug c++/49229] [C++0x][SFINAE] ICE with variadics and depending non-type default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49229 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-30 11:33:31 UTC --- Thanks for your further investigation of these issues, Daniel. I'm not sure to understand what you mean by degenerate specialization, though. In my experience, a binary trait like is_convertible for example also doesn't work (actually, in the PR I picked is_same only for its simplicity)
[Bug rtl-optimization/49230] New: please provide workaround for setjmp/longjmp in mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49230 Summary: please provide workaround for setjmp/longjmp in mingw32 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: jojel...@gmail.com Host: i686-pc-cygwin Target: i686-pc-mingw32 Build: i686-pc-cygwin in mingw32, there is setjmp/longjmp which its implementation is specific to msvc. and, in latest gcc trunk ebp register doesn't have to have its caller's frame address.( unfortunately, this could cause mingw32 application which use setjmp/longjmp to SIGSEGV. because in msvcrt, __NLG_Notify dereferences ebp+8 which is *(((void*)jmp_buf[0])+2) which msvcrt assumes it's correct address(maybe first parameter of caller function), and which it assumes is wrong for now.
[Bug c++/49223] Internal compiler error when using OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49223 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.30 11:55:00 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.1 Ever Confirmed|0 |1
[Bug c++/49223] Internal compiler error when using OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49223 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-30 11:56:18 UTC --- Created attachment 24394 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24394 gcc46-pr49223.patch Untested fix. The problem is that require_complete_type is just a nop if processing_template_decl, so we can't rely on the type being actually complete.
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #24343|0 |1 is obsolete|| --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 11:59:30 UTC --- Created attachment 24395 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24395 updated patch Updated patch containing the fld hunk. See also the dwarf2out.c commented change which might be necessary (ISTR to run into this). I also seem to remember that the gimple.c change has issues during LTO bootstrap for some reason. So, I'm not entirely happy, but somehow we have to stream DECL_ORIGINAL_TYPE.
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #6 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-05-30 12:01:11 UTC --- this is actually a follow up of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49228 that has been identified as a duplicate of this bug. I applied the patch now stops here /bin/sh ./libtool --tag=CC --mode=compile /Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/gcc/xgcc -B/Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/gcc/ -B/usr/local/x86_64-apple-darwin10.7.0/bin/ -B/usr/local/x86_64-apple-darwin10.7.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.7.0/include -isystem /usr/local/x86_64-apple-darwin10.7.0/sys-include-DHAVE_CONFIG_H -I. -I../.././libgfortran -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../.././libgfortran/../libquadmath -I../../host-x86_64-apple-darwin10.7.0/gcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -ftree-vectorize -fPIC -MT fmain.lo -MD -MP -MF .deps/fmain.Tpo -c -o fmain.lo ../.././libgfortran/fmain.c libtool: compile: /Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/gcc/xgcc -B/Users/innocent/RealStuff/gcc-4.7-20110528/host-x86_64-apple-darwin10.7.0/gcc/ -B/usr/local/x86_64-apple-darwin10.7.0/bin/ -B/usr/local/x86_64-apple-darwin10.7.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.7.0/include -isystem /usr/local/x86_64-apple-darwin10.7.0/sys-include -DHAVE_CONFIG_H -I. -I../.././libgfortran -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../.././libgfortran/../libquadmath -I../../host-x86_64-apple-darwin10.7.0/gcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -ftree-vectorize -fPIC -MT fmain.lo -MD -MP -MF .deps/fmain.Tpo -c ../.././libgfortran/fmain.c -fno-common -DPIC -o .libs/fmain.o In file included from ../.././libgfortran/libgfortran.h:53:0, from ../.././libgfortran/fmain.c:4: ../.././libgfortran/../libquadmath/quadmath_weak.h:39:1: internal compiler error: tree check: expected tree that contains ‘common’ structure, have ‘identifier_node’ in assemble_alias, at varasm.c:5789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/46500] target.h includes tm.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46500 --- Comment #9 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2011-05-30 12:11:07 UTC --- Author: amylaar Date: Mon May 30 12:11:03 2011 New Revision: 174431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174431 Log: PR middle-end/46500 gcc/java: * expr.c: Include tm.h . Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/expr.c
[Bug c++/49223] Internal compiler error when using OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49223 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-30 12:16:08 UTC --- Author: jakub Date: Mon May 30 12:16:04 2011 New Revision: 174432 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174432 Log: PR c++/49223 * semantics.c (finish_omp_clauses): Call require_complete_type even for copyin/copyprivate clauses. Only call cxx_omp_create_clause_info if inner_type is COMPLETE_TYPE_P. * g++.dg/gomp/pr49223-1.C: New test. * g++.dg/gomp/pr49223-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr49223-1.C trunk/gcc/testsuite/g++.dg/gomp/pr49223-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49223] Internal compiler error when using OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49223 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-30 12:19:02 UTC --- Author: jakub Date: Mon May 30 12:18:59 2011 New Revision: 174433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174433 Log: PR c++/49223 * semantics.c (finish_omp_clauses): Call require_complete_type even for copyin/copyprivate clauses. Only call cxx_omp_create_clause_info if inner_type is COMPLETE_TYPE_P. * g++.dg/gomp/pr49223-1.C: New test. * g++.dg/gomp/pr49223-2.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gomp/pr49223-1.C branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gomp/pr49223-2.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-30 12:19:45 UTC --- This is pr49190. If you want to proceed, you need to revert revision 174286 (or to wait for a fix). BTW which version of Xcode are you using?
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #8 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-05-30 12:26:37 UTC --- On 30 May, 2011, at 2:20 PM, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-30 12:19:45 UTC --- This is pr49190. If you want to proceed, you need to revert revision 174286 (or to wait for a fix). ok, I will wait for a fix it built g++ and that's enough for let me going for a while :-) BTW which version of Xcode are you using? apparently Version 3.2.6 thanks for the quick reply v.
[Bug libgomp/49231] New: #pragma omp parallel for never returns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49231 Summary: #pragma omp parallel for never returns Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: parviz_farib...@mentor.com Created attachment 24396 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24396 The attached file re-produces the probem that I have reported above Hi, The attached program when compiled using gcc 4.4.3 produces the following output and never returns : ... === Fpga: 865, Thread: 6 === Fpga: 866, Thread: 6 === Fpga: 867, Thread: 6 === Fpga: 868, Thread: 6 === Fpga: 869, Thread: 6 === Fpga: 870, Thread: 6 === Fpga: 871, Thread: 6 === Fpga: 872, Thread: 6 === Fpga: 873, Thread: 6 === Fpga: 874, Thread: 6 I have to kill the process to make it exit. The same program when compiled using gcc 4.3.3 and run on the same machine works fine and produces the correct output. I compile and run the program on a redhat 4 linux machine with the following specs: mawhp2:/home/parvizf/tmp= uname -a Linux mawhp2 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux mawhp2:/home/parvizf/tmp= cat /etc/redhat-release Red Hat Enterprise Linux WS release 4 (Nahant Update 8) Thanks in advance for your help. -Parviz
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-30 13:04:29 UTC --- ok, I will wait for a fix Meanwhile you can also configure with --enable-checking=release.
[Bug middle-end/49210] [4.7 regression] verify_gimple fails building ada/einfo.o at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49210 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 13:12:27 UTC --- Author: rguenth Date: Mon May 30 13:12:23 2011 New Revision: 174435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174435 Log: 2011-05-30 Richard Guenther rguent...@suse.de PR tree-optimization/49210 * ipa-split.c (split_function): Care for the case where the call result is not trivially convertible to the result holding variable. * gnat.dg/boolean_subtype2.adb: New testcase. * gnat.dg/boolean_subtype2.ads: Likewise. * gnat.dg/boolean_subtype2_pkg.ads: Likewise. Added: trunk/gcc/testsuite/gnat.dg/boolean_subtype2.adb trunk/gcc/testsuite/gnat.dg/boolean_subtype2.ads trunk/gcc/testsuite/gnat.dg/boolean_subtype2_pkg.ads Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49210] [4.7 regression] verify_gimple fails building ada/einfo.o at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49210 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 13:12:45 UTC --- Fixed.
[Bug c/40528] Add a new ifunc attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528 --- Comment #15 from Agner Fog agner at agner dot org 2011-05-30 13:13:06 UTC --- (In reply to comment #14) (In reply to comment #13) What is the status of this issue? It is implemented on ifunc branch. Is option 3 implemented? Yes, on ifunc branch. Which versions of Linux and binutils support IFUNC? You need at least glibc 2.11 and binutils 2.20. Any plans for BSD and Mac? You have to ask BSD and Mac people since IFUNC support needs to be implemented in both binutils and the C library. Still doesn't work. warning: ‘ifunc’ attribute directive ignored GNU Binutils for Ubuntu 2.21.0.20110327 Where can I find an implementation with ifunc branch?
[Bug libgomp/49231] #pragma omp parallel for never returns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49231 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 2011-05-30 13:15:49 UTC --- Can't reproduce, tried gcc 4.4.5, 4.6 and 4.7, both -m32 and -m64, gcc and g++, and various options.
[Bug c++/49221] [4.7 Regression] Several ICEs in the obj-c++ test suite after revision 174307
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49221 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-30 14:09:28 UTC --- Most *-*-solaris* does not seem affected by this pr (see http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg03426.html or http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg03448.html ).
[Bug target/49211] MMIX: Code generation broken, when using global variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-30 14:24:52 UTC --- With -nostdlib, you're basically disabling the startup code that is supposed to setup everything. If it still doesn't work without -nostdlib, then I'll have a look.
[Bug target/49211] MMIX: Code generation broken, when using global variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.30 14:25:18 Ever Confirmed|0 |1
[Bug target/49211] MMIX: Code generation broken, when using global variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-30 14:29:32 UTC --- See gcc/config/mmix/crtn.asm, where the global registers used by the ABI are allocated.
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #14 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-30 14:33:31 UTC --- (In reply to comment #13) Yep it looks a lot better now. The if statements could be optimized into the equivalent shift instructions but that is not a AVR backend problem I guess. Shifting generally is more expensive instead of bit extracting; at least if the bit offset is known at compile time. I noticed that the disassembly shows wrong lengths for some outputs of extzv. Is that a problem? It's not a problem if the sequence actually printed is not greater than the instruction length reported. If the reported instruction length was strinct greater, an assembler error could occur because relative jump offets migh be out of scope. The only case where the instruction length is smaller than reported is if IN_REG=OUT_REG and BITPOS=4 (sequence is swap + andi 1). The instruction length for lsr + andi 1 (IN_REG=OUT_REG, BITPOS=1) is already corrected in the patch.
[Bug target/49211] MMIX: Code generation broken, when using global variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211 --- Comment #3 from Nils Asmussen n...@script-solution.de 2011-05-30 14:47:40 UTC --- Thanks for your reply! Perhaps I miss something, but I've no idea how that should work. Regardless of whether $254 is initialized previously or not (in my case, it's a bootloader, so there is no stdlib and no crt*, but I have to do that myself), using the stack-pointer to access global variables can't work, right? Lets suppose, that the offset in main is correct. That would mean, that x is located at $254 + 8. But $254 is changed (of course) at the beginning and end of a function (and nowhere else). If func2 accesses x as well, gcc generates code to access it at $254 + 8. So, it expects it to be always at offset 8 from $254, but of course that can't work, because $254 changes.
[Bug target/49211] MMIX: Code generation broken, when using global variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-30 14:59:06 UTC --- (In reply to comment #3) Perhaps I miss something, but I've no idea how that should work. Writing a bootloader, you really should. Regardless of whether $254 is initialized previously or not (in my case, it's a bootloader, so there is no stdlib and no crt*, but I have to do that myself), using the stack-pointer to access global variables can't work, right? The key words are setup and allocated not initialized. Again, I suggest you have a look at crtn.asm, in particular these lines: % This must be the last file on the link-line, allocating global registers % from the top. % Register $254 is the stack-pointer. sp GREG So, if you leave that out, the global-register-allocation machinery in the linker will allocate registers starting from the topmost, which is $254 ($255 being a scratch register).
[Bug libgomp/49231] #pragma omp parallel for never returns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49231 Parviz Fariborz parviz_fariborz at mentor dot com changed: What|Removed |Added CC||parviz_fariborz at mentor ||dot com --- Comment #2 from Parviz Fariborz parviz_fariborz at mentor dot com 2011-05-30 15:11:16 UTC --- -Parviz(In reply to comment #1) Can't reproduce, tried gcc 4.4.5, 4.6 and 4.7, both -m32 and -m64, gcc and g++, and various options. The compile/link option -static seems to be significant in this case. The executable built with the following command : /tools/linux64/gcc-4.4.3/bin/g++ -o omp -g -static -fopenmp -lgomp -lpthread -I/tools/linux64/gcc-4.4.3/include -L/usr/lib64 -L/tools/linux64/gcc-4.4.3/lib64 omp.cc Do not work. When I remove the -static option, it does work. Any ideas?
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-30 15:16:25 UTC --- Created attachment 24397 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24397 Iain's work in progress for LTO containerization
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 --- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-30 15:15:31 UTC --- I have been using Iain's last work in progress patch and it works fine with both gcc 4.6 branch and gcc trunk. Hopefully he can get back to polishing it or someone else can pick up the patch and complete it.
[Bug target/45263] registers used in __do_global_ctors can get clobbered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Version|4.6.1 |4.5.1 Target Milestone|--- |4.6.1
[Bug target/49211] MMIX: Code generation broken, when using global variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211 --- Comment #5 from Nils Asmussen n...@script-solution.de 2011-05-30 15:22:37 UTC --- Again, I suggest you have a look at crtn.asm, in particular these lines: % This must be the last file on the link-line, allocating global registers % from the top. % Register $254 is the stack-pointer. sp GREG So, if you leave that out, the global-register-allocation machinery in the linker will allocate registers starting from the topmost, which is $254 ($255 being a scratch register). Oh, ok. I thought in a different direction :/ Then it's perfectly clear. Thanks!
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.30 15:30:05 Ever Confirmed|0 |1 --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org 2011-05-30 15:30:05 UTC --- (In reply to comment #11) Created attachment 24397 [details] Iain's work in progress for LTO containerization Sorry that I can't commit any time to GCC right now. The main outstanding issue with this patch is that the intermediate files created by GCC are still unbounded in the number of sections. So long as the only consumer of those files is GCC, no problem (since the arrangement has been made to ensure that relocatable sections come first). However, those intermediate files are still technically 'wrong' and therefore the writer should be updated to do the same encapsulation. Once that is done there will be no need to retain the ability to recognize GCC vs 'normal' objects.
[Bug fortran/49232] New: Pointer assignment of stride to CONTIGUOUS pointer not diagnosed as invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232 Summary: Pointer assignment of stride to CONTIGUOUS pointer not diagnosed as invalid Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Test case by Reinhold Bader, LRZ. Pointer assignment of a non-contiguous target to a CONTIGUOUS pointer is invalid: If the pointer object has the CONTIGUOUS attribute, the pointer target shall be contiguous. Note: The standard does not require simply contiguous, i.e. the compiler can accept pointer targets for which it does not know whether they are contiguous. Cf. gfc_is_simply_contiguous, which, however, cannot be used directly. program cont_01_neg implicit none real, pointer, contiguous :: r(:) real, target :: x(45) integer :: i x = (/ (real(i),i=1,45) /) r = x(22::3) write(*,*) 'FAIL' end program
[Bug libgomp/49231] #pragma omp parallel for never returns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49231 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-30 16:30:16 UTC --- See http://www.akkadia.org/drepper/no_static_linking.html If you still for whatever weird reason insist to link statically, for NPTL you need to -Wl,--whole-archive -lpthread -Wl,--no-whole-archive because if only some objects from libpthread are linked in, it can misbehave in various ways. In RHEL6 libpthread.a contains just one object ld -r linked together the whole normal libpthread.a contents, but in upstream glibc as well as older RHEL versions (no idea about other distros) you need to link as mentioned above.
[Bug c/49233] New: Please un-deprecate rvalues in memory constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49233 Summary: Please un-deprecate rvalues in memory constraints Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@zytor.com gcc 4.6.0 has started outputting these warnings: /home/hpa/kernel/linux-2.6-tip.urgent/arch/x86/include/asm/bitops.h: In function ‘can_boost’: /home/hpa/kernel/linux-2.6-tip.urgent/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input without lvalue in asm operand 1 is deprecated [enabled by default] The Linux kernel is going to require this construct indefinitely. Please stop issuing this nuisance warning.
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 --- Comment #14 from Nathan Froyd froydnj at gcc dot gnu.org 2011-05-30 16:42:12 UTC --- Author: froydnj Date: Mon May 30 16:42:05 2011 New Revision: 174445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174445 Log: fix PR bootstrap/4910 gcc/ PR bootstrap/49190 Revert: 2011-05-26 Nathan Froyd froy...@codesourcery.com * tree.h (struct tree_identifier): Inherit from tree_typed, not tree_common. (HT_IDENT_TO_GCC_IDENT): Adjust for said change. * tree.c (initialize_tree_contains_struct): Mark TS_IDENTIFIER as TS_BASE instead of TS_COMMON. * varasm.c (assemble_name): Remove assert. gcc/c-family/ PR bootstrap/49190 Revert: 2011-05-26 Nathan Froyd froy...@codesourcery.com * c-common.h (struct c_common_identifier): Inherit from tree_typed, not tree_common. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/varasm.c
[Bug c/4910] imacat ima...@mail.imacat.idv.tw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4910 --- Comment #4 from Nathan Froyd froydnj at gcc dot gnu.org 2011-05-30 16:42:10 UTC --- Author: froydnj Date: Mon May 30 16:42:05 2011 New Revision: 174445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174445 Log: fix PR bootstrap/4910 gcc/ PR bootstrap/49190 Revert: 2011-05-26 Nathan Froyd froy...@codesourcery.com * tree.h (struct tree_identifier): Inherit from tree_typed, not tree_common. (HT_IDENT_TO_GCC_IDENT): Adjust for said change. * tree.c (initialize_tree_contains_struct): Mark TS_IDENTIFIER as TS_BASE instead of TS_COMMON. * varasm.c (assemble_name): Remove assert. gcc/c-family/ PR bootstrap/49190 Revert: 2011-05-26 Nathan Froyd froy...@codesourcery.com * c-common.h (struct c_common_identifier): Inherit from tree_typed, not tree_common. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/varasm.c
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 --- Comment #15 from Nathan Froyd froydnj at gcc dot gnu.org 2011-05-30 16:43:01 UTC --- I've reverted the offending commit. If somebody could confirm that the failures are gone, this PR can be closed.
[Bug c/49234] New: -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
Summary: -Wstrict-overflow gives obviously unwarranted warning
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net
Given this code, in file k.c, -O2 -Wstrict-overflow evokes a warning.
However, since the only values assigned to state are 0, 1 and 2,
gcc should be able to determine that no overflow is possible,
and hence should issue no warning:
char *
trim2 (char *d)
{
int state = 0;
char *r;
int i;
for (i = 0; d[i]; i++)
{
if (state == 0 d[i] == ' ')
continue;
if (state == 0) /* line 13 */
state = 1;
if (state == 1)
{
state = 2;
r = d + i;
}
}
if (state == 2)
*r = '\0';
return d;
}
$ gcc -O2 -Wstrict-overflow -c k.c
k.c: In function 'trim2':
k.c:13:10: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
For the record, until recently I would not have bothered enabling
-Wstrict-overflow, due to the high proportion of false-positives,
but since I've learned about the risk of this bug,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498
I am now more inclined to use -Wstrict-overflow in spite of that.
[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 --- Comment #10 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-05-30 17:12:58 UTC --- Author: wschmidt Date: Mon May 30 17:12:53 2011 New Revision: 174446 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174446 Log: 2011-05-30 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/46728 * tree-ssa-math-opts.c (build_and_insert_call): Reorder parms. (build_and_insert_binop): New. (gimple_expand_builtin_pow): Reorder args for build_and_insert_call; use build_and_insert_binop; add more optimizations for fractional exponents. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug fortran/45786] [4.5/4.6 Regression] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] |Relational operators .eq. |Relational operators .eq. |and == are not recognized |and == are not recognized |as equivalent |as equivalent --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-05-30 17:42:42 UTC --- Fixed on trunk, 4.6 and 4.5 to go.
[Bug rtl-optimization/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|target |rtl-optimization --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-30 17:54:19 UTC --- Recategorizing.
[Bug rtl-optimization/49235] New: [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 Summary: [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24398 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24398 reduced testcase (the same as gcc.c-torture/compile/pr36817.c) Compiler output: $ gcc -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model testcase.c testcase.c: In function 'foo': testcase.c:9:10: internal compiler error: in int_mode_for_mode, at stor-layout.c:424 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x11c8af0 /mnt/svn/gcc-trunk/gcc/stor-layout.c, line=424, function=0x11c8ee0 int_mode_for_mode) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x00939533 in int_mode_for_mode (mode=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/stor-layout.c:424 #2 0x006bdae2 in emit_move_via_integer (mode=VOIDmode, x=0x75c345e0, y=0x77ecc470, force=0 '\000') at /mnt/svn/gcc-trunk/gcc/expr.c:2921 #3 0x006cb8ea in emit_move_insn_1 (x=0x75c345e0, y=0x77ecc470) at /mnt/svn/gcc-trunk/gcc/expr.c:3296 #4 0x006cbc53 in emit_move_insn (x=0x75c345e0, y=0x77ecc470) at /mnt/svn/gcc-trunk/gcc/expr.c:3359 #5 0x006ad0bb in copy_to_reg (x=0x77ecc470) at /mnt/svn/gcc-trunk/gcc/explow.c:608 #6 0x006ae10f in memory_address_addr_space (mode=V4SImode, x=0x75c36438, as=0 '\000') at /mnt/svn/gcc-trunk/gcc/explow.c:480 #7 0x006c49f1 in expand_expr_real_1 (exp=0x75c319d8, target=0x0, tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=0x0) at /mnt/svn/gcc-trunk/gcc/expr.c:8690 #8 0x006d9cf8 in expand_expr (to=0x75c319d8, from=0x75c1fcd8, nontemporal=0 '\000') at /mnt/svn/gcc-trunk/gcc/expr.h:419 #9 expand_assignment (to=0x75c319d8, from=0x75c1fcd8, nontemporal=0 '\000') at /mnt/svn/gcc-trunk/gcc/expr.c:4406 #10 expand_assignment (to=0x75c319d8, from=0x75c1fcd8, nontemporal=0 '\000') at /mnt/svn/gcc-trunk/gcc/expr.c:4106 #11 0x005e6ce6 in expand_gimple_stmt_1 (stmt=0x75c37910) at /mnt/svn/gcc-trunk/gcc/cfgexpand.c:1953 #12 expand_gimple_stmt (stmt=0x75c37910) at /mnt/svn/gcc-trunk/gcc/cfgexpand.c:2050 #13 0x005e86ba in expand_gimple_basic_block (bb=0x75bb41a0) at /mnt/svn/gcc-trunk/gcc/cfgexpand.c:3633 #14 0x005eec67 in gimple_expand_cfg () at /mnt/svn/gcc-trunk/gcc/cfgexpand.c:4116 #15 0x0085e876 in execute_one_pass (pass=0x16adae0) at /mnt/svn/gcc-trunk/gcc/passes.c:1876 #16 0x0085eb65 in execute_pass_list (pass=0x16adae0) at /mnt/svn/gcc-trunk/gcc/passes.c:1930 #17 0x009b398d in tree_rest_of_compilation (fndecl=0x75bcf000) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:417 #18 0x00614cf5 in cgraph_expand_function (node=0x75bd4000) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1630 #19 0x0061697c in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1689 #20 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1952 #21 0x00616faa in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1126 #22 0x004fe148 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9844 #23 0x00948a74 in compile_file (argc=17, argv=0x7fffdb88) at /mnt/svn/gcc-trunk/gcc/toplev.c:586 #24 do_compile (argc=17, argv=0x7fffdb88) at /mnt/svn/gcc-trunk/gcc/toplev.c:1923 #25 toplev_main (argc=17, argv=0x7fffdb88) at /mnt/svn/gcc-trunk/gcc/toplev.c:1995 #26 0x76477cec in __libc_start_main () from /lib64/libc.so.6 #27 0x004e22ed in _start () Tested revisions: r174424 - crash 4.6 r173059 - OK
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Attachment #24364|0 |1 is obsolete|| --- Comment #14 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-30 18:48:27 UTC --- Created attachment 24399 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24399 Updated preliminary patch This updated patch resolves the issues identified so far. Please continue testing. I have regression tested and the testsuite case gfortran.dg/pr20755.f fails because with the patch I am ignoring the scale factor. Perhaps I have been too aggressive with that. Regardless, please continue testing while I study the scale factor question a bit more.
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 --- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-30 18:52:18 UTC --- At r174446, lto profiled bootstrap works fine on x86_64 darwin.
[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #9 from janus at gcc dot gnu.org 2011-05-30 19:28:52 UTC --- (In reply to comment #3) Here is a reduced test case for the duplicate SAVE attribute: The duplicate SAVE warning of comment #3 can be fixed with something like this: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 174416) +++ gcc/fortran/symbol.c(working copy) @@ -3400,7 +3400,8 @@ save_symbol (gfc_symbol *sym) if (sym-attr.in_common || sym-attr.dummy || sym-attr.result - || sym-attr.flavor != FL_VARIABLE) + || sym-attr.flavor != FL_VARIABLE + || (sym-name[0]=='_' sym-name[1]=='_')) return; /* Automatic objects are not saved. */ if (gfc_is_var_automatic (sym)) This prevents 'internal' symbols, starting with '__', from getting a SAVE attribute twice.
[Bug target/49168] [4.7 Regression] Aligned store used with unaligned address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49168 --- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-05-30 20:00:16 UTC --- Author: hjl Date: Mon May 30 20:00:11 2011 New Revision: 174451 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174451 Log: Handle misaligned TFmode load/store. gcc/ 2011-05-30 H.J. Lu hongjiu...@intel.com PR target/49168 * config/i386/i386.md (*movtf_internal): Handle misaligned load/store. gcc/testsuite/ 2011-05-30 H.J. Lu hongjiu...@intel.com PR target/49168 * gcc.target/i386/pr49168-1.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr49168-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 --- Comment #10 from janus at gcc dot gnu.org 2011-05-30 20:09:18 UTC --- (In reply to comment #6) string = dt%getFormattedString(0, FMT) 1 Error: 'getformattedstring' at (1) is not a member of the 'datetime' structure Here is a reduced test case for this error, which is also a regression: ... probably due to my r163631: http://gcc.gnu.org/viewcvs?view=revisionrevision=163631 It can be fixed by this partial revert: === --- gcc/fortran/resolve.c(revision 174415) +++ gcc/fortran/resolve.c(working copy) @@ -964,9 +964,6 @@ resolve_structure_cons (gfc_expr *expr, int init) t = SUCCESS; - if (expr-ts.type == BT_DERIVED) -resolve_symbol (expr-ts.u.derived); - cons = gfc_constructor_first (expr-value.constructor); /* A constructor may have references if it is the result of substituting a parameter variable. In this case we just pull out the component we
[Bug libstdc++/49236] New: [4.7 Regression] FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49236 Summary: [4.7 Regression] FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 174445 gave FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 633) FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for excess errors) Revision 174439 is OK.
[Bug libstdc++/49236] [4.7 Regression] FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49236 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-05-30 20:13:15 UTC --- This may be caused by revision 174443: http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg01224.html
[Bug tree-optimization/33498] Optimizer (-O2) may convert a normal loop to infinite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498 --- Comment #17 from Bruno.THOMAS at solucom dot fr 2011-05-30 20:24:31 UTC --- Je suis absent jusqu'au 6 juin 2011 et ne peux répondre à votre mail. En cas d'urgence, vous pouvez joindre le 01 49 03 20 50.
[Bug lto/49237] New: error with -flto: 'f' causes a section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49237
Summary: error with -flto:'f' causes a section type
conflict
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wouter.vermae...@scarlet.be
cat bug.cc
struct Bar;
struct Base1 {
virtual ~Base1();
};
templatetypename T struct Base2 {
virtual void f(T) = 0;
};
templatetypename struct Foo : Base1, Base2Bar {
virtual void f(Bar) {}
};
template struct FooBar;
g++-snapshot --version
g++-snapshot (GCC) 4.7.0 20110530 (experimental)
g++-snapshot bug.cc -c -flto
g++-snapshot bug.o -flto
In file included from bug.cc:8:0,
from :14:
bug.cc: In member function ‘f’:
bug.cc:9:15: error: f causes a section type conflict
Without the '-flto' option it works as expected.
This is on linux x86_64 (though I don't think this matters).
[Bug tree-optimization/33498] Optimizer (-O2) may convert a normal loop to infinite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-05-30 20:23:19 UTC --- I wonder what Clang/LLVM does here, since they seem to be trying really hard to handle undefined behaviour in a user-friendly way: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html#more
[Bug c/49233] Please un-deprecate rvalues in memory constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49233 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.30 20:31:55 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 20:31:55 UTC --- Surely not without a testcase that shows _why_ you need this.
[Bug tree-optimization/49234] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.30 20:44:22 Component|c |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-30 20:44:22 UTC --- Hum ... VRP ... Simulating block 15 Visiting statement: state_31 = ASSERT_EXPR state_3, state_3 != 0; Found new range for state_31: [1, +INF(OVF)] yeah, well ... !? We are entering the loop induction variable code and SCEV computes us this (not sure why we end up with the overflow flag set though).
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug libstdc++/49236] [4.7 Regression] FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49236 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-05-30 21:14:04 UTC --- Author: paolo Date: Mon May 30 21:14:01 2011 New Revision: 174455 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174455 Log: 2011-05-30 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/49236 * testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Adjust dg-warning line number. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/weak_ptr/comparison/cmp_neg.cc
[Bug libstdc++/49236] [4.7 Regression] FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49236 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-30 21:14:37 UTC --- Fixed.
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 Gerald Pfeifer gerald at pfeifer dot com changed: What|Removed |Added Target|x86_64-apple-darwin10, |x86_64-apple-darwin10, |sparc-sun-solaris2* |sparc-sun-solaris2*,x86_64- ||unknown-freebsd8.2 --- Comment #17 from Gerald Pfeifer gerald at pfeifer dot com 2011-05-30 21:15:29 UTC --- x86_64-unknown-freebsd8.2 is back in bootstrap land again.
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 --- Comment #18 from dave at hiauly1 dot hia.nrc.ca 2011-05-31 00:03:14 UTC --- Bootstrap restored on i686-apple-darwin9. Dave
[Bug target/49238] New: ICE in extract_insn, at recog.c:2113
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49238 Summary: ICE in extract_insn, at recog.c:2113 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: x86_64-linux-gnu Target: sh4-unknown-linux-gnu Build: x86_64-linux-gnu Created attachment 24400 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24400 preprocessed source ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: sh4-unknown-linux-gnu Configured with: ../configure --target=sh4-unknown-linux-gnu --prefix=/home/ryan/x-tools/sh4-unknown-linux-gnuc --with-local-prefix=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root --disable-multilib --with-sysroot=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root --with-newlib --enable-threads=no --disable-shared --enable-__cxa_atexit --disable-nls --enable-symvers=gnu --enable-languages=c --enable-target-optspace --enable-checking --disable-libmudflap --disable-libssp Thread model: single gcc version 4.7.0 20110530 (experimental) [trunk revision 174450] (GCC) $ ./xgcc -B. ~/ice.i -O1 /home/ryan/ice.i: In function 'foo': /home/ryan/ice.i:27:1: error: unrecognizable insn: (insn 61 60 62 3 (set (reg:SI 147 t) (geu:SI (reg:SI 3 r3 [ D.1975+4 ]) (const_int -1 [0x]))) /home/ryan/ice.i:21 -1 (nil)) /home/ryan/ice.i:27:1: internal compiler error: in extract_insn, at recog.c:2113 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/49239] New: Random gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49239 Summary: Random gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c failure Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: i...@gcc.gnu.org On Linux/ia32, gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c failed at random.
[Bug middle-end/49239] Random gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49239 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-05-31 04:55:41 UTC --- The error is: FAIL: gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c execution test
[Bug c/49233] Please un-deprecate rvalues in memory constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49233
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31
05:42:05 UTC ---
Yeah,
static inline int variable_test_bit(int nr, volatile const unsigned long *addr)
{
int oldbit;
asm volatile(bt %2,%1\n\tsbb %0,%0 : =r (oldbit) : m (*(unsigned long
*)addr), Ir (nr));
return oldbit;
}
unsigned long *a;
int
foo (int n)
{
return variable_test_bit (n, a);
}
doesn't warn, so we need a small self-contained preprocessed testcase that
reproduces it.
