[Bug c++/46736] [c++0x] move constructor is not implicitly deleted when it should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46736 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-01 09:27:42 UTC --- Jason, could you take a look? Shouldn't a user-provided move constructor still be defined as deleted if there's a subobject that isn't trivially copyable?
[Bug tree-optimization/46723] [4.5 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 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 #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 10:01:32 UTC --- Mine then.
[Bug bootstrap/46730] [4.6 Regression] Failed to profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46730 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.01 10:10:30 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 10:10:30 UTC --- Mine.
[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #36 from rguenther at suse dot de rguenther at suse dot de
2010-12-01 10:12:21 UTC ---
On Tue, 30 Nov 2010, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #35 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-30
23:25:57 UTC ---
I said in my comment that adding temporaries could correct the issue,
but they do not. I had some different test trees, and reviewing them,
what actually corrected in one of the builds was adding a volatile
modifier to APR_RING_HEAD, as in:
#define APR_RING_HEAD(head, elem)\
struct head {\
struct elem * volatile next;\
struct elem * volatile prev;\
}
to better match APR_RING_ENTRY.
Probably a reasonable workaround. Having 2 different constructs
APR_RING_ENTRY
and APR_RING_HEAD for the same object is strange in any case.
If you'd re-use the same type the issue would go away as well (I think).
Richard.
[Bug ada/46738] microblaze ada --enable-werror-always build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46738 Laurent GUERBY laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net --- Comment #1 from Laurent GUERBY laurent at guerby dot net 2010-12-01 10:23:57 UTC --- Probably a missing #include tm_p.h or something like that again ...
[Bug fortran/28105] Check for memory allocations bigger than size_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28105 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-01 11:04:06 UTC --- I have played a bit around with the following (which has to be compiled on a system with 32bit size_t): real(8), dimension(1024*1024*1024) :: m m(1)= 0 print *, 1024*1024*1024 ! * 8 - overflow print *, huge(3) print *, 2_8**32 print *, 4_8*1024*1024*1024 end However, I fail to get any compile- or run-time error. Expected: As with the following code, one gets a compile-time error: $ gfortran -m32 hjff3.f90 .test.f90:1:0: error: size of variable ‘m’ is too large real(8), dimension(huge(3)) :: m m(1)= 0 end
[Bug c++/46645] [4.6 Regression] FAIL: 20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46645 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2010-12-01 11:12:51 UTC --- Also seen on i386-pc-solaris2*, sparc-sun-solaris2* and mips-sgi-irix6.5 (all ABIs).
[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Comment #37 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-01 12:15:02 UTC --- If you'd re-use the same type the issue would go away as well (I think). Yes, this works for the testcase, but probably only because the problematic fields are now volatile too (APR_RING_ENTRY has volatile fields, APR_RING_HEAD doesn't). The warning is still emitted for the more natural: #define APR_RING_SENTINEL(hp, elem, link)\ (struct elem *)((char *)(hp) - APR_OFFSETOF(struct elem, link)) with -Wstrict-aliasing so the underlying aliasing issue is probably still there. Closing as invalid since the original SPARC issues were fixed elsewhere and the -O3 issue is an aliasing violation in the source code.
[Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.01 12:17:35 CC||davek at gcc dot gnu.org AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Dave Korn davek at gcc dot gnu.org 2010-12-01 12:17:35 UTC --- (In reply to comment #2) not I, the addition of -no-undefined was from the Dave K. who needs it to get a .dll to build - without that change, everything is hunky-dory with libtool defaults. Based on our off-list discussion, I thought that it actually required an explicit -undefined dynamic_lookup? (Dave also has a patch that makes the addition conditional on the *win* target). Yep, that will resolve this problem. Just need to agree the fine details with Ralf.
[Bug c/46742] New: -Wparentheses unexpectedly misses some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742
Summary: -Wparentheses unexpectedly misses some cases
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se
cat bug.c
int foo(unsigned int mask) { return (!mask 2) ? 1 : 0; }
int bar(unsigned int mask) { return (!mask 1) ? 1 : 0; }
gcc -Wparentheses -S bug.c
bug.c: In function 'foo':
bug.c:1:1: warning: suggest parentheses around operand of '!' or change '' to
'' or '!' to '~'
gcc warns about foo(), which is good, but why doesn't it warn about bar()? For
some reason the number of the bit being inspected affects the compiler's
ability to detect the typo and issue the warning.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/mikpe/pkgs/linux-x86_64/gcc-4.5.1/libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /tmp/gcc-4.5.1/configure
--prefix=/home/mikpe/pkgs/linux-x86_64/gcc-4.5.1
--with-gmp=/home/mikpe/pkgs/linux-x86_64/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86_64/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-x86_64/mpc-0.8.2 --disable-plugin
--disable-lto --disable-nls --disable-shared --disable-libmudflap
--enable-multilib --enable-threads=posix --enable-checking=release
--enable-languages=c,ada
Side note, shouldn't there be a diagnostic component in bugzilla? For now I
chose C frontend, which may or may not be appropriate.
[Bug libstdc++/46743] New: gdb Pretty Printers don't work for std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46743
Summary: gdb Pretty Printers don't work for std::set
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bschind...@inf.ethz.ch
I'm using the gdb-pretty printers as released with gcc for my projects, but
they fail for a simple std::setdouble:
$1 = (DataSpec ) @0xc53b80: {mTracks = std::map with 0 elements, mGlobalData =
{mGlobal = false, mTimeValues = std::set with 88 elementsTraceback (most recent
call last):
File
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1/gcc-4.5.1/python/libstdcxx/v6/printers.py,
line 395, in next
item = self.rbiter.next()
File
/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1/gcc-4.5.1/python/libstdcxx/v6/printers.py,
line 297, in next
if node.dereference()['_M_right']:
RuntimeError: Attempt to dereference a generic pointer.
}}
[Bug libstdc++/46743] gdb Pretty Printers don't work for std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46743 --- Comment #1 from Benjamin Schindler bschindler at inf dot ethz.ch 2010-12-01 12:31:30 UTC --- Btw, I tried latest svn too and it has the same issues
[Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 --- Comment #4 from Dave Korn davek at gcc dot gnu.org 2010-12-01 12:31:28 UTC --- (In reply to comment #3) (In reply to comment #2) not I, the addition of -no-undefined was from the Dave K. who needs it to get a .dll to build - without that change, everything is hunky-dory with libtool defaults. Based on our off-list discussion, I thought that it actually required an explicit -undefined dynamic_lookup? Ah, hang on, I re-read our earlier emails and think I misunderstood. My understanding now is that that is what you get by default, so simply /not/ passing -no-undefined on Darwin is all that is required. That is how I will respin the patch.
[Bug libstdc++/46743] gdb Pretty Printers don't work for std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46743 --- Comment #2 from Benjamin Schindler bschindler at inf dot ethz.ch 2010-12-01 12:32:15 UTC --- Btw, I tried latest svn (pretty printers only) too and it has the same issues
[Bug debug/43628] [4.5 Regression] in-class func-ptr type parameter has unspecified DW_AT_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43628 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||bschindler at inf dot ||ethz.ch --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-01 12:34:07 UTC --- *** Bug 46743 has been marked as a duplicate of this bug. ***
[Bug libstdc++/46743] gdb Pretty Printers don't work for std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46743 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-01 12:34:07 UTC --- fixed already *** This bug has been marked as a duplicate of bug 43628 ***
[Bug libstdc++/46743] gdb Pretty Printers don't work for std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46743 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-01 12:35:57 UTC --- the bug is in g++ not the pretty printers, so you need a new gcc from svn, not just the pretty printers
[Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 12:42:48 UTC --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) not I, the addition of -no-undefined was from the Dave K. who needs it to get a .dll to build - without that change, everything is hunky-dory with libtool defaults. Based on our off-list discussion, I thought that it actually required an explicit -undefined dynamic_lookup? Ah, hang on, I re-read our earlier emails and think I misunderstood. My understanding now is that that is what you get by default, so simply /not/ passing -no-undefined on Darwin is all that is required. That is how I will respin the patch. indeed .. a mid-air collision ;) yes, I have checked (at rev. 167243) that simply deleting the -no-undefined -bindir ... addition is enough. Originally, I thought we needed to add it explicitly (and, of course, your patch works).
[Bug fortran/46625] libquadmath: Mangle internal symbols; rename __float128 - string functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46625 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-01 12:47:13 UTC --- Regarding the mangled symbols: As http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/11b3845e961393bc shows there is a real-world issue with MinGW64 and static linking as MinGW64 also uses gdtoa. MinGW64 now mangles the symbols using gdtoaimp.h by using #define symbol_D2A prefix_symbol_D2A with a suitable __prefix.
[Bug c/46744] New: Additional stop after stage for C cache usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46744 Summary: Additional stop after stage for C cache usage Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: m.j.tha...@googlemail.com This is a request for an additional option to gcc to make it stop at a point later than the end of preprocessing but earlier than actual compilation which might be useful for C cache hash generation. I was thinking of a point at which as much useless information (e.g. unused typedefs) as possible has been discarded from the pre-processed output, but still not too much processing-intensive work has been done.
[Bug bootstrap/46730] [4.6 Regression] Failed to profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46730 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 13:13:28 UTC --- Author: rguenth Date: Wed Dec 1 13:13:23 2010 New Revision: 167326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167326 Log: 2010-12-01 Richard Guenther rguent...@suse.de PR tree-optimization/46730 * value-prof.c (gimple_ic): Always generate a separate merge BB. * g++.dg/tree-prof/indir-call-prof-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-prof/indir-call-prof-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/value-prof.c
[Bug other/46745] New: '#'mem_ref' not supported by dump_expr#expression error'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46745 Summary: '#'mem_ref' not supported by dump_expr#expression error' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: marc.gli...@normalesup.org Created attachment 22586 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22586 testcase Hello, with the attached testcase, I currently get (-Wall -O1): a.cc: In member function 'void CGAL::Envelope_divide_and_conquer_2Traits_, Diagram_::_construct_envelope_non_vertical(CGAL::Envelope_divide_and_conquer_2Traits_, Diagram_::Curve_pointer_iterator, CGAL::Envelope_divide_and_conquer_2Traits_, Diagram_::Curve_pointer_iterator, CGAL::Envelope_divide_and_conquer_2Traits_, Diagram_::Envelope_diagram_1) [with Traits_ = CGAL::Arr_curve_data_traits_2CGAL::Arr_segment_traits_2CGAL::CartesianCGAL::Gmpq , int, Diagram_ = CGAL::Env_default_diagram_1CGAL::Arr_curve_data_traits_2CGAL::Arr_segment_traits_2CGAL::CartesianCGAL::Gmpq , int , CGAL::Envelope_divide_and_conquer_2Traits_, Diagram_::Curve_pointer_iterator = __gnu_cxx::__normal_iteratorCGAL::Arr_segment_2CGAL::CartesianCGAL::Gmpq **, std::vectorCGAL::Arr_segment_2CGAL::CartesianCGAL::Gmpq *, std::allocatorCGAL::Arr_segment_2CGAL::CartesianCGAL::Gmpq * , CGAL::Envelope_divide_and_conquer_2Traits_, Diagram_::Envelope_diagram_1 = CGAL::Env_default_diagram_1CGAL::Arr_curve_data_traits_2CGAL::Arr_segment_traits_2CGAL::CartesianCGAL::Gmpq , int ]': a.cc:291:3: warning: 'new_v' is used uninitialized in this function [-Wuninitialized] a.cc:112:20: warning: '#'mem_ref' not supported by dump_expr#expression error' is used uninitialized in this function [-Wuninitialized] a.cc:287:40: note: '#'mem_ref' not supported by dump_expr#expression error' was declared here a.cc:112:20: warning: 'intersection_point' is used uninitialized in this function [-Wuninitialized] a.cc:288:29: note: 'intersection_point' was declared here Older g++ didn't have the two mem_ref lines. The closest bug I could find is PR22238.
[Bug tree-optimization/46728] GCC no longer generates fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.01 13:47:04 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 13:47:04 UTC --- Confirmed.
[Bug c++/46731] GCC shouts cannot call member function 'void a::g()' without object if a is a dependent base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.01 13:52:15 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 13:52:15 UTC --- Confirmed. EDG accepts it. But I would argue that g is bound at first stage name-lookup and thus it is not a dependent name and thus the error is correct.
[Bug middle-end/46734] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:505
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46734
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.01 13:58:46
CC||jamborm at gcc dot gnu.org
Known to work||4.4.5, 4.6.0
Target Milestone|--- |4.5.2
Summary|ICE in create_tmp_var, at |[4.5 Regression] ICE in
|gimplify.c:505 |create_tmp_var, at
||gimplify.c:505
Ever Confirmed|0 |1
Known to fail||4.5.0, 4.5.1, 4.5.2
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01
13:58:46 UTC ---
Confirmed.
It's ipa-sra:
#9 0x00ccdf3c in sra_ipa_modify_assign (stmt_ptr=0x7fffd6e8,
gsi=0x7fffd6f0, data=0x1e188e0)
at /space/rguenther/src/svn/gcc-4_5-branch/gcc/tree-sra.c:3990
3990 true, GSI_SAME_STMT);
(gdb) l
3985new_rhs = *rhs_p;
3986
3987 if (new_rhs)
3988{
3989 tree tmp = force_gimple_operand_gsi (gsi, new_rhs, true,
NULL_TREE,
3990 true, GSI_SAME_STMT);
3991
3992 gimple_assign_set_rhs_from_tree (gsi, tmp);
3993}
3994
(gdb) call debug_tree (new_rhs)
view_convert_expr 0x702b2600
type record_type 0x7fffef7fec78 vector_closure_type sizes-gimplified
addressable needs-constructing type_1 type_4 type_5 type_6 BLK
size integer_cst 0x77ed2988 constant 32
unit size integer_cst 0x77ed2690 constant 4
...
arg 0 indirect_ref 0x702b25a0
type reference_type 0x7fffef81ee70 type record_type 0x7fffef81eb28
referred_type
sizes-gimplified unsigned type_6 SI size integer_cst
0x77ed2988 32 unit size integer_cst 0x77ed2690 4
align 32 symtab 0 alias set -1 canonical type 0x71bc2c78
pointer_to_this pointer_type 0x7fffed698d20
arg 0 parm_decl 0x7fffef2813b8 ISRA.934 type pointer_type
0x7fffed698d20
...
TYPE_NEEDS_CONSTRUCTING is set on new_rhs type which means gimplification
will fail to create a temporary.
Somehow fixed on the trunk.
[Bug c/46744] Additional stop after stage for C cache usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46744 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 14:00:31 UTC --- There isn't such point internally, unused typedefs etc. are not removed.
[Bug other/46745] '#'mem_ref' not supported by dump_expr#expression error'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46745 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.01 14:01:02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 14:01:02 UTC --- Mine.
[Bug bootstrap/46730] [4.6 Regression] Failed to profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46730 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 14:01:19 UTC --- Fixed.
[Bug c++/46732] Valgrind emits false(?) alarms on boost::make_shared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46732
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-01
14:03:39 UTC ---
(In reply to comment #4)
GCC 4.4 predates that issue being resolved, so the only real workaround is to
avoid using -std=c++0x with GCC 4.4
Or do something like I did for std::move in my initial implementation of
std::future, which returned scalars by value rather than by rvalue-reference:
// workaround for CWG issue 664 and c++/34022
templatetypename _Result, bool = is_scalar_Result::value
struct _Move_future_result
{
typedef _Result __rval_type;
static _Result _S_move(_Result __res) { return std::move(__res); }
};
// specialization for scalar types returns rvalue not rvalue-reference
templatetypename _Result
struct _Move_future_result_Result, true
{
typedef _Result __rval_type;
static _Result _S_move(_Result __res) { return __res; }
};
Boost could use something like this (for GCC 4.4 with -std=c++0x only) to avoid
the problem
[Bug ada/46746] New: ICE at find_valid_class, at reload.c:704
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46746 Summary: ICE at find_valid_class, at reload.c:704 Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org What do I need to attach to help someone debug this? /users/joel/test-gcc/b-gccada-arm/./gcc/xgcc -B/users/joel/test-gcc/b-gccada-arm/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gccada-arm/arm-rtems4.11/newlib/ -isystem /users/joel/test-gcc/b-gccada-arm/arm-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc-4.5-branch/newlib/libc/include -B/users/joel/test-gcc/install-4.5-branch/arm-rtems4.11/bin/ -B/users/joel/test-gcc/install-4.5-branch/arm-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-4.5-branch/arm-rtems4.11/include -isystem /users/joel/test-gcc/install-4.5-branch/arm-rtems4.11/sys-include-c -g -O2 -mthumb -W -Wall -gnatpg -mthumb a-nlcefu.ads -o a-nlcefu.o +===GNAT BUG DETECTED==+ | 4.5.2 20101129 (prerelease) [gcc-4_5-branch revision 167253] (arm-unknown-rtems4.11) GCC error:| | in find_valid_class, at reload.c:704 | | Error detected around a-ngcefu.adb:115:8 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+
[Bug c++/46731] GCC shouts cannot call member function 'void a::g()' without object if a is a dependent base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-01 14:18:55 UTC --- (In reply to comment #3) But I would argue that g is bound at first stage name-lookup and thus it is not a dependent name and thus the error is correct. 9.3.1p3 says that because it's found in the enclosing scope (during phase one) it should be transformed into (*this).g() and so it's not called without an object. It's ill-formed for any specialisation bT where T is not a or some class deriving from a, but for ba it's well-formed.
[Bug c/46747] New: invalid first operand of MEM_REF errors and ICEs with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46747
Summary: invalid first operand of MEM_REF errors and ICEs with
-fgraphite-identity
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu
Using r167318 with the approved graphite patches from
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02915.html applied as well as...
Index: gcc/opts.c
===
--- gcc/opts.c(revision 167318)
+++ gcc/opts.c(working copy)
@@ -462,6 +462,9 @@
{ OPT_LEVELS_1_PLUS, OPT_fcombine_stack_adjustments, NULL, 1 },
/* -O2 optimizations. */
+#ifdef HAVE_cloog
+{ OPT_LEVELS_2_PLUS, OPT_fgraphite_identity, NULL, 1 },
+#endif
{ OPT_LEVELS_2_PLUS, OPT_finline_small_functions, NULL, 1 },
{ OPT_LEVELS_2_PLUS, OPT_findirect_inlining, NULL, 1 },
{ OPT_LEVELS_2_PLUS, OPT_fpartial_inlining, NULL, 1 },
...a set of ICEs are exposed in the gcc testsuite. These include...
FAIL: gcc.c-torture/execute/921013-1.c compilation, -O2 (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/921013-1.c execution, -O2
FAIL: gcc.c-torture/execute/921013-1.c compilation, -O2 -flto
-flto-partition=none (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/921013-1.c execution, -O2 -flto
-flto-partition=none
FAIL: gcc.c-torture/execute/921013-1.c compilation, -O2 -flto (internal
compiler error)
UNRESOLVED: gcc.c-torture/execute/921013-1.c execution, -O2 -flto
FAIL: gcc.c-torture/execute/990513-1.c compilation, -Os (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/990513-1.c execution, -Os
FAIL: gcc.c-torture/execute/pr27073.c compilation, -Os (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/pr27073.c execution, -Os
FAIL: gcc.c-torture/execute/strcmp-1.c compilation, -Os (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/strcmp-1.c execution, -Os
FAIL: gcc.c-torture/execute/strncmp-1.c compilation, -Os (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/strncmp-1.c execution, -Os
which are all of the form...
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101130/gcc/testsuite/gcc.c-torture/execute/921013-1.c
-w -O2 -lm -m32 -o
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gcc/921013-1.x2
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101130/gcc/testsuite/gcc.c-torture/execute/921013-1.c:
In function 'main':
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101130/gcc/testsuite/gcc.c-torture/execute/921013-1.c:9:1:
error: invalid first operand of MEM_REF
r[3]
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101130/gcc/testsuite/gcc.c-torture/execute/921013-1.c:6:18:
note: in statement
# .MEM_80 = VDEF .MEM_63
r[3] = D.2716_79;
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101130/gcc/testsuite/gcc.c-torture/execute/921013-1.c:9:1:
internal compiler error: verify_stmts failed
and use of -fno-graphite-identity suppresses these failures.
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc-4.6-20101130/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20101130 (experimental) (GCC)
[Bug c++/46731] GCC shouts cannot call member function 'void a::g()' without object if a is a dependent base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731 --- Comment #5 from Johannes Schaub schaub-johannes at web dot de 2010-12-01 14:39:18 UTC --- (In reply to comment #3) Confirmed. EDG accepts it. But I would argue that g is bound at first stage name-lookup and thus it is not a dependent name and thus the error is correct. It is bound at first stage name lookup because it's not a dependent name. Thus, it is transformed to class-member access because g is a non-static member of some class. It being bound at first stage name lookup doesn't IMO mean that you drop any analysis that would depend on instantiation semantics, it just means you do name lookup only in the definition as opposed to be in the instantiation. In this case what will happen: g - (*this).g // found g in the definition context! - (*this).g(); So, you have an implicit object parameter of type a, and an implied object argument of lvalue of type ba, that has a dependent base class. The validity of the call depends on template arguments, so you have to delay further analysis. This further analysis doesn't have to do with name lookup but with overload resolution. The committee clarified the issue by resolving DR 515, stating their intent to support this and similar code. It may require that you internally mark constructs as instantiation dependent that formally aren't marked as type/value dependent, just because its validity depends on facts you can only know when instatiating so that you know when walking over the AST top-down what you again need to check and what not. I've no idea about those internal compiler things. Active issue #1172 looks for proper wording to capture any such constructs in a formal way.
[Bug fortran/28105] Check for memory allocations bigger than size_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28105 --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org 2010-12-01 14:43:55 UTC --- AFAICS the patch I committed in #6 as r167317 only changes how the ALLOCATE statement is compiled. For automatic and static arrays, different codepaths are chosen. In principle we should be able to catch the example in #7 at compile-time. But intuitively that would require us to check overflow after constant propagation; I don't know how easy that would be to do and what other effects such a change might bring. Or, perhaps a simpler approach would be to generate the array setup code with runtime overflow checks, and rely on the optimizers to remove the test at runtime for constant bounds; that is, essentially what the ALLOCATE code does?
[Bug c/46744] Additional stop after stage for C cache usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46744 Michael T. m.j.thayer at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #2 from Michael T. m.j.thayer at googlemail dot com 2010-12-01 15:01:11 UTC --- Fair enough then, I will mark it wontfix (unless you can think of some other point that would be more useful to a C cache than pre-processed output but still not too much processing work to reach).
[Bug c++/46748] New: Error using typename in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46748
Summary: Error using typename in template class
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@airs.com
When I compile this test case:
templatetypename T class B
{
public:
typedef int T2;
static void F(T* f, T2* v);
};
templatetypename T class D : public BT
{
public:
using typename BT::T2;
using BT::F;
static void F2(T* f) {
T2 v;
F(f, v);
}
};
with current mainline, I get this:
foo.cc: In static member function ‘static void DT::F2(T*)’:
foo.cc:15:8: error: expected ‘;’ before ‘v’
foo.cc:16:11: error: ‘v’ was not declared in this scope
As far as I can see, this should work without an error.
[Bug tree-optimization/46723] [4.5/4.6 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work|4.6.0 |
Summary|[4.5 Regression] internal |[4.5/4.6 Regression]
|compiler error: in |internal compiler error: in
|get_initial_def_for_inducti |get_initial_def_for_inducti
|on, at |on, at
|tree-vect-loop.c:2431 |tree-vect-loop.c:2431
Known to fail||4.6.0
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01
15:32:55 UTC ---
C testcase that also ICEs on trunk:
short *m;
void test()
{
short x = 128;
unsigned int i;
for (i = 0; i 128; ++i, x = (unsigned short)x + 1)
m[i] = x;
}
we are confused wrt the address arithmetic in
D.2720_6 = (long unsigned int) i_20;
D.2721_7 = D.2720_6 * 2;
D.2722_8 = pretmp.6_18 + D.2721_7;
*D.2722_8 = x_19;
and don't ICE with
short m[128];
which just gives us m[i_20] = x_19;
The access function that isn't a simple iv evolution is:
(short int) {(short unsigned int) x_50, +, 1}_1
At analysis time (in the not copied loop) we analyse it to
{128, +, 1}_1
instead as the loop bound is now non-constant after peeling a prologue:
bb 3:
# x_19 = PHI x_12(4), x_50(22)
# i_20 = PHI i_9(4), i_52(22)
# ivtmp.14_5 = PHI ivtmp.14_27(4), ivtmp.14_55(22)
D.2690_6 = (long unsigned int) i_20;
D.2691_7 = D.2690_6 * 2;
D.2692_8 = pretmp.6_18 + D.2691_7;
*D.2692_8 = x_19;
i_9 = i_20 + 1;
x.1_10 = (short unsigned int) x_19;
D.2694_11 = x.1_10 + 1;
x_12 = (short int) D.2694_11;
ivtmp.14_27 = ivtmp.14_5 - 1;
if (ivtmp.14_27 != 0)
goto bb 4;
else
goto bb 19;
in principle we can deal with that evolution just fine, but this
discrepancy analysis vs. transformation time doesn't look too good.
[Bug c++/46748] Error using typename in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46748 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-01 15:33:56 UTC --- another dup of PR 14258 ?
[Bug tree-optimization/46723] [4.5/4.6 Regression] internal compiler error: in get_initial_def_for_induction, at tree-vect-loop.c:2431
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46723 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 15:37:09 UTC --- Created attachment 22587 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22587 patch Patch I'm testing. Computes the induction PHI in the type of the evolution, stripping conversions (sign-changing only for now) and re-applying them at uses (by inserting another assignment that does the conversion in place for the vectorized stmt).
[Bug middle-end/46745] [4.6 Regression] '#'mem_ref' not supported by dump_expr#expression error'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46745 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|other |middle-end Target Milestone|--- |4.6.0 Summary|'#'mem_ref' not supported |[4.6 Regression] |by dump_expr#expression|'#'mem_ref' not supported |error' |by dump_expr#expression ||error'
[Bug fortran/28105] Check for memory allocations bigger than size_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28105
--- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-01
15:38:52 UTC ---
(In reply to comment #8)
For automatic and static arrays, different code paths are chosen.
I think one should try to get some checking working for INTEGER_CST_P only,
i.e. independent whether one uses automatic or static arrays or in the ALLOCATE
statement, a compile-time error should be printed. I am not sure that one needs
a run-time error - and if so, only with -fcheck=mem.
I think one should do something like:
if (INTEGER_CST_P (size))
{
if (!host_integerp (DECL_SIZE_UNIT (size), 1))
goto too_large = true;
if (TREE_INT_CST_LOW (size)
TYPE_MAX_VALUE (sizetype)/TREE_INT_CST_LOW (element_size)
goto too_large;
}
if (!host_integerp (DECL_SIZE_UNIT (decl), 1))
goto too_large;
too_large:
gfc_error (...);
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||ian at airs dot com --- Comment #14 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-01 15:46:29 UTC --- *** Bug 46748 has been marked as a duplicate of this bug. ***
[Bug c++/46748] Error using typename in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46748 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-01 15:46:29 UTC --- (In reply to comment #1) another dup of PR 14258 ? Yes. *** This bug has been marked as a duplicate of bug 14258 ***
[Bug tree-optimization/46728] [4.6 Regression] GCC no longer generates fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|GCC no longer generates |[4.6 Regression] GCC no |fmadd for pow (x, 0.75)+y |longer generates fmadd for |on powerpc |pow (x, 0.75)+y on powerpc
[Bug c++/46645] [4.6 Regression] FAIL: 20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46645
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC||marc.glisse at normalesup
||dot org
--- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2010-12-01
16:16:46 UTC ---
I get the same ICE (same line number 5490) with:
templateclass _T1, class _T2 struct pair {
_T2 second;
templateclass _U1, class _U2 constexpr pair(const pair_U1, _U2
__p) : second(__p.second) { }
};
pairint,int make_pair();
struct Gmpfr{
Gmpfr(int);
};
struct Gmpfi{
Gmpfi(pairconst Gmpfr,const Gmpfr bounds){ }
};
template class CT void test_interval_io(CT x){
Gmpfi a(x);
}
int main(){
test_interval_iopairint,Gmpfr (make_pair());
}
[Bug target/46746] ICE at find_valid_class, at reload.c:704
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46746 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||DUPLICATE --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-01 16:18:14 UTC --- Old issue. *** This bug has been marked as a duplicate of bug 37440 ***
[Bug target/37440] [4.4/4.5/4.6 Regression] GNAT Bug Box a-ngcefu.adb:397
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-01 16:18:14 UTC --- *** Bug 46746 has been marked as a duplicate of this bug. ***
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 --- Comment #6 from Sebastian Pop spop at gcc dot gnu.org 2010-12-01 17:25:15 UTC --- Author: spop Date: Wed Dec 1 17:25:10 2010 New Revision: 167348 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167348 Log: Postpone the rewrite out of SSA to the end of the translation to polyhedral representation. 2010-11-22 Sebastian Pop sebastian@amd.com PR middle-end/45297 * graphite-poly.c (new_poly_bb): Returns a poly_bb_p. Do not take the reduction bool in parameter. Clear PBB_IS_REDUCTION. Set GBB_PBB. * graphite-poly.h (new_poly_bb): Update declaration. (gbb_from_bb): Moved here... (pbb_from_bb): New. * graphite-sese-to-poly.c (var_used_in_not_loop_header_phi_node): Removed. (graphite_stmt_p): Removed. (try_generate_gimple_bb): Returns a gimple_bb_p. Do not pass in sbitmap reductions. Always build a gimple_bb_p. Do not call new_poly_bb. (build_scop_bbs_1): Do not pass in sbitmap reductions. (build_scop_bbs): Same. (gbb_from_bb): ... from here. (add_conditions_to_constraints): Moved up. (analyze_drs): New. (build_scop_drs): Call analyze_drs. Remove all the PBBs that do not contain data references. (new_pbb_from_pbb): New. (insert_out_of_ssa_copy_on_edge): Call new_pbb_from_pbb after a block is split. (rewrite_close_phi_out_of_ssa): Update call to insert_out_of_ssa_copy_on_edge. (rewrite_reductions_out_of_ssa): Now static. (rewrite_cross_bb_scalar_deps_out_of_ssa): Same. (split_pbb): New. (split_reduction_stmt): Call split_pbb. (translate_scalar_reduction_to_array): Pass in the scop, do not pass in the sbitmap reductions. (rewrite_commutative_reductions_out_of_ssa_close_phi): Same. (rewrite_commutative_reductions_out_of_ssa_loop): Same. (rewrite_commutative_reductions_out_of_ssa): Same. (build_poly_scop): Call build_scop_bbs, rewrite_commutative_reductions_out_of_ssa, rewrite_reductions_out_of_ssa, and rewrite_cross_bb_scalar_deps_out_of_ssa. Move build_scop_drs before scop_to_lst. * graphite-sese-to-poly.h (rewrite_commutative_reductions_out_of_ssa): Removed declaration. (rewrite_reductions_out_of_ssa): Same. (rewrite_cross_bb_scalar_deps_out_of_ssa): Same. (build_scop_bbs): Same. * graphite.c (graphite_transform_loops): Do not initialize reductions. Do not call build_scop_bbs, rewrite_commutative_reductions_out_of_ssa, rewrite_reductions_out_of_ssa, and rewrite_cross_bb_scalar_deps_out_of_ssa. * sese.h (struct gimple_bb): Add field pbb. (GBB_PBB): New. * gcc.dg/graphite/pr45297.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr45297.c Modified: trunk/gcc/ChangeLog trunk/gcc/ChangeLog.graphite trunk/gcc/graphite-poly.c trunk/gcc/graphite-poly.h trunk/gcc/graphite-sese-to-poly.c trunk/gcc/graphite-sese-to-poly.h trunk/gcc/graphite.c trunk/gcc/sese.h trunk/gcc/testsuite/ChangeLog
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Sebastian Pop spop at gcc dot gnu.org 2010-12-01 17:26:25 UTC --- Fixed.
[Bug debug/46749] New: gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 Summary: gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The new gcc.dg/debug/pr41893-1.c testcase fails on darwin as... FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O (test for excess errors) FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O3 (test for excess errors) where the form of the failure is... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101201/gcc/testsuite/gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -flto -fwhole-program -O /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101201/gcc/testsuite/gcc.dg/debug/pr41893-2.c -lm -m32 -o pr41893-1.exe warning: (i386) /var/tmp//cchADStB.ltrans0.ltrans.o unable to open object file warning: no debug symbols in executable (-arch i386) From the output with -v this appears to be a dsymutil related issue... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/as -arch i386 -force_cpusubtype_ALL -o /var/tmp//ccyf23lE.ltrans0.ltrans.o /var/tmp//ccJ7sllh.s COMPILER_PATH=/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ LIBRARY_PATH=/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/i386/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/i386/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/i386/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/:/usr/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-B' '/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-fwhole-program' '-O' '-m32' '-v' '-mtune=core2' '-dumpdir' './' '-dumpbase' 'pr41893-1.exe.ltrans0' '-fltrans' '-o' '/var/tmp//ccyf23lE.ltrans0.ltrans.o' COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-B' '/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-flto' '-fwhole-program' '-O' '-m32' '-v' '-o' 'pr41893-1.exe' '-mtune=core2' dsymutil pr41893-1.exe warning: (i386) /var/tmp//ccyf23lE.ltrans0.ltrans.o unable to open object file warning: no debug symbols in executable (-arch i386)
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 17:50:25 UTC --- This failure appeared after r167289 but by r167301.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 18:05:00 UTC --- Caused by... Author: rguenth Date: Tue Nov 30 10:00:51 2010 New Revision: 167292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167292 Log: 2010-11-30 Richard Guenther rguent...@suse.de PR lto/44986 * gcc.c (main): Use the first input with a compiler as infile for link spec processing. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488 --- Comment #38 from Paulo César Pereira de Andrade pcpa at mandriva dot com.br 2010-12-01 18:23:36 UTC --- (In reply to comment #37) If you'd re-use the same type the issue would go away as well (I think). Yes, this works for the testcase, but probably only because the problematic fields are now volatile too (APR_RING_ENTRY has volatile fields, APR_RING_HEAD doesn't). The warning is still emitted for the more natural: #define APR_RING_SENTINEL(hp, elem, link)\ (struct elem *)((char *)(hp) - APR_OFFSETOF(struct elem, link)) with -Wstrict-aliasing so the underlying aliasing issue is probably still there. Closing as invalid since the original SPARC issues were fixed elsewhere and the -O3 issue is an aliasing violation in the source code. Maybe this should this be considered a problem in the sense that it does not warn with -Wstrict-aliasing ? As in this case, httpd source was patched to correct the warning, but the problem remained. I mean, otherwise it is a kind of please use -fno-strict-aliasing for everything you do not want to risk having incorrect code generation.
[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488 --- Comment #39 from Paulo César Pereira de Andrade pcpa at mandriva dot com.br 2010-12-01 18:25:50 UTC --- (In reply to comment #38) (In reply to comment #37) If you'd re-use the same type the issue would go away as well (I think). Yes, this works for the testcase, but probably only because the problematic fields are now volatile too (APR_RING_ENTRY has volatile fields, APR_RING_HEAD doesn't). The warning is still emitted for the more natural: #define APR_RING_SENTINEL(hp, elem, link)\ (struct elem *)((char *)(hp) - APR_OFFSETOF(struct elem, link)) with -Wstrict-aliasing so the underlying aliasing issue is probably still there. Closing as invalid since the original SPARC issues were fixed elsewhere and the -O3 issue is an aliasing violation in the source code. Maybe this should this be considered a problem in the sense that it does not warn with -Wstrict-aliasing ? As in this case, httpd source was patched to correct the warning, but the problem remained. I mean, otherwise it is a kind of please use -fno-strict-aliasing for everything you do not want to risk having incorrect code generation. Damn, sorry for quickly replying to myself. It warns with both -Wstrict-aliasing=1 and -Wstrict-aliasing=2
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.01 18:44:07 CC|rguenther at suse dot de|rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 18:44:07 UTC --- What's the difference of -v output caused by the patch?
[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488 --- Comment #40 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-01 18:55:28 UTC --- Maybe this should this be considered a problem in the sense that it does not warn with -Wstrict-aliasing ? As in this case, httpd source was patched to correct the warning, but the problem remained. The level 3 warning isn't guaranteed to catch all the cases, especially when one explicitly obfuscates the issue. :-) But, yes, worth taking a look.
[Bug driver/46750] New: Parallel build doesn't work --with-build-config=bootstrap-lto in a gcc+binutils combined tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46750 Summary: Parallel build doesn't work --with-build-config=bootstrap-lto in a gcc+binutils combined tree Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: bonz...@gnu.org I got make[7]: *** read jobs pipe EOF. Stop. make[7]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status lto-wrapper failedcollect2: ld returned 1 exit status make[6]: *** [objdump] Error 1 make[6]: *** Waiting for unfinished jobs make[7]: *** read jobs pipe EOF. Stop. make[7]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status lto-wrapper failedcollect2: ld returned 1 exit status make[6]: *** [nm-new] Error 1 make[7]: *** read jobs pipe EOF. Stop.
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 19:05:48 UTC --- The new testcase fails on x86_64-apple-darwin10 as... FAIL: gcc.dg/graphite/pr45297.c (internal compiler error) FAIL: gcc.dg/graphite/pr45297.c (test for excess errors) with the error... /Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/ /Users/howarth/gcc/gcc/testsuite/gcc.dg/graphite/pr45297.c -Os -fgraphite-identity -S -m32 -o pr45297.s /Users/howarth/gcc/gcc/testsuite/gcc.dg/graphite/pr45297.c: In function 'foo': /Users/howarth/gcc/gcc/testsuite/gcc.dg/graphite/pr45297.c:4:1: internal compiler error: in rename_uses, at sese.c:533 which backtraces as... Breakpoint 1, fancy_abort (file=0x1009ea1e0 ../../gcc/gcc/sese.c, line=533, function=0x1009ea2fe rename_uses) at ../../gcc/gcc/diagnostic.c:893 893 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) bt #0 fancy_abort (file=0x1009ea1e0 ../../gcc/gcc/sese.c, line=533, function=0x1009ea2fe rename_uses) at ../../gcc/gcc/diagnostic.c:893 #1 0x000100663a2a in copy_bb_and_scalar_dependences (bb=value temporarily unavailable, due to optimizations, region=0x142032f40, next_e=0x143b27880, iv_map=0x14205a5c0) at ../../gcc/gcc/sese.c:533 #2 0x0001004db6c2 in translate_clast (region=0x142032f40, context_loop=0x143a0ad48, stmt=0x142059a10, next_e=0x143b27840, newivs=0x7fff5fbfe388, newivs_index=0x14205a610, bb_pbb_mapping=0x142032d10, level=2, params_index=0x14203d000) at ../../gcc/gcc/graphite-clast-to-gimple.c:947 #3 0x0001004dab17 in translate_clast (region=0x142032f40, context_loop=0x143a0ad48, stmt=0x14205d8f0, next_e=0x143b27840, newivs=0x7fff5fbfe388, newivs_index=0x14205a610, bb_pbb_mapping=0x142032d10, level=2, params_index=0x14203d000) at ../../gcc/gcc/graphite-clast-to-gimple.c:1138 #4 0x0001004db564 in translate_clast_for_loop [inlined] () at /Users/howarth/gcc/gcc/graphite-clast-to-gimple.c:1028 #5 0x0001004db564 in translate_clast_for [inlined] () at /Users/howarth/gcc/gcc/graphite-clast-to-gimple.c:1061 #6 0x0001004db564 in translate_clast (region=0x142032f40, context_loop=0x143a0abb0, stmt=0x14205bab0, next_e=0x143b27440, newivs=0x7fff5fbfe388, newivs_index=0x14205a610, bb_pbb_mapping=0x142032d10, level=1, params_index=0x14203d000) at ../../gcc/gcc/graphite-clast-to-gimple.c:1116 #7 0x0001004dab17 in translate_clast (region=0x142032f40, context_loop=0x143a0abb0, stmt=0x142059840, next_e=0x143b27440, newivs=0x7fff5fbfe388, newivs_index=0x14205a610, bb_pbb_mapping=0x142032d10, level=1, params_index=0x14203d000) at ../../gcc/gcc/graphite-clast-to-gimple.c:1138 #8 0x0001004dbac1 in graphite_verify [inlined] () at /Users/howarth/gcc/gcc/graphite-clast-to-gimple.c:1553 #9 0x0001004dbac1 in gloog (scop=value temporarily unavailable, due to optimizations, bb_pbb_mapping=0x142032d10) at ../../gcc/gcc/graphite-clast-to-gimple.c:1557 #10 0x0001004d76a1 in graphite_transform_loops () at ../../gcc/gcc/graphite.c:284 #11 0x00010079ce7a in graphite_transforms () at ../../gcc/gcc/tree-ssa-loop.c:296 #12 0x0001005c9916 in execute_one_pass (pass=0x100bdbe00) at ../../gcc/gcc/passes.c:1553 #13 0x0001005c9d7d in execute_pass_list (pass=0x100bdbe00) at ../../gcc/gcc/passes.c:1608 #14 0x0001005c9d8f in execute_pass_list (pass=0x100bdbda0) at ../../gcc/gcc/passes.c:1609 #15 0x0001005c9d8f in execute_pass_list (pass=0x100bdbb00) at ../../gcc/gcc/passes.c:1609 #16 0x0001005c9d8f in execute_pass_list (pass=0x100bdb1a0) at ../../gcc/gcc/passes.c:1609 #17 0x0001006ff990 in invoke_plugin_callbacks [inlined] () at /Users/howarth/gcc/gcc/plugin.h:422 #18 0x0001006ff990 in tree_rest_of_compilation (fndecl=0x143b0b200) at ../../gcc/gcc/tree-optimize.c:425 #19 0x0001008fabb9 in cgraph_expand_function (node=0x143b29000) at ../../gcc/gcc/cgraphunit.c:1508 #20 0x0001008fdb5c in cgraph_expand_all_functions [inlined] () at /Users/howarth/gcc/gcc/cgraphunit.c:1567 #21 0x0001008fdb5c in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1827 #22 0x0001008fe021 in timevar_pop [inlined] () at /Users/howarth/gcc/gcc/timevar.h:1031 #23 0x0001008fe021 in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1033 #24 0x0001c7af in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9840 #25 0x000100689f91 in do_compile () at ../../gcc/gcc/toplev.c:591 #26 0x00010068a799 in toplev_main (argc=27, argv=0x7fff5fbfe800) at ../../gcc/gcc/toplev.c:1937 #27 0x00011504 in start ()
[Bug driver/46750] Parallel build doesn't work --with-build-config=bootstrap-lto in a gcc+binutils combined tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46750 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.01 19:06:23 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 19:06:23 UTC --- That's very much useless information ;)
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 19:10:07 UTC --- Note that I see these failures with either ppl-0.10.2 and legacy cloog-ppl or ppl-0.11 and cloog-isl.
[Bug libstdc++/46751] New: backtrace_symbols wrong when in unexpected_handler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46751
Summary: backtrace_symbols wrong when in unexpected_handler
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: e...@cq2.nl
When in an std::unexpected_handler, backtrace_symbols returns a trace with
functions not even called at all.
I noticed strange functions to appear on the trace, and missed functions that
should be there.
I reproduced it with the following minimal code:
#include exception
#include execinfo.h
extern C void my_unexpected_handler() {
void* trace[100];
int size = backtrace(trace, 100);
backtrace_symbols_fd(trace, size, 2);
}
void throw_0() throw() {
throw 0;
}
extern C void not_called_at_all_but_appearing_on_the_backtrace() { }
extern C int main(int, char*[]) {
std::set_unexpected(my_unexpected_handler);
throw_0();
return 0;
}
I compile this with: g++ -g -rdynamic filename
It then produces:
./a.out(my_unexpected_handler+0x1f)[0x8048973]
/usr/lib/libstdc++.so.6(+0xbd465)[0xb7853465]
/usr/lib/libstdc++.so.6(__cxa_call_unexpected+0x45)[0xb78528b5]
./a.out(not_called_at_all_but_appearing_on_the_backtrace+0x0)[0x80489dc]
./a.out(main+0x1a)[0x80489fb]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7621c76]
./a.out[0x80488c1]
terminate called after throwing an instance of 'int'
Aborted
As you can see, not_called_at_all_but_appearing_on_the_backtrace is not
called anywhere, but yet it is on the stack trace.
The function throw_0 however is missing.
I believe this is a bug. If not, what is going on here?
Best regards
Erik Groeneveld
[Bug libstdc++/46751] backtrace_symbols wrong when in unexpected_handler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46751 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-01 19:18:02 UTC --- backtrace is part of libc and not GCC.
[Bug libstdc++/46751] backtrace_symbols wrong when in unexpected_handler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46751 --- Comment #2 from Erik J Groeneveld erik at cq2 dot nl 2010-12-01 19:27:26 UTC --- (In reply to comment #1) backtrace is part of libc and not GCC. Thank you, I'll post it there too. Could it also have to do something with exception handling code in the c++ runtime that calls unexpected_handler? I think it somehow leaves the stack in a state that backtrace does not expect. That still leaves open the question where the bug is, if any.
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #10 from Sebastian Pop spop at gcc dot gnu.org 2010-12-01 19:45:10 UTC --- I see the same failure on amd64-linux with ./cc1 -m32 -Os -fgraphite-identity pr45297.c I will have a look at this.
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297
--- Comment #11 from Sebastian Pop spop at gcc dot gnu.org 2010-12-01
20:15:29 UTC ---
In this code:
bb 3:
q_5 = MEM[(void *)q_1 + 4294967288B];
bb 4:
# q_1 = PHI q_3(2), q_5(3)
if (q_1 != p_2(D))
goto bb 3;
else
goto bb 5;
scev analysis is able to determine that q1 = {q_3, +, -8}_1 and in the
same time, scev fails to analyze q5. And that triggers a rewrite of
q_5 out of SSA making the scev analysis of q1 impossible.
[Bug fortran/46752] New: OpenMP - Seg fault for unallocated allocatable array in firstprivate clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752 Summary: OpenMP - Seg fault for unallocated allocatable array in firstprivate clause Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com Test Case: cat test.f90 ! derived from OpenMP test omp3f/F03_2_9_3_4_5c.f90 program F03_2_9_3_4_5c use omp_lib implicit none integer, parameter :: NT = 4 integer, allocatable :: allocatable_array(:) integer :: i call omp_set_dynamic(.false.) call omp_set_num_threads(NT) !$omp parallel ! use schedule(static, 1) so each thread executes an iteration !$omp do firstprivate(allocatable_array) schedule(static, 1) do i = 1, NT ! Per OpenMP 3.0, p. 90, lines 33-34: if the list item is not ! currently allocated, the new list item will have an initial state of ! not currently allocated; if (ALLOCATED(allocatable_array) .neqv. .false.) then print *, FAIL - ALLOCATED(allocatable_array) == .true., (expected .false.) end if end do !$omp end parallel end program F03_2_9_3_4_5c gfortran -fopenmp test.f90 ./a.out Fortran runtime error: [the remaining text after error: appears to be missing, including the newline character.] The code executes when compiled with other compilers, and produces no output.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 20:30:57 UTC --- Created attachment 22588 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22588 -v for gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 at r167291
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 20:31:45 UTC --- Created attachment 22589 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22589 -v for gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 at r167292
[Bug fortran/46753] New: ICE: OpenMP - in extract_omp_for_data, at omp-low.c:335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753 Summary: ICE: OpenMP - in extract_omp_for_data, at omp-low.c:335 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: lo...@cray.com cat test.f90 program F03_E_3a use omp_lib implicit none integer, parameter :: NT = 4 integer, parameter :: INT32_MAX = 2147483647 ! 2**31-1 integer :: i, j, thread_num = -1 call omp_set_dynamic(.false.) call omp_set_num_threads(NT) !$omp parallel do collapse(2) schedule(static, 1) lastprivate(thread_num) do i = 1, INT32_MAX - 1 do j = 0, NT-1 thread_num = omp_get_thread_num() if (j /= thread_num) then print *, 'FAIL - j == ', j, ' (expected ', thread_num, ')' stop 1 end if end do end do !$omp end parallel do end program F03_E_3a gfortran -fopenmp test.f90 test.f90: In function 'f03_e_3a': test.f90:11:0: internal compiler error: in extract_omp_for_data, at omp-low.c:335 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 20:32:53 UTC --- Created attachment 22590 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22590 diff between -v for gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 at r167291 and r167292
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 20:35:13 UTC --- (In reply to comment #3) What's the difference of -v output caused by the patch? The offending lines from the diff of -v output appears to be... COMPILER_PATH=/Users/howarth/darwin_objdir/gcc/:/Users/howarth/darwin_objdir/gcc/ LIBRARY_PATH=/Users/howarth/darwin_objdir/gcc/i386/:/Users/howarth/darwin_objdir/gcc/i386/:/Users/howarth/darwin_objdir/gcc/:/Users/howarth/darwin_objdir/gcc/i386/:/Users/howarth/darwin_objdir/gcc/:/usr/lib/:/usr/lib/ -COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-B' '/Users/howarth/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-fwhole-program' '-O' '-m32' '-v' '-mtune=generic' '-dumpdir' './' '-dumpbase' 'pr41893-1.exe.ltrans0' '-fltrans' '-o' '/var/folders/24/24glfkZF2RWeoU+87t2fYU+++TQ/-Tmp-//ccGj1vUo.ltrans0.ltrans.o' +COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-B' '/Users/howarth/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-fwhole-program' '-O' '-m32' '-v' '-mtune=generic' '-dumpdir' './' '-dumpbase' 'pr41893-1.exe.ltrans0' '-fltrans' '-o' '/var/folders/24/24glfkZF2RWeoU+87t2fYU+++TQ/-Tmp-//ccCBuImZ.ltrans0.ltrans.o' +COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-B' '/Users/howarth/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-flto' '-fwhole-program' '-O' '-m32' '-v' '-o' 'pr41893-1.exe' '-mtune=generic' + dsymutil pr41893-1.exe +warning: (i386) /var/folders/24/24glfkZF2RWeoU+87t2fYU+++TQ/-Tmp-//ccCBuImZ.ltrans0.ltrans.o unable to open object file +warning: no debug symbols in executable (-arch i386) where r167292 causes the compiler to burp out a second incorrect assignment for COLLECT_GCC_OPTIONS after the first one.
[Bug middle-end/46667] [4.6 Regression] -freorder-blocks-and-partition -g failed and libstdc++ builds for arm-eabi are broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667 --- Comment #6 from Joel Sherrill joel at gcc dot gnu.org 2010-12-01 20:34:56 UTC --- Also impacts arm-*-rtems*
[Bug middle-end/46754] New: FAIL: gcc.dg/graphite/pr45297.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46754 Summary: FAIL: gcc.dg/graphite/pr45297.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: s...@gcc.gnu.org On Linux/ia32, revision 167353 gave: Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/graphite/pr45297.c -Os -fgraphite-identity -S -o pr45297.s(timeout = 300) spawn -ignore SIGHUP /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/graphite/pr45297.c -Os -fgraphite-identity -S -o pr45297.s^M /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/graphite/pr45297.c: In function 'foo':^M /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/graphite/pr45297.c:4:1: internal compiler error: in rename_uses, at sese.c:533^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 20:38:40 UTC --- Can you also add -Wl,-debug and/or -debug (basically make sure collect2 and lto-wrapper have verbosity on)?
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #9 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 20:46:11 UTC --- my (quick) reading of this is that -- the bugfix made by 167292 has caused the source file to be recognized -- causing dsymutil to fire up -- and revealing a pre-existing, probably unrelated problem.
[Bug middle-end/38856] loop iv detection failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38856 Sergei Larin slarin at codeaurora dot org changed: What|Removed |Added CC||slarin at codeaurora dot ||org --- Comment #8 from Sergei Larin slarin at codeaurora dot org 2010-12-01 20:48:47 UTC --- Hello, This has not been touched in a while, nevertheless the issue still exist with 4.5.1
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 20:49:41 UTC --- Works for me with -Wl,-debug (which doesn't delete intermediate files).
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-01 20:58:55 UTC --- (In reply to comment #10) Works for me with -Wl,-debug (which doesn't delete intermediate files). On x86_64-apple-darwin10 at r167292, adding -Wl,-debug inhibits the crash in dsymutil.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 21:10:51 UTC --- hm. on i686-darwin9 - adding -Wl,-debug simply suppresses the recognition of the source file and dsymutil is not called (a manifestation of PR41751). So there are two things; 1. dsymutil is not being called correctly - depends on what's on the c/l (PR43751) 2. when it is called it looks like the object is being deleted too early.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #13 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 21:20:36 UTC --- with -save-temps, dsymutil _is_ called and, indeed, the file complained about is absent. (I've a hunch that this could be related to the changes for simple-obj).
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 21:23:55 UTC --- Also works with splitting the command into a -c and a link step. Thus, /Users/richard/obj/gcc/xgcc -B/Users/richard/obj/gcc/ /Users/richard/src/trunk/gcc/testsuite/gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -flto -fwhole-program -O /Users/richard/src/trunk/gcc/testsuite/gcc.dg/debug/pr41893-2.c -lm -c /Users/richard/obj/gcc/xgcc -B/Users/richard/obj/gcc/ pr41893-1.o -gdwarf-2 -g1 -flto -fwhole-program -O pr41893-2.o -lm -o pr41893-1.exe -flto-partition=none does not fail. -flto-partition=none makes it easier to debug, no make is invocated (it's basically old LTO mode and not WHOPR). darwin doesn't seem to have an 'strace' command (bah). lto-wrapper invokes xgcc: /Users/richard/obj/gcc/lto-wrapper /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//cc0Ff4e8.o /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//ccWa94cZ.o /Users/richard/obj/gcc/xgcc -xlto -c -mmacosx-version-min=10.6.5 -B /Users/richard/obj/gcc/ -gdwarf-2 -g1 -fwhole-program -O -flto-partition=none -mtune=generic -dumpdir ./ -dumpbase pr41893-1.exe -o /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//ccWI2XqX.lto.o /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//cc0Ff4e8.o /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//ccWa94cZ.o /Users/richard/obj/gcc/collect-ld -dynamic -arch x86_64 -macosx_version_min 10.6.5 -weak_reference_mismatches non-weak -o pr41893-1.exe -lcrt1.10.5.o -L/Users/richard/obj/gcc /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//ccWI2XqX.lto.o -v -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem @(#)PROGRAM:ld PROJECT:ld64-97.14 Library search paths: /Users/richard/obj/gcc /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ warning: (x86_64) /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//ccWI2XqX.lto.o unable to open object file warning: no debug symbols in executable (-arch x86_64)
[Bug fortran/46752] OpenMP - Seg fault for unallocated allocatable array in firstprivate clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp, wrong-code CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-01 21:26:10 UTC --- Older GCC 4.6: Fortran runtime error: Attempt to allocate negative amount of memory. Possible integer overflow Current GCC 4.6: Operating system error: Cannot allocate memory Out of memory Valgrind: ==15971== Warning: silly arg (-1485340) to malloc() ==15971== Warning: silly arg (-1485340) to malloc() Operating system error: Success Out of memory
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 21:34:19 UTC --- splitting the command into compile and link steps will intentionally remove the dsymutil step - thus making the problem 'go away' ... dsymutil should _only_ be called if there is a source file on the c/l (which would have its object deleted and thus be unavailable for debug).
[Bug middle-end/45297] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1210 with -Os -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45297 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #12 from Sebastian Pop spop at gcc dot gnu.org 2010-12-01 21:42:38 UTC --- *** Bug 46754 has been marked as a duplicate of this bug. ***
[Bug middle-end/46754] FAIL: gcc.dg/graphite/pr45297.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46754 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Sebastian Pop spop at gcc dot gnu.org 2010-12-01 21:42:38 UTC --- Let's keep track of this bug in the previous bug PR45297. *** This bug has been marked as a duplicate of bug 45297 ***
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #16 from rguenther at suse dot de rguenther at suse dot de 2010-12-01 21:51:18 UTC --- On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 21:34:19 UTC --- splitting the command into compile and link steps will intentionally remove the dsymutil step - thus making the problem 'go away' ... dsymutil should _only_ be called if there is a source file on the c/l (which would have its object deleted and thus be unavailable for debug). Huh, ok. But the spec seems to call it unconditionally in the link-command-spec when -g is visible. At least I can't see how a source file is matched (and we now definitely do find object files as source for the link step). And the issue is probably that we match on the intermediate link command but execute only after that is finished. Well, that dsymutil hack looks like a hack.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #17 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 21:52:33 UTC --- (In reply to comment #14) is invocated (it's basically old LTO mode and not WHOPR). darwin doesn't seem to have an 'strace' command (bah). dtruss/dtrace might help.
[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488 --- Comment #41 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-01 21:53:23 UTC --- The warning machinery is faced with: (struct apr_bucket *) a-list.next It doesn't warn because, although a-list has a different type than struct apr_bucket, its field 'next' has the same type as the 'next' sub-field of the 'link' field of struct apr_bucket. Too much sophistication for the machinery. One would probably need to mimic the disambiguation rules of tree-ssa-alias.c. Richard, any idea?
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #18 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 22:06:23 UTC --- (In reply to comment #16) On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2010-12-01 21:34:19 UTC --- splitting the command into compile and link steps will intentionally remove the dsymutil step - thus making the problem 'go away' ... dsymutil should _only_ be called if there is a source file on the c/l (which would have its object deleted and thus be unavailable for debug). Huh, ok. But the spec seems to call it unconditionally in the link-command-spec when -g is visible. At least I can't see how a source file is matched (and we now definitely do find object files as source for the link step). it is matched (with the noted hacky buggy behavior) by the list of suffixes. And the issue is probably that we match on the intermediate link command but execute only after that is finished. OK Well, that dsymutil hack looks like a hack. yeah - it's on my TODO (pr43751). FWIW, some time ago, I did enquire about the difficulty of adding an intentional additional post-link phase, with the feedback that it was prob. not easy.
[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488 --- Comment #42 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-01 22:14:23 UTC --- (In reply to comment #41) The warning machinery is faced with: (struct apr_bucket *) a-list.next It doesn't warn because, although a-list has a different type than struct apr_bucket, its field 'next' has the same type as the 'next' sub-field of the 'link' field of struct apr_bucket. Too much sophistication for the machinery. One would probably need to mimic the disambiguation rules of tree-ssa-alias.c. Richard, any idea? The frontend machinery uses get_alias_set on types but it should use it on the references (but it also warns at places that are not memory references but just pointer casts, which of course will result in false positives and us not being able to do real analysis). I am repeatedly about to remove all but the memory-reference cases from the frontend warning code as with the many false positives people only learn how to circumvent it via casts which is never a real fix. If you want to experiment try using get_alias_set on the reference or get_deref_alias_set on the ADDR_EXPRs. The warn_strict_aliasing == 2 !alias_sets_must_conflict_p check doesn't make sense at all btw. and the alias_sets_conflict_p check should really be set1 != set2 !alias_set_subset_of (set2, set1). The interface of strict_aliasing_warning is also not good. Callers seem to check the warning level dependent on if they are in a dereference or just a casting context, instead they should pass a flag. And really the frontend should only warn about the dereference case. We can do a warning in the middle-end whenever we disambiguate using TBAA and could not do with only points-to info. We could restrict this to type-punned pointers if we can mark them somehow. But again this would result in very many false positives. Warning about TBAA violations is hard - you have to be better at alias-analysis than the optimizer (which otherwise would see the alias and not optimize).
[Bug rtl-optimization/46755] New: ICE: in calc_dfs_tree, at dominance.c:395 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46755
Summary: ICE: in calc_dfs_tree, at dominance.c:395 with -O
Product: gcc
Version: 4.6.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 22591
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22591
auto-reduced testcase
Compiler output:
$ gcc -O pr46755.f
pr46755.f:3.72:
ASSIGN 801 TO I800 ! { dg-warning Deleted feature: ASSIGN Delet
1
Warning: Deleted feature: ASSIGN statement at (1)
pr46755.f:6.72:
ASSIGN 761 TO I760 ! { dg-warning Deleted feature: ASSIGN Delet
1
Warning: Deleted feature: ASSIGN statement at (1)
pr46755.f:16.72:
ASSIGN 641 to I640 ! { dg-warning Deleted feature: ASSIGN
1
Warning: Deleted feature: ASSIGN statement at (1)
pr46755.f:25.16:
GOTO I760 ! { dg-warning Deleted feature: Assigned Assigned GO
1
Warning: Deleted feature: Assigned GOTO statement at (1)
pr46755.f:27.16:
GOTO I800 ! { dg-warning Deleted feature: Assigned Assigned GO
1
Warning: Deleted feature: Assigned GOTO statement at (1)
pr46755.f: In function 'MAIN__':
pr46755.f:28:0: internal compiler error: in calc_dfs_tree, at dominance.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Backtrace:
(gdb) bt
#0 fancy_abort (file=0x11415e8 /mnt/svn/gcc-trunk/gcc/dominance.c, line=395,
function=0x11416a5 calc_dfs_tree)
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1 0x00698483 in calc_dfs_tree (di=0x7fffd770, reverse=0 '\000')
at /mnt/svn/gcc-trunk/gcc/dominance.c:395
#2 0x00699d60 in calculate_dominance_info (dir=CDI_DOMINATORS) at
/mnt/svn/gcc-trunk/gcc/dominance.c:656
#3 0x00650e9d in flow_loops_find (loops=0x16c36c0) at
/mnt/svn/gcc-trunk/gcc/cfgloop.c:386
#4 0x007e0934 in ira (f=value optimized out) at
/mnt/svn/gcc-trunk/gcc/ira.c:3168
#5 0x007e2840 in rest_of_handle_ira () at
/mnt/svn/gcc-trunk/gcc/ira.c:3346
#6 0x00849fef in execute_one_pass (pass=0x1676ea0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1553
#7 0x0084a2b5 in execute_pass_list (pass=0x1676ea0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1608
#8 0x0084a2c7 in execute_pass_list (pass=0x16773c0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#9 0x0098a416 in tree_rest_of_compilation (fndecl=0x77fc0f00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#10 0x00b4fea2 in cgraph_expand_function (node=0x75cbb000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508
#11 0x00b5247a in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1567
#12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1827
#13 0x00b529fa in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031
#14 0x0080313d in write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/langhooks.c:303
#15 0x00933ed0 in compile_file (argc=15, argv=0x7fffdbf8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#16 do_compile (argc=15, argv=0x7fffdbf8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1874
#17 toplev_main (argc=15, argv=0x7fffdbf8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1937
#18 0x76586bbd in __libc_start_main () from /lib/libc.so.6
#19 0x004fe129 in _start ()
Tested revisions:
r167331 - crash
4.5 r166509 - crash
4.4 r166509 - crash
Testcase is auto-reduced from 20010519-1.f, I hit this ICE when reducing for
different problem. I don't know if this code should be considered valid or
invalid.
[Bug rtl-optimization/46755] ICE: in calc_dfs_tree, at dominance.c:395 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46755 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-01 23:02:46 UTC --- It crashes with -std=legacy as well: $ gfortran -O pr46755.f -std=legacy pr46755.f: In function 'MAIN__': pr46755.f:28:0: internal compiler error: in calc_dfs_tree, at dominance.c:395 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug debug/46756] New: -fcompare-debug failure (length) with ASSIGN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46756 Summary: -fcompare-debug failure (length) with ASSIGN Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22592 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22592 reduced testcase (from 20010519-1.f) Compiler output (-w is not needed): $ gcc -O -fcompare-debug pr46756.f -w gcc: error: pr46756.f: -fcompare-debug failure (length) $ diff pr46756.*gkd 89c89,90 (nil))) --- (nil)) - 2) Tested revisions: r167331 - fail 4.5 r166509 - fail
[Bug rtl-optimization/46755] ICE: in calc_dfs_tree, at dominance.c:395 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46755 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.01 23:09:35 CC||steven at gcc dot gnu.org AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2010-12-01 23:09:35 UTC --- Weird but technically valid code. I'll investigate.
[Bug debug/46756] -fcompare-debug failure (length) with ASSIGN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46756 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-01 23:11:44 UTC --- Created attachment 22593 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22593 another testcase (from pr9258.f) This one is shorter, but needs -fexpensive-optimizations $ gcc -O -fexpensive-optimizations -fcompare-debug pr46756-2.f -w gcc: error: pr46756-2.f: -fcompare-debug failure (length) $ diff pr46756-2.*gkd 97c97,98 (nil))) --- (nil)) - 4) 99c100 (code_label/s 4 0 0 5 4 (__label_20) [3 uses]) --- (code_label/s 4 0 0 5 4 (__label_20) [4 uses]) 123c124,125 (nil))) --- (nil)) - 2) 125c127 (code_label/s 2 0 0 8 2 (__label_30) [3 uses]) --- (code_label/s 2 0 0 8 2 (__label_30) [4 uses])
[Bug bootstrap/46757] New: bootstrap failure under Fedora 13 and 14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46757 Summary: bootstrap failure under Fedora 13 and 14 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@yahoo.com Created attachment 22594 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22594 config.log Fedora 13 x86_64 Fedora 14 x86_64 On each machine these packages are installed into /usr/local: gmp-5.0.1.tar.bz2 mpfr-3.0.0.tar.bz2 mpc-0.8.2.tar.gz gcc svn trunk rev. 167359 ../gcc_trunk/configure --prefix=$th1/gcc_trunk_167359_fc14 --enable-languages=c,c++ runs to completion. make bootstrap runs for a while and stops with a failure: configure: error: cannot compute suffix of object files: cannot compile Attaching: config.log make_bootstrap_log
[Bug bootstrap/46757] bootstrap failure under Fedora 13 and 14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46757 --- Comment #1 from rwgk at yahoo dot com 2010-12-01 23:44:42 UTC --- Created attachment 22595 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22595 output of make bootstrap
[Bug bootstrap/46757] bootstrap failure under Fedora 13 and 14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46757 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-01 23:47:28 UTC --- /usr/local: You have to either edit /etc/ld.so or add /usr/local to your LD_LIBRARY_PATH. This is not a bug with GCC but rather how you installed the libraries/build/run with them.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-01 23:58:30 UTC --- I am just trying to get Mozilla building with GNU ld instead of gold. First problem is that Mozilla links some of libraries as: /abuild/jh/trunk-install/bin/gcc -O3 -flto -flto-partition=none -fuse-linker-plugin -shared -Wl,-soname -Wl,libplds4.so -o libplds4.so ./plarena.o ./plhash.o ./plvrsion.o-L/abuild/jh/build-mozilla-new7/dist/lib -lnspr4 i.e. there is missing -fPIC that means that we compile into non-PIC code and GNU LD eventually complains about PC32 relocations into symbols that can be overwritten. Is this valid? If so, we need to work out -fPIC ourselves at LTO time Honza
[Bug middle-end/46734] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:505
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46734 --- Comment #2 from Ryan Hill dirtyepic at gentoo dot org 2010-12-02 00:29:26 UTC --- Created attachment 22596 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22596 testcase-mini.i FWIW, delta eventually spit this out.
