A question about doloop
Hello,
Doloop optimization fails to be applied on the following kernel from
tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
iteration
case' message; taken from the loop2_doloop dump. (please see below).
With an older version of gcc (-r 146278) doloop succeeded to be applied
and I appreciate an explanation about the change of behavior.
Thanks,
Revital
The kernel:
unsigned int i, n = size;
int changed = 0;
for (i = 0; i n; i++)
{
const int tmp = *ap++ | (*bp++ *cp++);
changed |= *dstp ^ tmp;
*dstp++ = tmp;
}
The messages from loop2_doloop dump:
Doloop: Possible infinite iteration case.
Doloop: The loop is not suitable.
Loop 1 is simple:
simple exit 4 - 5
infinite if: (expr_list:REG_DEP_TRUE (ne:SI (and:DI (minus:DI (plus:DI
(ashift:DI (reg:DI 200)
(const_int 2 [0x2]))
(reg/v/f:DI 194 [ ap ]))
(reg:DI 168 [ ivtmp.19 ]))
(const_int 3 [0x3]))
(const_int 0 [0]))
(nil))
Re: A question about doloop
On Mon, 26 Jul 2010, Revital1 Eres wrote: Hello, Doloop optimization fails to be applied on the following kernel from tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite iteration case' message; taken from the loop2_doloop dump. (please see below). With an older version of gcc (-r 146278) doloop succeeded to be applied and I appreciate an explanation about the change of behavior. This may be due to changes in induction variable selection and the ability of loop2_doloop to discover number of iterations for different variants of IV selection (which is not trivial when 'i' variable is eliminated and loop boundary is expressed with pointer comparison). See PR32283 [1] audit trail for an example of a related problem that was discussed before. It is possible that something is missing in simplify-rtx.c so that 'infinite if' condition cannot be simplified and proven to be always false. Zdenek once had to improve simplify-rtx.c for this reason, as the audit trail shows. [1] http://gcc.gnu.org/PR32283 Hope that helps, Alexander
Re: GFDL/GPL issues
What if we ask the FSF if we can dual license the constraints.md files under both the GPL and the GFDL? Thanks for the update Mark. I agree that we are likely to get more traction with a request to dual license as opposed to re-license. Although I confess to lingering doubts as to the big picture. This implied documentation license algebra is quite weak and the imagined documentation production toolchains and procedures quite tortured. GPL indexes, but no GFDL direct linkages? Please. Not for the first time I find myself wishing the FSF spent more mental effort on documentation for free software, at every level. -benjamin
Re: GFDL/GPL issues
Benjamin Kosnik wrote: What if we ask the FSF if we can dual license the constraints.md files under both the GPL and the GFDL? I agree that we are likely to get more traction with a request to dual license as opposed to re-license. Well, I've asked -- but RMS shot down that idea. Not for the first time I find myself wishing the FSF spent more mental effort on documentation for free software, at every level. I (and I speak here not for the FSF, the SC, CodeSourcery, or anybody else) wish the FSF spent less time improving licenses and more time focused on making FSF software attractive to end users. I'm disappointed that a license improvement (changing GPL to GFDL on manuals) has made it impossible to do something that we, as developers, used to be able to do (when documentation was under the GPL we could move things back and forth between code and documentation at will), and which benefited users (by making it easier for us to generate better documentation). -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Mark Mitchell wrote: I'm disappointed that a license improvement (changing GPL to GFDL on manuals) has made it impossible to do something that we, as developers, used to be able to do (when documentation was under the GPL we could move things back and forth between code and documentation at will), and which benefited users (by making it easier for us to generate better documentation). I agree that it is essential to be able to do this kind of movement backwards and forwards.
Re: GFDL/GPL issues
Mark Mitchell m...@codesourcery.com writes: I agree that we are likely to get more traction with a request to dual license as opposed to re-license. Well, I've asked -- but RMS shot down that idea. Did he give reasons, and/or indicate any other possible methods to use? -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT]
[Bug tree-optimization/45071] New: [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in inhibit_phi_insertion, at tree-ssa-pre.c:3278 with -ftree-pre -ftree-vectorize
Command line: $ gcc -O -ftree-pre -ftree-vectorize testcase.c or $ gcc -O2 -ftree-vectorize testcase.c or $ gcc -O3 testcase.c Compiler output: $ gcc -O -ftree-pre -ftree-vectorize testcase.c testcase.c: In function 'f1': testcase.c:27:1: internal compiler error: tree check: expected ssa_name, have integer_cst in inhibit_phi_insertion, at tree-ssa-pre.c:3278 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r162456 - crash r162056 - crash r161659 - OK -- Summary: [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in inhibit_phi_insertion, at tree-ssa- pre.c:3278 with -ftree-pre -ftree-vectorize Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45071
[Bug tree-optimization/45071] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in inhibit_phi_insertion, at tree-ssa-pre.c:3278 with -ftree-pre -ftree-vectorize
--- Comment #1 from zsojka at seznam dot cz 2010-07-26 06:06 --- Created an attachment (id=21309) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21309action=view) reduced testcase (from g++.dg/opt/new1.C) Command line: $ gcc -O -ftree-pre -ftree-vectorize pr45071.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45071
[Bug tree-optimization/45072] New: [4.6 Regression] 23_containers/vector/bool/modifiers/erase/1.cc FAILs with -fprofile-generate
Output: $ g++ -O2 -fprofile-generate 1.ii $ rm 1.gcda $ ./a.out a.out: /mnt/svn/gcc-trunk/libstdc++-v3/testsuite/23_containers/vector/bool/modifiers/erase/1.cc:50: void test01(): Assertion `it1 == v.begin() + 1' failed. Aborted $ echo $? 134 Tested revisions: r162456 - broken r162056 - broken r161659 - OK -- Summary: [4.6 Regression] 23_containers/vector/bool/modifiers/erase/1.cc FAILs with -fprofile-generate Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45072
[Bug tree-optimization/45072] [4.6 Regression] 23_containers/vector/bool/modifiers/erase/1.cc FAILs with -fprofile-generate
--- Comment #1 from zsojka at seznam dot cz 2010-07-26 06:18 --- Created an attachment (id=21310) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21310action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45072
[Bug target/42240] wrong epilogue on naked function
--- Comment #10 from anitha dot boyapati at atmel dot com 2010-07-26 06:49 --- Bug can be confirmed with 4.4.3 version also (With -O2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
[Bug tree-optimization/45073] New: [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
Command line: $ gfortran -O -finline-small-functions -fprofile-generate assumed_charlen_function_3.f90 or $ gfortran -O2 -fprofile-generate assumed_charlen_function_3.f90 Valgrind output: $ valgrind -q --trace-children=yes /mnt/svn/gcc-trunk/binary-162456-lto-fortran-checking-yes-rtl-df/bin/gfortran -O2 -fprofile-generate assumed_charlen_function_3.f90 ==893== Invalid read of size 4 ==893==at 0x10628D0: htab_find_with_hash (hashtab.c:272) ==893==by 0x927A7E: referenced_var_check_and_insert (tree-dfa.c:512) ==893==by 0x928276: add_referenced_var (tree-dfa.c:583) ==893==by 0x9283AE: find_new_referenced_vars_1 (tree-dfa.c:677) ==893==by 0xA79096: walk_tree_1 (tree.c:10166) ==893==by 0xA791CA: walk_tree_1 (tree.c:10415) ==893==by 0x764D74: walk_gimple_op (gimple.c:1358) ==893==by 0xF7F95A: gimplify_and_update_call_from_tree (gimple-fold.c:856) ==893==by 0xF813E8: fold_gimple_call (gimple-fold.c:1425) ==893==by 0xF81B60: fold_stmt_1 (gimple-fold.c:1504) ==893==by 0xB3722E: fold_marked_statements (tree-inline.c:4086) ==893==by 0xB3E324: optimize_inline_calls (tree-inline.c:4220) ==893== Address 0x68 is not stack'd, malloc'd or (recently) free'd ==893== assumed_charlen_function_3.f90: In function 'MAIN__': assumed_charlen_function_3.f90:30:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with - fprofile-generate Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug tree-optimization/45073] [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
--- Comment #1 from dominiq at lps dot ens dot fr 2010-07-26 07:27 --- Confirmed. From the builds I have at hand, it appeared between revisions 158921 (branch fortran-dev) and 162490 (trunk). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug tree-optimization/45073] [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
--- Comment #2 from zsojka at seznam dot cz 2010-07-26 07:33 --- Thank you for the answer. gfortran.dg/char_pointer_func.f90 and gfortran.dg/function_charlen_2.f90 fail the same way, with similiar backtrace $ gfortran -O2 -fprofile-generate char_pointer_func.f90 char_pointer_func.f90: In function 'char_pointer_func': char_pointer_func.f90:27:0: internal compiler error: Segmentation fault $ gfortran -O2 -fprofile-generate function_charlen_2.f90 function_charlen_2.f90: In function 'test': function_charlen_2.f90:18:0: internal compiler error: Segmentation fault Revisions tested: r162456 - crash r161659 - crash r161170 - OK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug target/44290] [4.5 only] __naked attribute is broken
--- Comment #24 from ramana at gcc dot gnu dot org 2010-07-26 08:05 --- If this is fixed, the target milestone should be 4.6.0 and not 4.5.1 . I thought this was a regression on the 4.5 branch and given that the branch is now locked down for 4.5.1 the target milestone ought to be 4.5.2 and this patch should also be backported to the 4.5 branch. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.5 Regression] __naked|[4.5 only] __naked attribute |attribute is broken |is broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug c++/45074] New: GCC Segmentation fault - negating global register variables
When compiling the following example using language c++ (compiling in language
c works fine) and optimization level -O1 or higher (-O0 works fine) GCC 4.4.1
for MIPS crashes with an internal compiler error - segmentation fault in line
5.
Please note that the register variable is declared double, when using float
type the error does not occur.
gcc -O1 -x c++ test_neg_float_register.c
-test_neg_float_register.c--
register double g_param_f64_1 __asm__($f20);
void negate_float_register (void)
{
g_param_f64_1 = -(g_param_f64_1);
}
See attachment for example file.
The error is reproducible with GCC version 4.3.2 and 4.4.1 and optimization
level higher -O0 (that is -O1, -O2, -O3).
--
Summary: GCC Segmentation fault - negating global register
variables
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steffenschmidt dot ext at siemens dot com
GCC host triplet: MinGW
GCC target triplet: mips*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45074
[Bug c++/45074] GCC Segmentation fault - negating global register variables
--- Comment #1 from steffenschmidt dot ext at siemens dot com 2010-07-26 08:14 --- Created an attachment (id=21311) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21311action=view) Test file to reproduce the segmentation fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45074
[Bug middle-end/45075] New: Optimization failure about user-defined sections
Hello,
as we noticed there is an new optimization failure about user-defined sections
and loops.
The following code works for me with -O0, but fails with -O2.
extern void abort (void);
static long long start __attribute__ ((section (.my_sec$A))) = 0;
static long long end __attribute__ ((section (.my_sec$Z))) = 2;
int main()
{
long long *p;
for (p = (start + 1); p != end; p++)
if (*p == 2)
abort();
return 0;
}
--
Summary: Optimization failure about user-defined sections
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45075
[Bug middle-end/45075] Optimization failure about user-defined sections
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-07-26 08:43 --- Version used $ /usr/local/bin/x86_64-pc-mingw32-gcc.exe -v Using built-in specs. COLLECT_GCC=/usr/local/bin/x86_64-pc-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-mingw32/4.6.0/lto-wrapper.exe Target: x86_64-pc-mingw32 Configured with: ../gcc/configure --target=x86_64-pc-mingw32 --enable-lto target _alias=x86_64-pc-mingw32 --enable-languages=c,c++,fortran,java,lto,objc --no-create --no-recursion : (reconfigured) ../gcc/configure --target=x86_64-pc-mingw32 --enable-lto target_alias=x86_64-pc-mingw32 --enable-languages=c,c++,fortran,java,lto,objc --no-create --no-recursion Thread model: win32 gcc version 4.6.0 20100726 (experimental) (GCC) This issue could be also LTO related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45075
[Bug c++/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #2 from mikpe at it dot uu dot se 2010-07-26 08:49 --- With -Os on armv5tel I see a random number repeated 16 times, with -O2 I see the expected output. gcc-4.4 and gcc-4.5 are affected. (Can't test 4.6 or 4.3 right now.) -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug middle-end/45075] Optimization failure about user-defined sections
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-07-26 08:52 --- The test fails for me for any type != char for section variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45075
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #4 from ramana at gcc dot gnu dot org 2010-07-26 08:55 --- I see the same issue in my nightly armv7-a bootstrap. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-26 08:55:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug middle-end/37060] [4.3/4.4/4.5/4.6 regression] Bogus __builtin___memcpy_chk overflow warning
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-07-26 09:06 --- (In reply to comment #11) I think this testcase has some other issues at least on the trunk. sparc_floating_p.isra.0 is produced for 32bit but not 64bit. And then we have: MEM[(const struct type *)type_1(D)].code; Why didn't we just produce an indirect reference here as the const should be able to be ignored? (CCing Richard about that part). There are no more INDIRECT_REFs. The above is type_1-code, just not pretty printed as such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37060
[Bug tree-optimization/45052] [4.5/4.6 Regression] volatile ignored
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-26 09:27 --- Subject: Bug 45052 Author: rguenth Date: Mon Jul 26 09:26:43 2010 New Revision: 162528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162528 Log: 2010-07-26 Richard Guenther rguent...@suse.de PR tree-optimization/45052 * ipa-pure-const.c (check_stmt): Check volatileness. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052
[Bug middle-end/45075] Optimization failure about user-defined sections
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-26 09:28 --- The testcase is invalid. Comparing pointers to different objects has undefined behavior. If you want to do something like this, you either need to cast to uintptr_t and do comparisons in that type, or hide where the pointers point to from the compiler (e.g. using inline-asm). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45075
[Bug c++/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #3 from mikpe at it dot uu dot se 2010-07-26 09:33 --- Created an attachment (id=21312) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21312action=view) reduced test case in C You don't need C++ to trigger the bug. Proper C with a function that may recurse before returning a packed struct suffices. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug fortran/45066] [4.6 Regression] ICE in namelist read in snapshot of 7/24/2010
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-26 09:42 --- (In reply to comment #2) --- trans-io.c (revision 162507) +++ trans-io.c (working copy) + if (base_addr == NULL) +return; + This does not make sense if you call transfer_namelist_element in build_dt with the arguments: transfer_namelist_element (block, nml-sym-name, nml-sym, NULL, NULL); The last argument is tree base_addr. (By the way, I think that should be NULL_TREE and not NULL.) Besides, the issue seems to be rather: dt = TREE_TYPE ((sym) ? sym-backend_decl : c-backend_decl); dtype = gfc_get_dtype (dt); which makes more sense in terms of fwhole-file; the problem is that sym-backend_decl = NULL. It seems as if the following patch fixes this. With -fno-whole-file the sym-backend_decl is set and one returns the decl. With -fwhole-file only the decl was returned. I wonder how many other issues this patch fixes. Note: I tested it for the example in comment 0, but I have not yet tested it against gfortran's test suite. Index: trans-io.c === --- trans-io.c (revision 162526) +++ trans-io.c (working copy) @@ -1760,7 +1760,7 @@ build_dt (tree function, gfc_code * code for (nml = dt-namelist-namelist; nml; nml = nml-next) transfer_namelist_element (block, nml-sym-name, nml-sym, - NULL, NULL); + NULL, NULL_TREE); } else set_parameter_const (block, var, IOPARM_common_flags, mask); Index: trans-decl.c === --- trans-decl.c(revision 162526) +++ trans-decl.c(working copy) @@ -1150,7 +1150,8 @@ gfc_get_symbol_decl (gfc_symbol * sym) true); if (sym-ts.type == BT_CHARACTER) sym-ts.u.cl-backend_decl = s-ts.u.cl-backend_decl; - return s-backend_decl; + sym-backend_decl = s-backend_decl; + return sym-backend_decl; } } } -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-25 14:26:17 |2010-07-26 09:42:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #71 from burnus at gcc dot gnu dot org 2010-07-26 09:53 --- Subject: Bug 40011 Author: burnus Date: Mon Jul 26 09:53:19 2010 New Revision: 162531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162531 Log: Add file forgotten in commit Rev. 162500 2010-07-24 Tobias Burnus bur...@net-b.de PR fortran/40011 * gfortran.dg/whole_file_21.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_21.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug c++/43824] C++0x feature inline namespace enabled under -std=c++98; no warnings
--- Comment #5 from rodrigorivascosta at gmail dot com 2010-07-26 09:59 --- Created an attachment (id=21313) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21313action=view) Patch to add pedantic warning to inline namespaces in C++98 I think that this tiny patch should do the trick. Regards. -- Rodrigo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43824
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #14 from borntraeger at de dot ibm dot com 2010-07-26 10:13 --- I have seen the original problem only with bitfields. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug fortran/45066] [4.6 Regression] ICE in namelist read in snapshot of 7/24/2010
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-26 10:31 --- Subject: Bug 45066 Author: burnus Date: Mon Jul 26 10:30:45 2010 New Revision: 162532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162532 Log: 2010-07-26 Tobias Burnus bur...@net-b.de PR fortran/45066 * trans-io.c (build_dt): Use NULL_TREE rather than NULL for call to transfer_namelist_element. * trans-decl.c (gfc_get_symbol_decl): Also set sym-backend_decl for -fwhole-file. 2010-07-26 Tobias Burnus bur...@net-b.de PR fortran/45066 * gfortran.dg/namelist_62.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_62.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug fortran/45066] [4.6 Regression] ICE in namelist read in snapshot of 7/24/2010
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-26 10:32 --- (In reply to comment #8) I wonder how many other issues this patch fixes. Seemingly none of those -fwhole-file/-fwhole-program issues which I wanted to see fixed :-( Well, at least this PR is now FIXED. Thanks for the bug report! (As with all -fwhole-file patches: I think I won't backport them to 4.5. Howvever, if someone wants to do it, feel free to do so.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45066
[Bug tree-optimization/45071] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in inhibit_phi_insertion, at tree-ssa-pre.c:3278 with -ftree-pre -ftree-vectorize
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-26 10:33 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-26 10:33:53 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45071
[Bug tree-optimization/45072] [4.6 Regression] 23_containers/vector/bool/modifiers/erase/1.cc FAILs with -fprofile-generate
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45072
[Bug tree-optimization/45073] [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug rtl-optimization/45061] [4.6 Regression] ICE: in check_allocation, at ira.c:1677 with -O2 -ftracer -fira-coalesce
--- Comment #3 from bernds at gcc dot gnu dot org 2010-07-26 11:00 --- Vlad intends to remove flag_ira_coalesce anyway, so there's probably not too much point investigating this. -- bernds at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45061
[Bug tree-optimization/45056] [4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1023
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-26 11:00 --- Invalid MEMs in debug-insns (invalid as in not folded). Why does the scheduler query the alias oracle about them? (debug_insn 49 48 50 7 t.cc:22 (var_location:DI D#3 (mem/s/f/j:DI (plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -32 [0xffe0])) [0 MEM[(struct vector *)qq.seq]._M_finish+0 S8 A256])) -1 (nil)) CCP does - D.2433_12 = qq.seq; - # DEBUG this = D.2433_12 - # DEBUG D#3 = MEM[(struct vector *)D.2433_12]._M_finish - # DEBUG this = D.2433_12 + # DEBUG this = qq.seq + # DEBUG D#3 = MEM[(struct vector *)qq.seq]._M_finish + # DEBUG this = qq.seq I have a patch to fix it there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45056
[Bug tree-optimization/45073] [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-26 11:34 --- Introduced by r161655 aka MEM-REF merge. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-26 11:34:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug c/45062] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in start_decl, at c-decl.c:4064
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-26 11:47 --- This is caused also by http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00577.html but likely unrelated to the other PR, this is in C FE, that one is in C++ FE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45062
[Bug tree-optimization/44997] [4.6 regression] tree-chrec introduces broken asm code
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-26 11:51 --- Isn't this dup of PR45075? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44997
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-07-26 12:21 --- One of the issues is /* For a MEM rtx, the alignment in bits. We can use the alignment of the mode as a default when STRICT_ALIGNMENT, but not if not. */ #define MEM_ALIGN(RTX) \ (MEM_ATTRS (RTX) != 0 ? MEM_ATTRS (RTX)-align \ : (STRICT_ALIGNMENT GET_MODE (RTX) != BLKmode \ ? GET_MODE_ALIGNMENT (GET_MODE (RTX)) : BITS_PER_UNIT)) this might be true during RTL, but certainly during expansion this is wrong. It invents alignment out of thin air. Invented by Kenner via +Tue Oct 23 13:05:53 2001 Richard Kenner ken...@vlsi1.ultra.nyu.edu + ... + * rtl.h (MEM_ALIGN): Take default from mode, if not BLKmode, and + change default if unknown from 1 to BITS_PER_UNIT. and fixed up partly +Sun Jan 27 13:23:40 2002 Richard Kenner ken...@vlsi1.ultra.nyu.edu + + * emit-rtl.c (get_mem_attrs): Don't default alignment for non-BLKmode + if not STRICT_ALIGNMENT. + * rtl.h (MEM_ALIGN): Likewise. which conditionalized it on STRICT_ALIGNMENT. But store_field still tries to compare MEM_ALIGN for alignment. This could have never worked properly. Thus, for stores I can fix it by doing Index: gcc/emit-rtl.c === --- gcc/emit-rtl.c (revision 162526) +++ gcc/emit-rtl.c (working copy) @@ -1543,7 +1543,7 @@ set_mem_attributes_minus_bitpos (rtx ref tree expr = MEM_EXPR (ref); rtx offset = MEM_OFFSET (ref); rtx size = MEM_SIZE (ref); - unsigned int align = MEM_ALIGN (ref); + unsigned int align = MEM_ATTRS (ref) ? MEM_ALIGN (ref) : BITS_PER_UNIT; HOST_WIDE_INT apply_bitpos = 0; tree type; Index: gcc/expr.c === --- gcc/expr.c (revision 162526) +++ gcc/expr.c (working copy) @@ -4168,7 +4168,7 @@ expand_assignment (tree to, tree from, b Assignment of an array element at a constant index, and assignment of an array element in an unaligned packed structure field, has the same problem. */ - if (handled_component_p (to) + if (1 || handled_component_p (to) /* ??? We only need to handle MEM_REF here if the access is not a full access of the base object. */ || (TREE_CODE (to) == MEM_REF but unaligned loads are not fixed by that. Pre-existing mess. I am not qualified to stir it more. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug tree-optimization/45059] [4.6 Regression] error: invalid operands in binary operation, leads to ICE: verify_stmts failed
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-26 12:39 ---
Simplified testcase:
typedef unsigned int T;
extern void foo (unsigned char *, int);
static signed char a;
static T b[1] = { -1 };
static unsigned char c;
static inline short int
bar (short v)
{
c |= a b[0];
return 0;
}
int
main ()
{
unsigned char *e = a;
foo (e, bar (bar (c)));
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45059
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-26 12:45 --- Created an attachment (id=21314) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21314action=view) patch Please check whether the attached patch fixes the testcase this bug is about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-07-26 12:45 --- Mine again (only for restoring the pre-MEM_REF behavior). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-23 12:14:22 |2010-07-26 12:45:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug tree-optimization/45071] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in inhibit_phi_insertion, at tree-ssa-pre.c:3278 with -ftree-pre -ftree-vectorize
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-26 12:48 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45071
[Bug tree-optimization/45071] [4.6 Regression] ICE: tree check: expected ssa_name, have integer_cst in inhibit_phi_insertion, at tree-ssa-pre.c:3278 with -ftree-pre -ftree-vectorize
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-26 12:49 --- Subject: Bug 45071 Author: rguenth Date: Mon Jul 26 12:48:37 2010 New Revision: 162534 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162534 Log: 2010-07-26 Richard Guenther rguent...@suse.de PR tree-optimization/45071 * tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Always adjust op-opcode. * gcc.dg/pr45071.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr45071.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45071
[Bug tree-optimization/45076] New: gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use
Command line: $ gfortran -O[0123] -fprofile-generate dynamic_dispatch_6.f03 $ rm dynamic_dispatch_6.gcda $ ./a.out $ gfortran -O[0123] -fprofile-use dynamic_dispatch_6.f03 Compiler output: $ gfortran -fprofile-generate dynamic_dispatch_6.f03 $ rm dynamic_dispatch_6.gcda $ ./a.out $ gfortran -fprofile-use dynamic_dispatch_6.f03 dynamic_dispatch_6.f03: In function 'MAIN__': dynamic_dispatch_6.f03:59:0: error: invalid conversion in gimple call struct class$field_p struct class$field_p D.1711 = new_periodic_5th_order (field_creator); dynamic_dispatch_6.f03:59:0: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r162456 - crash r158095 - crash 4.5 r160526 - crash -- Summary: gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile- use Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45076
[Bug tree-optimization/45059] [4.6 Regression] error: invalid operands in binary operation, leads to ICE: verify_stmts failed
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-26 12:58 --- Works if b[] has unsigned int type instead of T. Sounds like a type mismatch. The VAR_DECL b has ARRAY_TYPE with T element type and b's CONSTRUCTOR has the same type, but the values in the constructor doesn't have T type, but unsigned int: constructor 0x71f2f420 type array_type 0x71f23498 type integer_type 0x71f232a0 T unsigned SI size integer_cst 0x7202d708 constant 32 unit size integer_cst 0x7202d410 constant 4 align 32 symtab 0 alias set -1 canonical type 0x72042540 precision 32 min integer_cst 0x7202d730 0 max integer_cst 0x7202d6e0 4294967295 pointer_to_this pointer_type 0x71f23540 SI size integer_cst 0x7202d708 32 unit size integer_cst 0x7202d410 4 align 32 symtab 0 alias set -1 canonical type 0x71f235e8 domain integer_type 0x72055690 type integer_type 0x72042000 long unsigned int DI size integer_cst 0x7202d7d0 constant 64 unit size integer_cst 0x7202d7f8 constant 8 align 64 symtab 0 alias set -1 canonical type 0x72055690 precision 64 min integer_cst 0x7202d438 0 max integer_cst 0x7202d438 0 constant static lngt 1 idx integer_cst 0x7202db40 type integer_type 0x720420a8 bit_size_type constant 0 val integer_cst 0x7202d6e0 type integer_type 0x72042540 unsigned int constant 4294967295 When ccp propagates b[0] into the comparison, the comparison uses T on one side and unsigned int on the other side. When b has T type, ccp doesn't optimize the ... 4294967295 comparison into ... != 4294967295, while when b has unsigned int type, it does. T's TYPE_MAIN_VARIANT is unsigned int. So, it isn't clear if the middle-end is considering the two types as incompatible or what. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45059
[Bug fortran/45077] New: ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021
+++ This bug was initially created as a clone of Bug #40011 +++ The program of PR 40011 comment 47 (attachment 18427) works -fno-whole-file but fails otherwise with an ICE in fold_convert_loc, at fold-const.c:2021. -- Summary: ICE with -fwhole-file in fold_convert_loc, at fold- const.c:2021 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 40011 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #72 from burnus at gcc dot gnu dot org 2010-07-26 13:15 --- (In reply to comment #70) With the patch of PR 40873 comment 18 applied [...] There is now a new patch which fixes tons of issues including the test case of comment 0 number 4, but not the one from comment 47. Are there still remaining issues, and if so which? I think this PR gets too long to have an overview... I only found the one in comment 47: Works -fno-whole-file but fails otherwise with an ICE in fold_convert_loc, at fold-const.c:2021. I have now filled PR 45077 to track that issue. If you find a new issue - or if there is a left over, which I have missed, please fill a new PR. Thus: Close as FIXED. Thanks to all involved for the bug reporting and fixing! -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|45077 | nThis|| Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING
--- Comment #9 from dominiq at lps dot ens dot fr 2010-07-26 13:25 --- Note that since revision 162531 (-fwhole-file is now the default) the tests in this pr no longer give ICEs. However these ICEs reappear when the tests are compiled with -fno-whole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #23 from burnus at gcc dot gnu dot org 2010-07-26 13:25 --- Created an attachment (id=21315) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21315action=view) New trans-decl.c patch - seems to work well New patch. Found the problem with the help of Jakub (thanks!); not yet regtested but it works with the previously failing examples. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug tree-optimization/45073] [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-26 13:26 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-26 11:34:34 |2010-07-26 13:26:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug tree-optimization/45056] [4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1023
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-26 13:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45056
[Bug tree-optimization/45056] [4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1023
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-26 13:29 --- Subject: Bug 45056 Author: rguenth Date: Mon Jul 26 13:29:14 2010 New Revision: 162536 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162536 Log: 2010-07-26 Richard Guenther rguent...@suse.de PR middle-end/45056 * gimple-fold.c (fold_stmt_1): Also fold references in debug stmts. * g++.dg/pr45056.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr45056.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45056
[Bug fortran/40994] ICE in gfc_undo_symbols
--- Comment #7 from dominiq at lps dot ens dot fr 2010-07-26 13:30 --- This pr looks like a duplicate of pr37744, or at least the ICEs disappear with -fwhole-file (now the default: see http://gcc.gnu.org/ml/gcc-bugs/2010-07/msg02853.html#c9 ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40994
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-26 13:31 --- (In reply to comment #9) Note that since revision 162531 (-fwhole-file is now the default) the tests in this pr no longer give ICEs. However these ICEs reappear when the tests are compiled with -fno-whole-file. Then, I am inclined to close it as WONTFIX. As written elsewhere: -fno-whole-file is deprecated and I want to remove it early in 4.7 (though others disagree). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING
--- Comment #11 from dominiq at lps dot ens dot fr 2010-07-26 13:45 --- (In reply to comment #10) Note that since revision 162531 (-fwhole-file is now the default) the tests in this pr no longer give ICEs. However these ICEs reappear when the tests are compiled with -fno-whole-file. Then, I am inclined to close it as WONTFIX. As written elsewhere: -fno-whole-file is deprecated and I want to remove it early in 4.7 (though others disagree). Well, I am among those who disagree. I think the flag -fno-whole-file will be quite useful to locate remaining failure due to -fwhole-file and I seriously doubt that the list will be exhausted before stage 3 of 4.7 (in addition I don't see the interest of irregular options: if you want to get rid of the -fno-whole-file, you should also remove -fwhole-file and all the associated machinery!-). I think this PR should be left open as P5 and enhancement. If some day the options -f(no-)?while-file and the corresponding code are removed, then it could be close as wontfiw or invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug fortran/45076] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-26 13:56 --- struct class$field_p struct class$field_p looks more like a frontend issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45076
[Bug plugins/45078] New: config/vxworks-dummy.h not installed as a plugin header on some archs
dehydra fails to build with the following error: /usr/bin/gcc-4.5 -MD -g3 -Wall -fPIC -DXP_UNIX -DIN_GCC -DPLUGIN_NO_POISON -DHAVE_CONFIG_H -I/usr/lib/gcc/sparc-linux-gnu/4.5.1/plugin/include -I/usr/include/mozjs -I/usr/lib -I//home/buildd/local/include/js/ -g -O2 -c dehydra_plugin.c In file included from /usr/lib/gcc/sparc-linux-gnu/4.5.1/plugin/include/tm.h:16:0, from gcc_cp_headers.h:40, from dehydra_plugin.c:28: /usr/lib/gcc/sparc-linux-gnu/4.5.1/plugin/include/config/sparc/sparc.h:25:34: fatal error: config/vxworks-dummy.h: No such file or directory $ fgrep -r vxworks-dummy.h src/gcc/config src/gcc/config/arm/arm.h:#include config/vxworks-dummy.h src/gcc/config/i386/i386.h:#include config/vxworks-dummy.h src/gcc/config/sparc/sparc.h:#include config/vxworks-dummy.h src/gcc/config/sh/sh.h:#include config/vxworks-dummy.h src/gcc/config/mips/mips.h:#include config/vxworks-dummy.h on ix86 this is added to tm_h in config.gcc, and tm_h files are installed as plugin header files. the file is included on other archs too, but not added to tm_h. so either always install it as a plugin header, or add it to tm_h on these architectures too? -- Summary: config/vxworks-dummy.h not installed as a plugin header on some archs Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45078
[Bug tree-optimization/45059] [4.6 Regression] error: invalid operands in binary operation, leads to ICE: verify_stmts failed
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-26 14:15 --- The reassoc issue is caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=159189 BTW, the C++ FE uses T instead of unsigned type for values in the ctor and thus the testcase works there. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||sandra at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45059
[Bug c/45079] New: function names in error message (�c_maybe_const_expr� not supported by 'pp_c_expression')
4.4 doesn't print the function names in the error message, while 4.5 and 4.6 do
so:
$ cat foo.c
void foo(const char *p, int cond, int a, int b)
{
p[cond ? a : b] = '\0';
}
$ gcc-4.4 -c foo.c
foo.c: In function 'foo':
foo.c:3: error: assignment of read-only location '*(p + (cond != 0 ? (long
unsigned int)(long unsigned int)a : (long unsigned int)(long unsigned int)b))'
$ gcc-4.5 -c foo.c
#'c_maybe_const_expr' not supported by pp_c_expression#) != 0 ? (long unsigned
int)a : (long unsigned int)b) * 1ul))'foo.c: In function 'foo':
foo.c:3:2: error: assignment of read-only location
is the new format expected?
--
Summary: function names in error message
(�c_maybe_const_expr� not supported by
'pp_c_expression')
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45079
[Bug c++/45080] New: [C++0x] Rejects lambda to function pointer conversion inside function template
cat lambda-convX.C
// { dg-options -std=c++0x }
typedef void(*pfn)();
templateint = 0
void f1 ()
{
pfn fn = []{};
}
templatetypename = int
void f2()
{
pfn fn = []{};
}
void test()
{
f1();
f2();
}
[p...@a tmp] g++-trunk -v lambda-convX.C -c -std=c++0x
Using built-in specs.
COLLECT_GCC=/home/prak/Dev/gcc-install/bin/g++-trunk
COLLECT_LTO_WRAPPER=/home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc.git/configure --enable-languages=c,c++
--program-suffix=-trunk --prefix=/home/prak/Dev/gcc-install --disable-bootstrap
: (reconfigured) ../gcc.git/configure --enable-languages=c,c++
--program-suffix=-trunk --prefix=/home/prak/Dev/gcc-install --disable-bootstrap
: (reconfigured) ../gcc.git/configure --program-suffix=-trunk
--prefix=/home/prak/Dev/gcc-install --disable-bootstrap
--enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20100725 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
/home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -quiet
-v -D_GNU_SOURCE lambda-convX.C -quiet -dumpbase lambda-convX.C -mtune=generic
-march=pentiumpro -auxbase lambda-convX -std=c++0x -version -o /tmp/ccwd0zJD.s
GNU C++ (GCC) version 4.6.0 20100725 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/i686-pc-linux-gnu
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
/home/prak/Dev/gcc-install/include
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/include
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.6.0 20100725 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 4866727cef69d58d8539d96f2ebb2a27
lambda-convX.C: In function âvoid f1() [with int anonymous = 0]â:
lambda-convX.C:20:10: instantiated from here
lambda-convX.C:9:19: error: cannot convert âf1() [with int anonymous =
0]::lambda()â to âpfnâ in initialization
lambda-convX.C: In function âvoid f2() [with template-parameter-1-1 =
int]â:
lambda-convX.C:21:10: instantiated from here
lambda-convX.C:15:19: error: cannot convert âf2() [with
template-parameter-1-1 = int]::lambda()â to âpfnâ in initialization
--
Summary: [C++0x] Rejects lambda to function pointer conversion
inside function template
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot rak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45080
[Bug c++/45080] [C++0x] Rejects lambda to function pointer conversion inside function template
--- Comment #1 from piotr dot rak at gmail dot com 2010-07-26 14:21 --- Created an attachment (id=21316) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21316action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45080
[Bug target/44290] [4.5 only] __naked attribute is broken
--- Comment #25 from jiez at gcc dot gnu dot org 2010-07-26 14:37 --- Ramana, I will ask for permission to commit it on 4.5 branch when it's unfrozen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug c/45079] function names in error message (�c_maybe_const_expr� not supported by 'pp_c_expression')
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-26 14:47 --- Created an attachment (id=21317) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21317action=view) gcc46-pr45079.patch Untested fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45079
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] safe conversion from unsigned to signed char gives broken code
--- Comment #7 from rakdver at gcc dot gnu dot org 2010-07-26 14:47 ---
By the time the code reaches ivopts, it looks (modulo SSA form) this way:
signed char x = -128, tmp;
for (;;)
{
tmp = -x;
foo ((int) x, (int) tmp, x==-128);
...
if (x == 127)
break;
x++;
}
Note that all the careful handling of -x in case that x=-128 disappeared.
Then, ivopts trust that signed arithmetics does not overflow, and misscompile
the program. In fact, it seems that the error is already there at the very
beginning: the .original dump shows
fixnum_neg
{
ux = (unsigned char) x;
uy = (unsigned char) -(signed char) ux;
...
}
That is, the negation of unsigned char value is implemented by casting it to
signed char, which introduces signed overflow if the value of x is -128. As
far as I understand the C standard, this seems incorrect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug tree-optimization/45073] [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-26 14:49 --- Subject: Bug 45073 Author: rguenth Date: Mon Jul 26 14:48:43 2010 New Revision: 162537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162537 Log: 2010-07-26 Richard Guenther rguent...@suse.de PR middle-end/45073 * gimple-fold.c (gimplify_and_update_call_from_tree): Conditionalize SSA updating on being in SSA form. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug tree-optimization/45073] [4.6 Regression] gfortran.dg/assumed_charlen_function_3.f90 ICEs with -fprofile-generate
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-26 14:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45073
[Bug tree-optimization/43784] [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution
--- Comment #9 from matz at gcc dot gnu dot org 2010-07-26 15:06 ---
Here's a testcase (nicer in the sense of not requiring inlining) that shows
the current compiler botching the nrv - retslot optimizations:
struct S {int x, y, makemelarge[5];};
S __attribute__((noinline)) f (S s) {
S r;
r.x = s.y;
r.y = s.x;
return r;
}
int __attribute__((noinline)) glob (int a, int b)
{
S local = { a, b };
local = f (local);
return local.y;
}
extern C void abort (void);
int main (void)
{
if (glob (1, 3) != 1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43784
[Bug fortran/45081] New: ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
The following code, with default options, module m implicit none type t integer :: i end type t type(t), dimension(1), parameter :: a1 = (/ t(1) /) type(t), dimension(1), parameter :: a = reshape ( (/ a1 /), (/ 1 /) ) end module m triggers: f951: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:4208 in GNU Fortran (GCC) 4.6.0 20100726 (experimental) The code compiles with the NAG compiler, as it should. gfortran also compiles the equivalent code for INTEGERS instead of the derived type. Maybe there is a relation to bug #44742. -- Summary: ICE in gfc_conv_array_initializer, at fortran/trans- array.c:4208 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ohl at physik dot uni-wuerzburg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug fortran/45081] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
--- Comment #1 from dominiq at lps dot ens dot fr 2010-07-26 15:22 --- Confirmed as a regression: it compiles with 4.2.4 (ppc-darwin), gives an ICE with 4.3.4, 4.4.2, 4.5.0 and trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug c++/45082] New: Static const signed int class member causes undefined symbol.
A class that has a static const signed int data member when passed to a
function as a const int parameter will cause the data member to be an
undefined symbol. If the static const signed int data member is re-typed as
const unsigned int the error goes away. I've verified this on g++ 3.4.6 and
4.1.2. The following code example illustrates the error.
#include stdio.h
static const signed int GLOBAL_BUFF_SIZE=30;
class myclass
{
public:
static const int BUFF_SIZE = 20; // Causes linker error.
//static const signed int BUFF_SIZE = 20; // Causes linker error.
//static const unsigned int BUFF_SIZE = 20; // No linker error.
static const int ANOTHER_BUFF_SIZE;
int myArray[BUFF_SIZE];
/* Linker error.
% g++ static2.cpp
Undefined first referenced
symbol in file
myclass::BUFF_SIZE /var/tmp//cc2IHYwP.o
ld: fatal: Symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status
% g++ --version
g++ (GCC) 3.4.6
and
g++ (GCC) 4.1.2
% ccppc --version
ccppc (Wind River VxWorks G++ DWARF-EH 4.1-131) 4.1.2
*/
};
// This solves the linker problem.
// Not an option for me. I need to dimension an array with BUFF_SIZE.
const int myclass::ANOTHER_BUFF_SIZE=20;
// Function that takes a constant reference to an integer.
// When a static const signed int is passed to this function
// that was defined in a class, you get the linker error.
// If that static const is declared unsigned int, you dont get the error.
// When the reference is to a global static, there is no error.
void funky(const int in)
{
printf(What came into funky() was %d\n, in);
}
int main()
{
printf(%d\n, myclass::BUFF_SIZE); // This doesn't cause the error.
funky(myclass::BUFF_SIZE); // This line causes the error.
funky(myclass::ANOTHER_BUFF_SIZE); // This doesn't cause the error.
funky(GLOBAL_BUFF_SIZE); // This doesn't cause the error.
}
--
Summary: Static const signed int class member causes undefined
symbol.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwitmer at xmission dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45082
[Bug c++/45082] Static const signed int class member causes undefined symbol.
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-26 15:32 --- This is not valid C++. See [class.static.data]/4: If a static data member is of const integral or const enumeration type, its declaration in the class definition can specify a constant-initializer which shall be an integral constant expression (5.19). In that case, the member can appear in integral constant expressions within its scope. The member shall still be defined in a namespace scope if it is used in the program and the namespace scope definition shall not contain an initializer. Your testcase doesn't have the needed const int myclass::BUFF_SIZE; anywhere. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45082
[Bug tree-optimization/45083] New: strange warning text from gcc
While compiling gdb with a relatively recent svn trunk gcc, I saw: gcc -g -O2 -I. -I../../archer/gdb -I../../archer/gdb/common -I../../archer/gdb/config -DLOCALEDIR=\/home/tromey/gnu/archer/install/share/locale\ -DHAVE_CONFIG_H -I../../archer/gdb/../include/opcode -I../../archer/gdb/../opcodes/.. -I../../archer/gdb/../readline/.. -I../bfd -I../../archer/gdb/../bfd -I../../archer/gdb/../include -I../libdecnumber -I../../archer/gdb/../libdecnumber -I../../archer/gdb/gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -I/usr/include -I/usr/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Werror -c -o xcoffread.o -MT xcoffread.o -MMD -MP -MF .deps/xcoffread.Tpo ../../archer/gdb/xcoffread.c ../../archer/gdb/xcoffread.c: In function xcoff_psymtab_to_symtab_1: ../../archer/gdb/xcoffread.c:1325:9: error: fcn_aux_saved$x_sym$x_misc$x_fsize may be used uninitialized in this function [-Werror=uninitialized] ../../archer/gdb/xcoffread.c:955:25: note: fcn_aux_saved$x_sym$x_misc$x_fsize was declared here cc1: all warnings being treated as errors Those $s are strange to see, because they don't appear in the source. I think it would be friendlier to emit .s instead. I will attach the .i momentarily. -- Summary: strange warning text from gcc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
[Bug tree-optimization/45083] strange warning text from gcc
--- Comment #1 from tromey at gcc dot gnu dot org 2010-07-26 15:53 --- Created an attachment (id=21318) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21318action=view) compressed .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
[Bug c++/45082] Static const signed int class member causes undefined symbol.
--- Comment #2 from rwitmer at xmission dot com 2010-07-26 15:59 --- I agree with your assessment. Adding const int myclass::BUFF_SIZE; resolves the issue. The bug/feature may be that re-typing BUFF_SIZE to static const unsigned int allows the compiler to not report a problem. It doesn't require a const unsigned myclass::BUFF_SIZE; anywhere and still compiles when it shouldn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45082
[Bug tree-optimization/45083] strange warning text from gcc
--- Comment #2 from tromey at gcc dot gnu dot org 2010-07-26 15:59 --- Forgot some info: opsy. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/space/tromey/Trunk/install/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../trunk/configure --prefix=/home/tromey/gnu/Trunk/install --enable-languages=c++,java,fortran --enable-threads=posix --enable-checking=yes --enable-java-awt=gtk --enable-languages=c,c++ --disable-static --disable-bootstrap --enable-java-maintainer-mode : (reconfigured) : (reconfigured) ../trunk/configure --prefix=/home/tromey/gnu/Trunk/install --enable-languages=c++,java,fortran --enable-threads=posix --enable-checking=yes --enable-java-awt=gtk --enable-languages=c,c++ --disable-static --disable-bootstrap --enable-java-maintainer-mode : (reconfigured) ../trunk/configure --prefix=/home/tromey/gnu/Trunk/install --enable-languages=c++,java,fortran --enable-threads=posix --enable-checking=yes --enable-java-awt=gtk --enable-languages=c,c++ --disable-static --disable-bootstrap --enable-java-maintainer-mode Thread model: posix gcc version 4.6.0 20100720 (experimental) [trunk revision 162345] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
[Bug tree-optimization/43784] [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-07-26 16:02 --- Subject: Bug 43784 Author: rguenth Date: Mon Jul 26 16:01:55 2010 New Revision: 162539 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162539 Log: 2010-07-26 Richard Guenther rguent...@suse.de PR tree-optimization/43784 * tree-nrv.c (dest_safe_for_nrv_p): It's not safe to NRV if the destination is used by the call. * gcc.c-torture/execute/pr43784.c: New testcase. * g++.dg/torture/pr43784.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/torture/pr43784.C trunk/gcc/testsuite/gcc.c-torture/execute/pr43784.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-nrv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43784
[Bug tree-optimization/43784] [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-26 16:02 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43784
[Bug libstdc++/45084] New: configure: error: no 8-bit type
Use binutils 2.20.1. Configure gcc: ../configure --prefix=/usr/local/m68k-elf \ --enable-interwork \ --enable-multilib \ --without-headers \ --disable-shared \ --disable-libssp \ --enable-languages=c,c++ \ --verbose \ --with-newlib \ --program-prefix=m68k-elf- \ --with-as=/usr/local/m68k-elf/bin/m68k-elf-as.exe \ --with-ld=/usr/local/m68k-elf/bin/m68k-elf-ld.exe \ --target=m68k-elf \ Error: looking for a compliant stdint.h in stdint.h, checking for uintmax_t... no looking for a compliant stdint.h in inttypes.h, checking for uintmax_t... no looking for a compliant stdint.h in sys/inttypes.h, checking for uintmax_t... no looking for an incomplete stdint.h in stdint.h, checking for uint32_t... no looking for an incomplete stdint.h in inttypes.h, checking for uint32_t... no looking for an incomplete stdint.h in sys/inttypes.h, checking for uint32_t... no looking for u_intXX_t types in sys/types.h, checking for u_int32_t... no looking for u_intXX_t types in inttypes.h, checking for u_int32_t... no looking for u_intXX_t types in sys/inttypes.h, checking for u_int32_t... no checking what to include in include/gstdint.h... stddef.h (using manual detection) checking size of void *... 0 checking size of long... 0 checking size of int... 0 checking size of short... 0 checking size of char... 0 checking for type equivalent to int8_t... /home/ivb/gcc-4.5.0/libstdc++-v3/configure: line 269: retu rn: please: numeric argument required configure: error: no 8-bit type make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/home/ivb/gcc-4.5.0/build' -- Summary: configure: error: no 8-bit type Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ivbx at bk dot ru GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: m68k-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084
[Bug tree-optimization/45085] New: incorrect -Wuninitialized warning
I'm using a relatively recent svn trunk gcc on an x86 Fedora 13 machine.
I'm trying to compile gdb with it. I got this error:
../../archer/gdb/remote.c: In function remote_wait:
../../archer/gdb/remote.c:5561:10: error: event_ptid.tid may be used
uninitialized in this function [-Werror=uninitialized]
../../archer/gdb/remote.c:5561:10: error: event_ptid.lwp may be used
uninitialized in this function [-Werror=uninitialized]
../../archer/gdb/remote.c:5561:10: error: event_ptid.pid may be used
uninitialized in this function [-Werror=uninitialized]
cc1: all warnings being treated as errors
But the body of remote_wait is simple:
{
ptid_t event_ptid;
if (non_stop)
event_ptid = remote_wait_ns (ptid, status, options);
else
event_ptid = remote_wait_as (ptid, status, options);
if (target_can_async_p ())
{
/* If there are are events left in the queue tell the event loop
to return here. */
if (stop_reply_queue)
mark_async_event_handler (remote_async_inferior_event_token);
}
return event_ptid;
}
I thought perhaps that inlining was causing a problem (in which case this
error message is quite confusing, since it would point to the wrong function).
However, I added this:
memset (event_ptid, 0, sizeof (event_ptid));
... to the function before the if, and the error went away.
So, I think this is a gcc bug.
I will attach the .i file.
--
Summary: incorrect -Wuninitialized warning
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45085
[Bug tree-optimization/45085] incorrect -Wuninitialized warning
--- Comment #1 from tromey at gcc dot gnu dot org 2010-07-26 16:12 --- Created an attachment (id=21319) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21319action=view) compressed .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45085
[Bug c++/41201] #pragma GCC target (sse2) doesn't alter __SSE2__ in C++ (as it does in C)
--- Comment #5 from justin dot lebar+bug at gmail dot com 2010-07-26 16:20 --- FWIW, it seems that MSVC is perfectly happy to compile code with intrinsics inside a file which doesn't have any special flags. It would be awesome if there were some way to do the same with GCC, even if it involves #pragma hackery. The current limitation makes using intrinsics pretty painful, as it requires a separate file for each targeted instruction set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41201
[Bug c++/45082] Static const signed int class member causes undefined symbol.
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-26 16:32 --- (In reply to comment #2) The bug/feature may be that re-typing BUFF_SIZE to static const unsigned int allows the compiler to not report a problem. You're not re-typing it, you're providing a definition for a variable that was previously only declared, not defined. It doesn't require a const unsigned myclass::BUFF_SIZE; anywhere Yes it does, it requires it where you bind a reference to the variable. If you only want it to be used as an integral constant, don't use it in a context that requires a variable (e.g. reference binding) and still compiles when it shouldn't. There are dozens of (invalid) bug reports in bugzilla about this, feel free to search for more details. The compiler must not reject your program as it doesn't know until link time that you've failed to define the symbol. It could be defined in some other object or library that you link to later. The bug was in your program, not the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45082
[Bug c++/45082] Static const signed int class member causes undefined symbol.
--- Comment #4 from redi at gcc dot gnu dot org 2010-07-26 16:37 --- (In reply to comment #3) If you only want it to be used as an integral constant, don't use it in a context that requires a variable (e.g. reference binding) e.g. funky((int)myclass::BUFF_SIZE); This means the reference binds to a temporary, not to your class variable, and therefore the compiler only needs the value of BUFF_SIZE, not it's definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45082
[Bug c++/45069] Instruction wrong with graphite on i486 geode
--- Comment #1 from spop at gcc dot gnu dot org 2010-07-26 16:45 --- This looks like a duplicate of a binutils bug: http://sourceware.org/bugzilla/show_bug.cgi?id=6957 I fail to see how this is related to Graphite: you may find other codes that are padded with NOPL that are triggering this same error on Geode. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45069
[Bug fortran/45086] New: For whole-file checking, also check whether an INTERFACE matches
The check should be done in resolve_global_procedure. NAG has: Error: fjkff.f90: Inconsistent INTERFACE block for procedure FOO from $main$ Argument X (no. 1) should be an assumed-shape array g95 has: Error: Passing array at (1) to assumed-shape actual argument at (2) via an implicit interface Example: subroutine foo(x) integer :: x(:) end subroutine foo interface subroutine foo(x) integer :: x(1) end subroutine foo end interface call foo([1]) end -- Summary: For whole-file checking, also check whether an INTERFACE matches Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45086
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #24 from dominiq at lps dot ens dot fr 2010-07-26 17:02 --- With the patch in comment #23, the polyhedron tests gas_dyn.f90 and test_fpu.f90 do not link and compiling the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867#c6 gives an ICE (Segmentation fault). Otherwise all the other polyhedron tests compile with -O3 -g -fwhole-program and I did not see any miscompilation, regtested without regression. Nice work! thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #25 from burnus at gcc dot gnu dot org 2010-07-26 17:03 ---
(In reply to comment #23)
Created an attachment (id=21315)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21315action=view) [edit]
New trans-decl.c patch - seems to work well
Dominique has found a failure (segfault) with PR 31867 comment 6.
If one generates in gfc_get_extern_function_decl the code for lensum, one
finds that its argument words has locally the correct type:
(gdb) p sym-formal-sym-as-type
$4 = AS_ASSUMED_SHAPE
but the gsym has the wrong type
(gdb) p gsym-ns-proc_name-formal-sym-as-type
$10 = AS_DEFERRED
Thus, one enters the code path for descriptor-free arrays and crashes as UBOUND
is NULL.
In principle, this should get fixed in resolve_formal_arglist. One problem is
that if one enters find_arglists sym-ns != gfc_current_ns it fails.
But the actual problems seems to be in resolve_global_procedure. One has:
(gdb) p sym-attr.if_source
$27 = IFSRC_IFBODY
(gdb) p sym-formal-sym-as-type
$28 = AS_ASSUMED_SHAPE
That is: The symbol in the interface block of the module is resolved. But the
gsym is not:
(gdb) p gsym-ns-resolved
$29 = 0
(gdb) p gsym-ns-proc_name-formal-sym-as-type
$30 = AS_DEFERRED
The following patch fixes the program. (Side remark, one could do more argument
checking, cf. PR 45086.)
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 162538)
+++ gcc/fortran/resolve.c (working copy)
@@ -1816,7 +1816,8 @@ resolve_global_procedure (gfc_symbol *sy
gfc_global_used (gsym, where);
if (gfc_option.flag_whole_file
-sym-attr.if_source == IFSRC_UNKNOWN
+(sym-attr.if_source == IFSRC_UNKNOWN
+ || sym-attr.if_source == IFSRC_IFBODY)
gsym-type != GSYM_UNKNOWN
gsym-ns
gsym-ns-resolved != -1
@@ -1902,7 +1903,7 @@ resolve_global_procedure (gfc_symbol *sy
sym-name, sym-declared_at, gfc_typename (sym-ts),
gfc_typename (def_sym-ts));
- if (def_sym-formal)
+ if (def_sym-formal sym-attr.if_source != IFSRC_IFBODY)
{
gfc_formal_arglist *arg = def_sym-formal;
for ( ; arg; arg = arg-next)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug target/44834] pr44707.c FAILs on sparc -m32: asm operand requires impossible reload
--- Comment #2 from mikpe at it dot uu dot se 2010-07-26 17:10 --- Fixed by Eric's patch for PR44707. -- mikpe at it dot uu dot se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44834
[Bug fortran/45087] New: -fwhole-program: Miscompiled due to wrong decls
Follow up to PR 40873. There are still some -fwhole-program issues left; for instance: The polyhedron tests gas_dyn.f90 and test_fpu.f90 do not link -- Summary: -fwhole-program: Miscompiled due to wrong decls Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 40873 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45087
[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE in |[4.3/4.4/4.5/4.6 Regression] |gfc_conv_array_initializer, |ICE in |at fortran/trans- |gfc_conv_array_initializer, |array.c:4208|at fortran/trans- ||array.c:4208 Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug target/42240] wrong epilogue on naked function
--- Comment #11 from eric dot weddington at atmel dot com 2010-07-26 17:37 --- Anitha, can you please check 4.5.x and HEAD? -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.3.2 4.3.4 |4.3.2 4.3.4 4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-07-26 17:37:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
[Bug target/42240] [4.3/4.4 Regression, avr] wrong epilogue on naked function
-- eric dot weddington at atmel dot com changed: What|Removed |Added Severity|normal |major GCC target triplet||avr Summary|wrong epilogue on naked |[4.3/4.4 Regression, avr] |function|wrong epilogue on naked ||function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
[Bug middle-end/44817] Stage2/stage3 genautomata has invalid memory access
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-26 18:41 --- It is a valgrind bug. I opened: https://bugzilla.redhat.com/show_bug.cgi?id=618360 -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||https://bugzilla.redhat.com/ ||show_bug.cgi?id=618360 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44817
[Bug tree-optimization/45083] strange warning text from gcc
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-26 18:50 ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options -O2 -Wuninitialized } */
struct S { char *a; unsigned b; unsigned c; };
extern int foo (const char *);
extern void bar (int, int);
static void
baz (void)
{
struct S cs[1];
switch (cs-b) /* { dg-warning cs\\[^\n\r\\]\.b\\[^\n\r\\]is used
uninitialized } */
{
case 101:
if (foo (cs-a)) /* { dg-warning cs\\[^\n\r\\]\.a\\[^\n\r\\]may be used
uninitialized } */
bar (cs-c, cs-b); /* { dg-warning cs\\[^\n\r\\]\.c\\[^\n\r\\]may be
used uninitialized } */
}
}
void
test (void)
{
baz ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
[Bug tree-optimization/45083] [4.3/4.4/4.5/4.6 Regression] strange warning text from gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-26 18:55 --- Confirmed, this was working in 4.2.4: t.c: In function âtestâ: t.c:9: warning: âcs[0u].bâ is used uninitialized in this function t.c:8: note: âcs[0u].bâ was declared here t.c:13: warning: âcs[0u].aâ is used uninitialized in this function t.c:8: note: âcs[0u].aâ was declared here t.c:15: warning: âcs[0u].câ is used uninitialized in this function t.c:8: note: âcs[0u].câ was declared here -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||4.3.2 4.6.0 4.5.0 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2010-07-26 18:55:56 date|| Summary|strange warning text from |[4.3/4.4/4.5/4.6 Regression] |gcc |strange warning text from ||gcc Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
[Bug tree-optimization/45083] [4.3/4.4/4.5/4.6 Regression] strange warning text from gcc
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-26 19:16 --- Created an attachment (id=21320) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21320action=view) gcc46-pr45083.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
