[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #6 from siarhei dot siamashka at gmail dot com 2009-12-21 08:27 --- Created an attachment (id=19356) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19356&action=view) return-address-prediction-bench.c This looks like a really serious performance issue. Not just indirect call alone is penalized, but the whole return address prediction stack is busted, causing return address mispredictions for all the nested calls. The attached test program demonstrates it. $ time ./return-address-prediction-bench 1 Indirect call for the topmost function real0m0.793s user0m0.789s sys 0m0.000s $ time ./return-address-prediction-bench Indirect call for the leaf function real0m1.797s user0m1.789s sys 0m0.008s gcc 4.4.2, "-O2 -mcpu=cortex-a8" Change of function pointer type "void (*f)()" -> "void (* volatile f)()" can be also used to "workaround" the problem. In this case execution times for both variants of test are approximately the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #7 from siarhei dot siamashka at gmail dot com 2009-12-21 08:53 --- (In reply to comment #4) > I would rather split the load out as a separate insn and allow it to be > scheduled separately. A question just to clarify the status of this issue. Are you waiting for David (or anybody else) to provide an updated patch with such split load? Are there no other options available besides either a perfect fix or no fix at all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug rtl-optimization/42429] [4.4 Regression] Miscompilation of 2fish on s390
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|Miscompilation of 2fish on |[4.4 Regression] |s390|Miscompilation of 2fish on ||s390 Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug rtl-optimization/39453] ICE : in init_seqno, at sel-sched.c:6433
--- Comment #5 from abel at gcc dot gnu dot org 2009-12-21 11:38 --- Me and Alexander will be looking at this together with the sel-sched ppc bugs. -- abel at gcc dot gnu dot org changed: What|Removed |Added CC||abel at gcc dot gnu dot org, ||amonakov at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |abel at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-03-13 14:08:02 |2009-12-21 11:38:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39453
[Bug target/41196] The use of ARM NEON vshll_n_u8 intrinsic results in compile error on valid code [4.4 only]
--- Comment #11 from mikpe at it dot uu dot se 2009-12-21 11:55 --- (In reply to comment #10) > Fixed. You forgot to add the test case in the 4.4 backport. -- 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=41196
[Bug c++/42447] New: ICE during processing complex templates
Compile the attached sources as follows:
g++ -std=gnu++0x -c -Wno-pmf-conversions file_reader.cpp
An Internal Compiler Error report will appear:
file_reader.cpp: In instantiation of
'std::unique_ptr::entry [], base::release_deleter>':
file_reader.cpp:35664:39: instantiated from 'std::unique_ptr<_Tp [],
_Tp_Deleter>::unique_ptr() [with _Tp = base::dynamic_dispatch::entry, _Tp_Deleter =
base::release_deleter]'
file_reader.cpp:86579:76: instantiated from 'base::dynamic_dispatch::dynamic_dispatch(TR (TC::*)(TD&, TA ...), size_t) [with
TC = io::file_reader, TR = void, TD = io::request, TA = {}, TR (TC::*)(TD&, TA
...) = void (io::file_reader::*)(io::request&), size_t = unsigned int]'
file_reader.cpp:88954:55: instantiated from here
file_reader.cpp:35653:5: internal compiler error: in finish_member_declaration,
at cp/semantics.c:2445
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: ICE during processing complex templates
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] ICE during processing complex templates
--- Comment #1 from piotr dot wyderski at gmail dot com 2009-12-21 12:41 --- Created an attachment (id=19357) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19357&action=view) The faulting code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] ICE during processing complex templates
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-21 13:00 --- Any chance you can provide a smaller reproducer? Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug target/42448] New: Wrong code with _Complex char in structure
Following testcase:
--cut here--
struct S2180
{
char t;
_Complex char u[2];
};
struct S2180 s2180;
int
main (void)
{
volatile struct S2180 x;
s2180.u[1] = 3 + 4i;
x.u[1] = s2180.u[1];
if (x.u[1] != s2180.u[1])
abort ();
return 0;
}
--cut here--
aborts for all optimization levels.
This bug shows in the testsuite of 4.4 branch [1]:
Running target unix
FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o
execute
The bug is also present on 4.3 and 4.5.
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01241.html
--
Summary: Wrong code with _Complex char in structure
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: alpha-linux-gnu
GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448
[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure
--- Comment #1 from ubizjak at gmail dot com 2009-12-21 13:19 --- Testsuite failure, so regression on all branches. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2009-12-21 13:19:36 date|| Summary|Wrong code with _Complex|[4.3/4.4/4.5 Regression] |char in structure |Wrong code with _Complex ||char in structure Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #3 from piotr dot wyderski at gmail dot com 2009-12-21 13:47 --- (In reply to comment #2) > Any chance you can provide a smaller reproducer? Thanks. > No, every simpler testcase based on the attached code I tried to create compiles successfully. Perhaps here is the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-21 14:11 --- Certainly *is* a problem if we hope to debug the issue decently fast... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #5 from piotr dot wyderski at gmail dot com 2009-12-21 14:27
---
(In reply to comment #4)
> Certainly *is* a problem if we hope to debug the issue decently fast...
>
I meant "the cause of the problem is in its size", i.e.
there must be a critical mass of templates to trigger
the issue. There probably is no problem in std::unique_ptr
on its own; to me it seems to be a "random victim" of
something strange happening under the hood. As I said,
I am not able to shrink it down in a reasonable way.
For example, this simplified testcase compiles flawlessly:
#include
struct release_deleter {
template void operator()(T* p) {
static_assert(std::is_pod::value ||
std::is_same::value,
"T must be a POD type or void");
}
};
template class dynamic_dispatch;
template <
typename TC,
typename TR,
typename TD,
typename... TA
> class dynamic_dispatch {
class entry {};
typedef std::unique_ptr entry_ptr;
public:
template void attach_handler(TR
(UC::*m)(UD&, TA...));
};
template <
typename TC,
typename TR,
typename TD,
typename... TA
> template <
typename UC,
typename UD
> void dynamic_dispatch::attach_handler(TR
(UC::*m)(UD&, TA...)) {
};
class C {
public:
void M(int&);
};
dynamic_dispatch dd;
int main() {
dd.attach_handler(&C::M);
}
But the problem is definitely related to template
processing. If you comment out the folowing line
(at the very bottom of the attached file, in the
constructor):
attach_handler(static_cast&)>
(&file_reader::execute_command));
it compiles OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-21 14:34 --- Ok... Did you help yourself with delta? See: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #20 from hjl at gcc dot gnu dot org 2009-12-21 15:32 --- Subject: Bug 42345 Author: hjl Date: Mon Dec 21 15:31:49 2009 New Revision: 155372 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155372 Log: Always pass --32 to ia32 Linux assembler. 2009-12-21 H.J. Lu PR bootstrap/42345 * acinclude.m4 (gcc_GAS_FLAGS): New. (gcc_GAS_CHECK_FEATURE): Use gcc_GAS_FLAGS. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/acinclude.m4 trunk/gcc/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-12-21 15:35 --- So given the above, I still think the patch from comment 7 will help. Because I don't have any access to a non-Linux platform I cannot try it myself and thus can only rely on others to test it for me. I'll be more than happy to cooperate further once someone does that. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #21 from hjl dot tools at gmail dot com 2009-12-21 16:06 --- Reopened -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|VERIFIED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #22 from hjl dot tools at gmail dot com 2009-12-21 16:07 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug c++/42447] [C++0x] ICE during processing complex templates
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #7 from paolo dot carlini at oracle dot com 2009-12-21 16:14 --- I'm reducing it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-21 16:14:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug rtl-optimization/42429] [4.4 Regression] Miscompilation of 2fish on s390
--- Comment #7 from jakub at gcc dot gnu dot org 2009-12-21 16:32 --- Subject: Bug 42429 Author: jakub Date: Mon Dec 21 16:32:44 2009 New Revision: 155374 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155374 Log: PR rtl-optimization/42429 * reload.c (find_reloads_subreg_address): When adjusting mode of MEM, update also MEM_SIZE if it is set. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug rtl-optimization/42429] [4.4 Regression] Miscompilation of 2fish on s390
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-21 16:34 --- Subject: Bug 42429 Author: jakub Date: Mon Dec 21 16:34:26 2009 New Revision: 155375 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155375 Log: PR rtl-optimization/42429 * reload.c (find_reloads_subreg_address): When adjusting mode of MEM, update also MEM_SIZE if it is set. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug other/42449] New: Error in dwarf2out.c when compiling tango for D with gdc
I have just updated to a new tango version. The source for tango can be found in http://www.dsource.org/projects/tango/wiki/Download svn co can be done svn co http://svn.dsource.org/projects/tango/tags/releases/0.99.8 The version report by svn update is revision 5270. I build the tango library like this. (All path are relative to the home of the checkout) terry:~/src/work/0.99.8> svn update At revision 5270. terry:~/src/work/0.99.8> cd lib terry:~/src/work/0.99.8/lib> ./bu build-dmd.sh* build-gdc-mac.sh* build-gdc.sh* build-gdc-x.sh* build-tango.sh* terry:~/src/work/0.99.8/lib> ./build-g build-gdc-mac.sh* build-gdc.sh* build-gdc-x.sh* terry:~/src/work/0.99.8/lib> ./build-gdc.sh --verbose --debug gdc #!/bin/sh -v cd "`dirname $0`" while [ "$#" != "0" ] ... tdc/wrap.o stdc/posix/pthread_darwin.o gmake[1]: Leaving directory `/home/carsten/src/work/0.99.8/lib/common/tango' chmod 644 ../tango/core/*.di || exit 1 export HOME=$OLDHOME terry:~/src/work/0.99.8/lib> ./build-tango.sh --verbose --debug gdc [gdmd] tango/sys/Process.d [gdmd] tango/sys/Common.d [gdmd] tango/sys/Environment.d [gdmd] tango/sys/linux/linux.d [gdmd] tango/sys/linux/tipc.d [gdmd] tango/sys/linux/epoll.d [gdmd] tango/sys/Pipe.d [gdmd] tango/sys/solaris/solaris.d [gdmd] tango/sys/SharedLib.d [gdmd] tango/time/ISO8601.d [gdmd] tango/time/Time.d [gdmd] tango/time/WallClock.d [gdmd] tango/time/Clock.d [gdmd] tango/time/chrono/Korean.d [gdmd] tango/time/chrono/ThaiBuddhist.d [gdmd] tango/time/chrono/Gregorian.d [gdmd] tango/time/chrono/Taiwan.d [gdmd] tango/time/chrono/Hebrew.d [gdmd] tango/time/chrono/Hijri.d [gdmd] tango/time/chrono/Japanese.d [gdmd] tango/time/chrono/GregorianBased.d [gdmd] tango/time/chrono/Calendar.d [gdmd] tango/time/StopWatch.d [gdmd] tango/math/Elliptic.d [gdmd] tango/math/BigInt.d [gdmd] tango/math/ErrorFunction.d [gdmd] tango/math/internal/Cache.d [gdmd] tango/math/internal/BiguintCore.d [gdmd] tango/math/internal/BignumX86.d [gdmd] tango/math/internal/BignumNoAsm.d [gdmd] tango/math/GammaFunction.d [gdmd] tango/math/IEEE.d [gdmd] tango/math/random/engines/Sync.d [gdmd] tango/math/random/engines/Twister.d [gdmd] tango/math/random/engines/CMWC.d [gdmd] tango/math/random/engines/KISS.d [gdmd] tango/math/random/engines/URandom.d [gdmd] tango/math/random/engines/ArraySource.d [gdmd] tango/math/random/engines/KissCmwc.d [gdmd] tango/math/random/NormalSource.d [gdmd] tango/math/random/Ziggurat.d [gdmd] tango/math/random/Twister.d [gdmd] tango/math/random/Random.d [gdmd] tango/math/random/ExpSource.d [gdmd] tango/math/random/Kiss.d [gdmd] tango/math/Bessel.d [gdmd] tango/math/Probability.d [gdmd] tango/math/Math.d [gdmd] tango/math/Random.d [gdmd] tango/math/Bracket.d [gdmd] tango/util/Convert.d [gdmd] tango/util/log/ConfigProps.d [gdmd] tango/util/log/Trace.d [gdmd] tango/util/log/AppendFile.d [gdmd] tango/util/log/LayoutChainsaw.d [gdmd] tango/util/log/AppendFiles.d tango/util/log/AppendFiles.d:1: internal compiler error: in output_die, at dwarf2out.c:7187 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . Compilation of tango/util/log/AppendFiles.d failed terry:~/src/work/0.99.8/lib> gdc --version gdc (GCC) 4.2.4 20080705 (prerelease gdc 0.25 20080312, using dmd 1.024) (Ubuntu 0.25-4.2.4-3.1) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See I dont know what this error means so I don't know who to fix it. I have tried this both on a 32bit and 64bits system and I am running Ubuntu 9.10 terry:~/src/work/0.99.8/lib> uname -a Linux terry 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux -- Summary: Error in dwarf2out.c when compiling tango for D with gdc Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cr at silicide dot dk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42449
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #8 from piotr dot wyderski at gmail dot com 2009-12-21 16:38 --- (In reply to comment #6) A marvelous tool! I'm reducing it too, staring at the proces with half-open mouth... -- piotr dot wyderski at gmail dot com changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-21 17:18 --- Note that a compiler built --disable-checking doesn't ICE, just errors out. Thus, are you sure the code is valid, before anything else? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
-- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-28 08:29:41 |2009-12-21 17:18:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #10 from piotr dot wyderski at gmail dot com 2009-12-21 17:23
---
(In reply to comment #9)
> Thus, are you sure the code is valid, before anything else?
It compiles and works on gcc version 4.5.0 20090604.
The current compiler is
Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap
--en
able-version-specific-runtime-libs --enable-shared --enable-shared-libgcc
--with
-gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers
--disable-nls
--with-arch=core2 --with-tune=generic --enable-threads=posix
--enable-languages
=c,c++
Thread model: posix
gcc version 4.5.0 20091217 (experimental) (GCC)
And here's the reduced testcase:
--8<--
namespace std
template
struct __add_ref<_Tp&>
{ typedef _Tp& type; };
class tuple<>
{
};
template
{
{
}
};
template
inline typename __add_ref<
>::type
get(tuple<_Elements...>& __t)
{
}
}
struct _Fnv_hash<4>
{
{
}
};
namespace std {
template
{
{
{
}
{
{
}
}
};
}
template >
class unique_ptr
{
reset(pointer __p = pointer())
{
{
}
}
{
}
};
template
class unique_ptr<_Tp[], _Tp_Deleter>
{
typedef std::tuple<_Tp*, _Tp_Deleter> __tuple_type;
get() const
{ return std::get<0>(_M_t); }
__tuple_type _M_t;
};
namespace base {
struct release_deleter {
template void operator()(T* p) {
}
};
template class dynamic_dispatch;
template <
typename TC,
typename TR,
typename TD,
typename... TA
> class dynamic_dispatch {
struct entry {
};
typedef std::unique_ptr entry_ptr;
entry_ptr m_Start;
template void attach_handler(TR
(UC::*m)(UD&, TA...));
};
template <
typename TC,
typename TR,
typename TD,
typename... TA
> template <
typename UC,
typename UD
> void dynamic_dispatch::attach_handler(TR
(UC::*m)(UD&, TA...)) {
entry* p = m_Cursor;
if (p != m_Start.get()) {
} while(--p != m_Start.get());
}
class __attribute__((dllexport)) request {
};
template class read_request : public read_request_base
{
};
template class request_dispatcher
: private base::dynamic_dispatch {
request_dispatcher();
};
class __attribute__((dllexport)) device {
struct __attribute__((dllexport)) control_block : public OVERLAPPED {
explicit control_block(request& req) {
}
};
};
class __attribute__((dllexport)) file_reader : public physical_device {
void execute_command(read_request<0>& req);
};
template <> request_dispatcher::request_dispatcher()
: super(&file_reader::report_unsupported_request) {
attach_handler(&file_reader::execute_command);
--
piotr dot wyderski at gmail dot com changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #11 from piotr dot wyderski at gmail dot com 2009-12-21 17:38
---
An even more reduced testcase which ICEs. Delta is amazing...
I think I'll stop here.
// 8<
namespace std
class tuple<>
{
};
template
get(tuple<_Elements...>& __t)
{
}
template
class unique_ptr
{
};
template
class unique_ptr<_Tp[], _Tp_Deleter>
{
typedef std::tuple<_Tp*, _Tp_Deleter> __tuple_type;
get() const
{ return std::get<0>(_M_t); }
__tuple_type _M_t;
};
namespace base {
struct release_deleter {
};
template class dynamic_dispatch;
template <
typename TC,
typename TR,
typename TD,
typename... TA
> class dynamic_dispatch {
struct entry {
};
typedef std::unique_ptr entry_ptr;
entry_ptr m_Start;
template void attach_handler(TR
(UC::*m)(UD&, TA...));
};
template <
typename TC,
typename TR,
typename TD,
typename... TA
> template <
typename UC,
typename UD
> void dynamic_dispatch::attach_handler(TR
(UC::*m)(UD&, TA...)) {
entry* p = m_Cursor;
if (p != m_Start.get()) {
} while(--p != m_Start.get());
}
class __attribute__((dllexport)) request {
};
template class read_request : public read_request_base
{
};
template class request_dispatcher
: private base::dynamic_dispatch {
request_dispatcher();
};
class __attribute__((dllexport)) file_reader : public physical_device {
void execute_command(read_request<0>& req);
};
template <> request_dispatcher::request_dispatcher()
: super(&file_reader::report_unsupported_request) {
attach_handler(&file_reader::execute_command);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug tree-optimization/42366] ICE in ipa_write_node_info, at ipa-prop.c:2023
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-12-21 17:55 --- This happens because IPA-CP (as opposed to indirect inlining) does not perform parameter modification analysis but the associated streaming (which is shared in between the two) code assumes it has been done. I will prepare a patch to address this shortly. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-21 17:55:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42366
[Bug c++/42447] [4.5 Regresson] ICE during processing complex templates
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-21 18:33
---
Ok, thanks. From your work I produced the below, which doesn't use any C++0x
feature and to me looks like a 4.5 Regression.
///
template
struct tuple { };
template
void*
get(const tuple<_Tp, _Up>&);
template
struct unique_ptr;
template
struct unique_ptr<_Tp[], _Tp_Deleter>
{
typedef tuple<_Tp*, _Tp_Deleter> __tuple_type;
void*
get() const
{ return ::get<0>(_M_t); }
__tuple_type _M_t;
};
struct release_deleter;
template class dynamic_dispatch;
template
struct dynamic_dispatch
{
struct entry { };
typedef unique_ptr entry_ptr;
entry_ptr m_Start;
template
void attach_handler(TR (UC::*m)(UD&))
{
entry* p = 0;
if (p != m_Start.get()) {
} while(--p != m_Start.get());
}
};
struct request;
struct read_request;
template
class request_dispatcher
: private dynamic_dispatch
{ request_dispatcher(); };
struct file_reader
{
void execute_command(read_request&);
};
template <>
request_dispatcher::request_dispatcher()
{
attach_handler(&file_reader::execute_command);
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC|piotr dot wyderski at gmail |jason at gcc dot gnu dot org
|dot com |
Known to fail||4.5.0
Known to work||4.4.1
Priority|P3 |P1
Summary|[C++0x] ICE during |[4.5 Regresson] ICE during
|processing complex templates|processing complex templates
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42450] New: another GCC 4.5 ICE on C++ templated code
Hi, Thanks to bug #42225 being now fixed, I was able to continue the build of Eigen's unit tests, and I hit another ICE. It's probably the last one though, as it occurred at 97% into the build process. Attached file autodiff.ii.bz2 allows to reproduce it. To reproduce it: bunzip2 autodiff.ii.bz2 g++-svn autodiff.ii Here the errors happens with GCC SVN from today, December 21. The same .ii file compiles nicely with GCC 4.4. My platform is Linux x86-64. Below is the compiler output when I generated the .ii file: # 13:46:13 ~/build/eigen/unsupported/test$ /usr/local/bin/g++-svn -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fexceptions -fno-check-new -fno-common -fstrict-aliasing -Wextra -pedantic -g2 -g0 -O2 -fno-inline-functions -I/home/bjacob/build/eigen/unsupported/test -I/home/bjacob/eigen/unsupported/test -I/home/bjacob/eigen -I/home/bjacob/build/eigen -I/home/bjacob/eigen/unsupported/test/../../test -DEIGEN_TEST_FUNC=autodiff -o CMakeFiles/autodiff.dir/autodiff.cpp.o -c /home/bjacob/eigen/unsupported/test/autodiff.cpp -save-temps -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++-svn COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../repo/configure --prefix=/usr/local --program-suffix=-svn --disable-multilib --enable-threads=posix --enable-maintainer-mode --enable-gnu-unique-object --with-lto CFLAGS='-march=x86-64 -mtune=generic -O2 -pipe' LDFLAGS='-Wl,--hash-style=gnu -Wl,--as-needed' CXXFLAGS='-march=x86-64 -mtune=generic -O2 -pipe' --enable-languages=c,c++,lto --no-create --no-recursion Thread model: posix gcc version 4.5.0 20091221 (experimental) (GCC) COLLECT_GCC_OPTIONS='-Wnon-virtual-dtor' '-Wno-long-long' '-ansi' '-Wundef' '-Wcast-align' '-Wchar-subscripts' '-Wall' '-W' '-Wpointer-arith' '-Wwrite-strings' '-Wformat-security' '-fexceptions' '-fno-check-new' '-fno-common' '-fstrict-aliasing' '-Wextra' '-pedantic' '-g2' '-g0' '-O2' '-fno-inline-functions' '-I/home/bjacob/build/eigen/unsupported/test' '-I/home/bjacob/eigen/unsupported/test' '-I/home/bjacob/eigen' '-I/home/bjacob/build/eigen' '-I/home/bjacob/eigen/unsupported/test/../../test' '-DEIGEN_TEST_FUNC=autodiff' '-o' 'CMakeFiles/autodiff.dir/autodiff.cpp.o' '-c' '-save-temps' '-v' '-shared-libgcc' '-mtune=generic' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus -E -quiet -v -I/home/bjacob/build/eigen/unsupported/test -I/home/bjacob/eigen/unsupported/test -I/home/bjacob/eigen -I/home/bjacob/build/eigen -I/home/bjacob/eigen/unsupported/test/../../test -D_GNU_SOURCE -DEIGEN_TEST_FUNC=autodiff /home/bjacob/eigen/unsupported/test/autodiff.cpp -mtune=generic -ansi -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -Wextra -pedantic -fexceptions -fno-check-new -fno-common -fstrict-aliasing -fno-inline-functions -O2 -fpch-preprocess -o autodiff.ii ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/bjacob/build/eigen/unsupported/test /home/bjacob/eigen/unsupported/test /home/bjacob/eigen /home/bjacob/build/eigen /home/bjacob/eigen/unsupported/test/../../test /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed
[Bug c++/42450] another GCC 4.5 ICE on C++ templated code
--- Comment #1 from jacob dot benoit dot 1 at gmail dot com 2009-12-21 18:57 --- Created an attachment (id=19358) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19358&action=view) Preprocessed C++ source triggering this ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug c++/42225] [4.5 Regression] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #20 from jacob dot benoit dot 1 at gmail dot com 2009-12-21 18:59 --- Thank you, I can confirm that it's fixed here. However I now hit another ICE, see bug #42450, but it seems unrelated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug lto/42451] New: 'warning: type of "array" does not match original declaration' with -flto/-fwhopr
Command line: g++ B.ii C.ii -fPIC -shared -flto or g++ B.ii C.ii -fPIC -shared -fwhopr Tested revisions: r155363 - warns r155248 - warns r155141 - warns r154886 - warns Output (r155363, r155248): $ /mnt/svn/gcc-trunk/binary-155363-lto/bin/g++ B.ii C.ii -fPIC -shared -fwhopr header.hpp:10:19: warning: type of ‘array’ does not match original declaration B.cpp:7:14: note: previously declared here Output (r155141, r154886): $ /mnt/svn/gcc-trunk/binary-155141-lto-checking-release/bin/g++ B.ii C.ii -fPIC -shared -fwhopr header.hpp:10:19: warning: type of ‘array’ does not match original declaration B.cpp:7:14: note: previously declared here /tmp/cclAkKXS.wpa.ltrans.o:(.bss._ZN1B5arrayE[_ZN1B5arrayE]+0x0): multiple definition of `_ZN1B5arrayE' /tmp/ccv6HwKA.wpa.ltrans.o:(.bss+0x20): first defined here /tmp/cclAkKXS.wpa.ltrans.o:(.bss.c[c]+0x0): multiple definition of `c' /tmp/ccv6HwKA.wpa.ltrans.o:(.bss+0x0): first defined here collect2: ld returned 1 exit status -- Summary: 'warning: type of "array" does not match original declaration' with -flto/-fwhopr Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42451
[Bug lto/42451] 'warning: type of "array" does not match original declaration' with -flto/-fwhopr
--- Comment #1 from zsojka at seznam dot cz 2009-12-21 19:06 --- Created an attachment (id=19359) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19359&action=view) first source file (preprocessed, reduced) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42451
[Bug lto/42451] 'warning: type of "array" does not match original declaration' with -flto/-fwhopr
--- Comment #2 from zsojka at seznam dot cz 2009-12-21 19:06 --- Created an attachment (id=19360) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19360&action=view) second source file (preprocessed, reduced) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42451
[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure
--- Comment #2 from ubizjak at gmail dot com 2009-12-21 19:36 --- This happens on !TARGET_BWX targets. Unaligned HImode access can cross widened SImode boundaries. Following patch triggers on this invalid condition in get_aligned_mem: Index: alpha.c === --- alpha.c (revision 155372) +++ alpha.c (working copy) @@ -1475,6 +1475,10 @@ get_aligned_mem (rtx ref, rtx *paligned_ else offset = disp & 3; + /* The location should not cross aligned word boundary. */ + gcc_assert (offset + GET_MODE_SIZE (GET_MODE (ref)) + <= GET_MODE_SIZE (SImode)); + /* Access the entire aligned word. */ *paligned_mem = widen_memory_access (ref, SImode, -offset); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42448
[Bug c++/35669] NULL (__null) not considered different from 0 with C++
--- Comment #14 from mdorey at bluearc dot com 2009-12-21 20:02 --- > so [implicit] conversion from NULL to int is OK. That's true where NULL is defined as 0 (or eg 0L), but that's not the only permitted definition of NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
[Bug driver/42442] [4.5 Regression] -march=native doesn't apply to multiple files
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-21 20:17 --- The problem is in the check_live_switch change. As -march=native spec handling uses % 1 remember the SWITCH_IGNORE settings of each of the switches in some array and before we start handling next source file reset it back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
[Bug lto/42451] 'warning: type of "array" does not match original declaration' with -flto/-fwhopr
--- Comment #3 from zsojka at seznam dot cz 2009-12-21 20:19 --- I am also receiving ICE (with checking enabled) probably caused by this incompability. I can provide reduced sources if needed, demonstrating that (it would probably take several days of reducing). The crash message in that case is: lto1: internal compiler error: in input_gimple_stmt, at lto-streamer-in.c:1093 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42451
[Bug c++/42447] [4.5 Regresson] ICE during processing complex templates
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-21 20:29
---
A tad simpler:
template
void* get(int);
template
struct unique_ptr;
template
struct unique_ptr<_Tp[]>
{
typedef int __tuple_type;
void*
get() const
{ return ::get<0>(_M_t); }
__tuple_type _M_t;
};
template class dynamic_dispatch;
template
struct dynamic_dispatch
{
struct entry { };
unique_ptr m_Start;
template
void attach_handler(void (UC::*m)(int&))
{
entry* p = 0;
do {
} while(--p != m_Start.get());
}
};
template
class request_dispatcher
: private dynamic_dispatch
{ request_dispatcher(); };
struct file_reader
{
void execute_command(int&);
};
template <>
request_dispatcher::request_dispatcher()
{ this->attach_handler(&file_reader::execute_command); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [4.5 Regresson] ICE during processing complex templates
--- Comment #14 from hjl dot tools at gmail dot com 2009-12-21 20:54 --- It is caused by revision 151461: http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00207.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c/42452] New: The application stack can be corrupted when an interrupt occurs somewhere
The options given when GCC was configured/built:
Using built-in specs.
Target: arm-none-eabi
Configured with: /scratch/julian/2009q3-respin-eabi-lite/src/gcc-4.4/configure
--build=i686-pc-linux-gnu --host=i686-min
gw32 --target=arm-none-eabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extr
a-sgxxlite-multilibs --with-gnu-as --with-gnu-ld
--with-specs='%{O2:%{!fno-remove-local-statics: -fremove-local-statics}
} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --disable-shar
ed --disable-lto --with-newlib --with-pkgversion='Sourcery G++ Lite 2009q3-68'
--with-bugurl=https://support.codesourcer
y.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-non
e-eabi
--with-build-sysroot=/scratch/julian/2009q3-respin-eabi-lite/install/host-i686-mingw32/arm-none-eabi
--with-libic
onv-prefix=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr
--with-gmp=/sc
ratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr
--with-mpfr=/scratch/julian/
2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr
--with-ppl=/scratch/julian/2009q3-respin-
eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-mingw32/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lst
dc++,-Bdynamic -lm'
--with-cloog=/scratch/julian/2009q3-respin-eabi-lite/obj/host-libs-2009q3-68-arm-none-eabi-i686-ming
w32/usr --disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/julian/2009q3-respin-eabi-
lite/obj/tools-i686-pc-linux-gnu-2009q3-68-arm-none-eabi-i686-mingw32/arm-none-eabi/bin
--with-build-time-tools=/scratch
/julian/2009q3-respin-eabi-lite/obj/tools-i686-pc-linux-gnu-2009q3-68-arm-none-eabi-i686-mingw32/arm-none-eabi/bin
Thread model: single
gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68)
0011c6d0 :
11c6d0: b510push{r4, lr}
11c6d2: b082sub sp, #8
11c6d4: 466cmov r4, sp
11c6d6: 3406addsr4, #6
11c6d8: 201dmovsr0, #29
11c6da: 1c21addsr1, r4, #0
11c6dc: 2201movsr2, #1
11c6de: f7ff ff6f bl 11c5c0
11c6e2: b002add sp, #8
11c6e4: 8820ldrhr0, [r4, #0]
11c6e6: bc10pop {r4}
11c6e8: bc02pop {r1}
11c6ea: 4708bx r
The returned value (r0) of the above function will be overwritten when an
interrupt occurs between address 11c6e2 and address 11c6e4 and the interrupt
service routine shares same stack with the above function. I think the quick
fix is to swap the instructions between address 11c6e2 and address 11c6e4.
--
Summary: The application stack can be corrupted when an interrupt
occurs somewhere
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cwang at rossvideo dot com
GCC host triplet: Windows or CygWin
GCC target triplet: ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42452
[Bug c/42452] The application stack can be corrupted when an interrupt occurs somewhere
--- Comment #1 from cwang at rossvideo dot com 2009-12-21 21:27 --- Actually, The value which r4 points to in the above function will be corrupted when an interrupt occurs between address 11c6e2 and address 11c6e4 and the interrupt service routine shares a same stack with the above function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42452
[Bug lto/42426] ICE in get_resolution (lto)
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-12-21 21:42 --- Created an attachment (id=19361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19361&action=view) Small testcase Run `gcc -flto -fuse-linker-plugin 1.c 2.c' (or just `gcc -flto -fuse-linker-plugin 1.c') to reproduce the bug. -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Attachment #19343|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42426
[Bug target/42452] The application stack can be corrupted when an interrupt occurs somewhere
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42452
[Bug target/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-12-21 21:46 --- *** Bug 42452 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||cwang at rossvideo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug target/42452] The application stack can be corrupted when an interrupt occurs somewhere
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-21 21:46 --- *** This bug has been marked as a duplicate of 38644 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42452
[Bug c++/42450] another GCC 4.5 ICE on C++ templated code
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-21 22:04 --- It is caused by revision 151696: http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00443.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-21 22:04:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug lto/42453] New: Assertion `syms' failed in lto-plugin
touch xxx.c gcc -flto -fuse-linker-plugin xxx.c collect2: ld terminated with signal 6 [Aborted] ld: ../../gcc-4.5/lto-plugin/lto-plugin.c:325: write_resolution: Assertion `syms' failed. -- Summary: Assertion `syms' failed in lto-plugin Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42453
[Bug lto/42453] Assertion `syms' failed in lto-plugin
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-12-21 22:32 --- Created an attachment (id=19362) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19362&action=view) Backtrace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42453
[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|ICE with pointer-to-member- |[4.5 Regression] ICE with |function argument in|pointer-to-member-function |template function |argument in template ||function Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug debug/42454] New: debug_ranges table contains empty range for unused .text section with -ffunction-sections
When -ffunction-sections is turned on with -g2, gcc emits an entry into the
.debug_ranges section for the DW_TAG_compile_unit for the range (.Ltext,
.Letext) unconditionally. With -ffunction-sections, the .text section remains
unused, and this entry in .debug_ranges refers to a zero-length range.
That's not normally a problem, but when --gc-sections is turned on in the
linker, the empty .text section can be removed, and the relocations for that
range apply zeroes to that entry, and it now looks like the end of the range
list. Because that's actually the first range entry that gcc emits for the
compile unit, DWARF consumers see an empty range list. This causes significant
slowdowns for objdump and addr2line.
Example:
$ cat foo.c
int foo(int i)
{
return i + 1;
}
int bar(int i)
{
return i + 2;
}
$ gcc -S -dA -g -ffunction-sections foo.c
The resulting assembly code has this:
.text
.Ltext0:
.section.text.foo,"ax",@progbits
.globl foo
.type foo, @function
foo:
.LFB0:
...
.text
.Letext0:
...
.section.debug_ranges,"",@progbits
.Ldebug_ranges0:
.quad .Ltext0 # Offset 0x0
.quad .Letext0
.quad .LFB0 # Offset 0x10
.quad .LFE0
.quad .LFB1 # Offset 0x20
.quad .LFE1
.quad 0x0
.quad 0x0
--
Summary: debug_ranges table contains empty range for unused .text
section with -ffunction-sections
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: ccoutant at gcc dot gnu dot org
ReportedBy: ccoutant at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux
GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug debug/42454] debug_ranges table contains empty range for unused .text section with -ffunction-sections
--- Comment #1 from ccoutant at gcc dot gnu dot org 2009-12-21 23:13 --- Created an attachment (id=19363) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19363&action=view) Proposed fix for PR 42454 * dwarf2out.c (dwarf2out_finish): Don't output range for .text section unless .text section was used. Likewise for cold. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug fortran/42422] Error in Fortran list directed input
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-12-21 23:14 --- Test case committed to trund and 4.4 branch. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42422
[Bug debug/42454] debug_ranges table contains empty range for unused .text section with -ffunction-sections
-- ccoutant at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-21 23:56:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
[Bug testsuite/36903] Generic vectorizarion test failures
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-12-22 00:01 --- Subject: Bug 36903 Author: hutchinsonandy Date: Tue Dec 22 00:00:50 2009 New Revision: 155382 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155382 Log: 2009-12-21 Andy Hutchinson PR testsuite/36903 * gcc.dg/tree-ssa/gen-vect-11.c : Disable for avr target. It will not vectorize. * gcc.dg/tree-ssa/gen-vect-11a.c: Ditto. * gcc.dg/tree-ssa/gen-vect-2.c: Ditto. * gcc.dg/tree-ssa/gen-vect-25.c: Ditto. * gcc.dg/tree-ssa/gen-vect-26.c: Ditto. * gcc.dg/tree-ssa/gen-vect-28.c: Ditto. * gcc.dg/tree-ssa/gen-vect-32.c: Ditto. * gcc.dg/tree-ssa/pr23455.c: Test for 4 eliminations on avr target. * gcc.dg/tree-ssa/ssa-fre-26.c: XFAIL test for avr. * gcc.dg/tree-ssa/vrp47.c: Skip test for avr target due to low branch cost. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11a.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23455.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-26.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36903
[Bug debug/42455] New: "-fcompare-debug failure" at -O2 in 'recent' builds
Command line: g++ -fcompare-debug -O2 testcase.ii Tested revisions: r155363 - crash r155256 - crash r155141 - crash r154886 - crash r154830 - OK r153685 - OK 4.4 - doesn't know -fcompare-debug Output: $ /mnt/svn/gcc-trunk/binary-155363-lto/bin/g++ -fcompare-debug testcase.ii -O2 g++: testcase.ii: -fcompare-debug failure -- Summary: "-fcompare-debug failure" at -O2 in 'recent' builds Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42455
[Bug debug/42455] "-fcompare-debug failure" at -O2 in 'recent' builds
--- Comment #1 from zsojka at seznam dot cz 2009-12-22 00:07 --- Created an attachment (id=19364) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19364&action=view) original testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42455
[Bug testsuite/36903] Generic vectorizarion test failures
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-12-22 00:16 --- Fixed 4.5. AVR wont vectorize with word size of 1 byte! -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36903
[Bug debug/42455] "-fcompare-debug failure" at -O2 in 'recent' builds
--- Comment #2 from zsojka at seznam dot cz 2009-12-22 00:10 --- Created an attachment (id=19365) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19365&action=view) somewhat reduced testcase Reducing the testcase is quite complicated, removing seemingly irrelevant lines causes the crash to disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42455
[Bug libstdc++/42456] New: [4.5 Regression] Revision 155377 failed some atomic tests
On Linux/ia32, revision 155377 caused: FAIL: 29_atomics/atomic_flag/clear/1.cc (test for excess errors) FAIL: 29_atomics/atomic_flag/test_and_set/explicit.cc (test for excess errors) FAIL: 29_atomics/atomic_flag/test_and_set/implicit.cc (test for excess errors) -- Summary: [4.5 Regression] Revision 155377 failed some atomic tests Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42456
[Bug debug/42455] "-fcompare-debug failure" at -O2 in 'recent' builds
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-22 01:52 --- It is caused by revision 154869: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00013.html -- hjl dot tools at gmail dot com 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 |2009-12-22 01:52:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42455
[Bug middle-end/42169] [4.4/4.5 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #1 from danglin at gcc dot gnu dot org 2009-12-22 03:09 --- Compiles successfully without -fbounds-check on hppa-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug c/42457] New: AVR fails to build unless LTO is disabled
AVR will fail to build with (default) LTO enabled. LTO becomes enabled when a working libelf implementation is found. Mike Stein brought this to my attention and I have been able to replicate it now I have loaded libelf. The undefined symbol `builtin_define_std' is defined in c-cppbuiltin.c. It would appear this is not linked for some of lto compilations - yet target avr.c is. The root cause seems to be that avr target uses `builtin_define_std' inside a staic function `avr_cpu_cpp_builtins' (avr.c) - whereas is used to be used inside a macro (avr.h). On most (all?) other targets it is used inside a macro When the macro is not used, there is no definition needed and no link error. A relevant change on avr target was made 149519 2009-07-11 Anatoly Sokolov * config/avr/avr.h (TARGET_CPU_CPP_BUILTINS): Redefine. (avr_extra_arch_macro) Remove declatation. * config/avr/avr.c (avr_cpu_cpp_builtins): New function. (avr_extra_arch_macro) Declare as static. * config/avr/avr-protos.h (avr_cpu_cpp_builtins): Dclare. Using --disable-lto switch for configure allows build to complete. -- Summary: AVR fails to build unless LTO is disabled Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hutchinsonandy at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457
[Bug c/42457] AVR fails to build unless LTO is disabled
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-12-22 03:20 --- Created an attachment (id=19366) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19366&action=view) Make log file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457
[Bug target/42457] [4.5 Regression] AVR fails to build with other than C family languages
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-22 03:29 --- A way to fix this is to have avr-c.c like most other targets have. And declare avr_cpu_cpp_builtins in there. Note this change broke other languages besides C/C++/Objective-C/Objective-C++ so this is a regression as at one point Ada was building. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet|avr-unknown-none|avr-*-* Keywords||build Last reconfirmed|-00-00 00:00:00 |2009-12-22 03:29:41 date|| Summary|AVR fails to build unless |[4.5 Regression] AVR fails |LTO is disabled |to build with other than C ||family languages Target Milestone|--- |4.5.0 Version|lto |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457
[Bug libstdc++/42456] [4.5 Regression] Revision 155377 failed some C++ tests
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-22 03:36 --- It may also have caused: UNRESOLVED: attribute_plugin.c compilation, -I. -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../gcc -I/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../../gcc -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../include -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../libcpp/include -DIN_GCC -fPIC -shared UNRESOLVED: dumb_plugin.c compilation, -I. -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../gcc -I/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../../gcc -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../include -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../libcpp/include -DIN_GCC -fPIC -shared -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression] Revision |[4.5 Regression] Revision |155377 failed some atomic |155377 failed some C++ tests |tests | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42456
[Bug libstdc++/42456] [4.5 Regression] Revision 155377 failed some C++ tests
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-12-22 04:20 --- HJ what are the excess errors that you see (from libstdc++.log file?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42456
[Bug bootstrap/42345] cannot force 32 bit toolchain only
--- Comment #23 from bkoz at gcc dot gnu dot org 2009-12-22 04:33 --- thanks HJ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42345
[Bug libstdc++/42456] [4.5 Regression] Revision 155377 failed some C++ tests
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-22 05:56 --- I got /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc:28: undefined reference to `std::__atomic0::atomic_flag::clear(std::memory_order)'^M /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc:29: undefined reference to `std::__atomic0::atomic_flag::test_and_set(std::memory_order)'^M /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc:30: undefined reference to `std::__atomic0::atomic_flag::test_and_set(std::memory_order)'^M -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42456
[Bug libstdc++/42456] [4.5 Regression] Revision 155377 failed some C++ tests
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-22 06:03 --- (In reply to comment #1) > It may also have caused: > > UNRESOLVED: attribute_plugin.c compilation, -I. > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../gcc > -I/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../../gcc > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../include > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../libcpp/include > > -DIN_GCC -fPIC -shared > UNRESOLVED: dumb_plugin.c compilation, -I. > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../gcc > -I/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../../gcc > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../include > -I/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/../../libcpp/include > > -DIN_GCC -fPIC -shared > This is caused by: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00523.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42456
[Bug translation/42458] New: 33 typos in gcc-4.5-b20091203.pot file
I have picked the following lines from file gcc-4.5-b20091203.pot: #: c-common.c:7053 c-common.c:7145 #, gcc-internal-format msgid "can%'t set %qE attribute after definition" #: c-decl.c:1533 #, gcc-internal-format msgid "a parameter list with an ellipsis can%'t match an empty parameter name list declaration" Is this above really gcc-internal-format ? There are more like this below, but I do not mark them any more. #: c-decl.c:1540 #, gcc-internal-format msgid "an argument type that has a default promotion can%'t match an empty parameter name list declaration" #: c-decl.c:4215 varasm.c:2139 #, gcc-internal-format msgid "storage size of %q+D isn%'t known" #: c-decl.c:4226 #, gcc-internal-format msgid "storage size of %q+D isn%'t constant" #: c-decl.c:4647 #, gcc-internal-format msgid "ISO C90 forbids array %qE whose size can%'t be evaluated" #: c-decl.c:4651 #, gcc-internal-format msgid "ISO C90 forbids array whose size can%'t be evaluated" #: c-decl.c:4670 #, gcc-internal-format msgid "the size of array %qE can%'t be evaluated" #: c-decl.c:4674 #, gcc-internal-format msgid "the size of array can %'t be evaluated" #: c-decl.c:6051 c-decl.c:7467 #, gcc-internal-format msgid "function declaration isn%'t a prototype" #: c-decl.c:6561 #, gcc-internal-format msgid "ISO C doesn%'t support unnamed structs/unions" #: c-decl.c:7778 #, gcc-internal-format msgid "number of arguments doesn%'t match built-in prototype" #: c-decl.c:7789 #, gcc-internal-format msgid "number of arguments doesn%'t match prototype" #: c-decl.c:7826 #, gcc-internal-format msgid "promoted argument %qD doesn%'t match built-in prototype" #: c-decl.c:7831 #, gcc-internal-format msgid "promoted argument %qD doesn%'t match prototype" #: c-decl.c:7841 #, gcc-internal-format msgid "argument %qD doesn%'t match built-in prototype" #: c-decl.c:7846 #, gcc-internal-format msgid "argument %qD doesn%'t match prototype" #: c-pch.c:132 #, gcc-internal-format msgid "can%'t create precompiled header %s: %m" #: c-pch.c:153 #, gcc-internal-format msgid "can%'t write to %s: %m" PLS, can you write this above more explicitly: "cannot write to file %s: %m" or something like that #: c-pch.c:188 c-pch.c:203 c-pch.c:217 #, gcc-internal-format msgid "can%'t write %s: %m" More explicitly here too. Write what? A file, a string, a field? Translators would appreciate if it were more explicitly. #: c-pch.c:193 c-pch.c:210 #, gcc-internal-format msgid "can%'t seek in %s: %m" More explicitly, PLS. #: c-pch.c:201 c-pch.c:243 c-pch.c:284 c-pch.c:335 #, gcc-internal-format msgid "can%'t read %s: %m" More explicitly, PLS. #: c-pch.c:473 #, gcc-internal-format msgid "%s: couldn%'t open PCH file: %m" #: c-typeck.c:739 #, gcc-internal-format msgid "can%'t mix operands of decimal float and vector types" #: c-typeck.c:744 #, gcc-internal-format msgid "can%'t mix operands of decimal float and complex types" #: c-typeck.c:744 #, gcc-internal-format msgid "can%'t mix operands of decimal float and complex types" #: c-typeck.c:749 #, gcc-internal-format msgid "can%'t mix operands of decimal float and other float types" #: stmt.c:900 #, gcc-internal-format msgid "asm operand %d probably doesn%'t match constraints" #: stor-layout.c:160 #, gcc-internal-format msgid "type size can%'t be explicitly evaluated" #: toplev.c:2051 #, gcc-internal-format msgid "can%'t open %s: %m" More explicitly, PLS. #: tree-cfg.c:3937 #, gcc-internal-format msgid "statement marked for throw, but doesn%'t" #: varasm.c:1375 #, gcc-internal-format msgid "data type of %q+D isn%'t suitable for a register" #: varasm.c:1378 #, gcc-internal-format msgid "register specified for %q+D isn%'t suitable for data type" -- Summary: 33 typos in gcc-4.5-b20091203.pot file Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: karvonen dot jorma at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42458
