[Bug target/42509] bootstrap failure in stage3 (integer overflow in preprocessor expression)
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-29 10:08:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug regression/42532] New: configuring with --enable-gold introduces many regressions in the testsuite
a biarch build from trunk (r155486) on x86_64 configured with --enable-gold and gold providing ld introduces the regressions as shown in the diff. gold was built from the binutils 2.20 branch. The two complete test summaries are: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02390.html http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02462.html Matthias -- Summary: configuring with --enable-gold introduces many regressions in the testsuite Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42532
[Bug regression/42532] configuring with --enable-gold introduces many regressions in the testsuite
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29 10:11 --- Created an attachment (id=19409) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19409action=view) test summary diff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42532
[Bug c++/42533] New: boost_concept_check.h - _SGIAssignableConcept broken the class self contains
for example, I have a class like this:
class MyClass
{
public:
MyClass() ...
MyClass(IN const MyClass rhs) ...
MyClass operator=(IN const MyClass rhs)...
private:
typedef std::map string, MyClass KEYTBL; // Self contains
struct PROP {
...
KEYTBL tblKeys;
...
};
typedef SMART_POINTER PROP HPROP;
HPROP m_hProp;
};
As the example shown, If with out (early and msvc) the boost concept check,
then everything is perfect ok, Because C++ will try to instantiation the map
only when we need to use it. BUT the boost conept check (_SGIAssignableConcept)
just broken the c++ delay instantiation rule, so everything is broken here.
--
Summary: boost_concept_check.h - _SGIAssignableConcept broken the
class self contains
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baiyang at gmail dot com
GCC host triplet: OpenSolaris 2009.06 x86
GCC target triplet: OpenSolaris 2009.06 x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42533
[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM
--- Comment #11 from ramana at gcc dot gnu dot org 2009-12-29 10:24 --- (In reply to comment #7) (In reply to comment #5) I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing the backport of __sync_synchronize() support to regress. I'm currently testing 4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): that cured the build failure, but the testsuite run is not yet finished. The testsuite run now finished with no regressions compared to 4.4 snapshots from before this regression. Can you or Matthias submit this patch to gcc-patc...@gcc.gnu.org ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
[Bug libgcj/40180] [4.4/4.5 regression] regressions in libjava testsuite on ia64-linux
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29 10:30 --- seen on a ia64-suse-linux-gnu build as well (and on a recent debian build): http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02466.html Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
[Bug c/42494] [4.4 only] Regression on dead-code-elimination: GCC 4.2.1 generates better code than 4.4.0
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-29 10:35 --- I can confirm this as a problem on the 4.4 branch and I can see this isn't a problem on trunk . .arch armv5te .fpu softvfp .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 1 .eabi_attribute 30, 4 .eabi_attribute 18, 4 .code 16 .file t.c .text .align 1 .global test .code 16 .thumb_func .type test, %function test: ldr r3, .L4 mov r2, #0 str r2, [r3] ldr r3, .L4+4 @ sp needed for prologue ldr r2, [r3] sub r3, r2, #1 sbc r2, r2, r3 ldr r3, .L4+8 lsl r2, r2, #1 strbr2, [r3] bx lr .L5: .align 2 .L4: .word outcnt .word bool_var .word outbuf .size test, .-test .ident GCC: (GNU) 4.5.0 20091223 (experimental) -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-29 10:35:21 date|| Summary|Regression on dead-code-|[4.4 only] Regression on |elimination: GCC 4.2.1 |dead-code-elimination: GCC |generates better code than |4.2.1 generates better code |4.4.0 |than 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
[Bug libgcj/40181] [4.4 Regression] regressions in libjava testsuite on s390-linux
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29 10:43 --- seen with 20091228/29 as well: https://buildd.debian.org/fetch.cgi?pkg=gcj-4.4ver=4.4.2-7arch=s390stamp=1261836998file=log http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02429.html results on the trunk don't show this failure: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02453.html https://buildd.debian.org/fetch.cgi?pkg=gcc-snapshotver=20091228-2arch=s390stamp=1262082415file=log Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40181
[Bug c++/42533] boost_concept_check.h - _SGIAssignableConcept broken the class self contains
--- Comment #1 from baiyang at gmail dot com 2009-12-29 10:43 --- PS: the above example is a typical usage of the self contain skill. In this exapmle, the coder will ensure every really usage point (i.e. every possible template instantiation point) of 'm_hProp-tblKeys' in the code are all at outside of MyClass' defination scope. So we guarantee the class has been fully defined before using it. BUT the concept check just cancelled the delay instantiation mechanism, so the code doesn't work anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42533
[Bug libstdc++/42533] boost_concept_check.h - _SGIAssignableConcept broken the class self contains
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-29 10:56 --- After so many years since that idea, we are not interested in squeezing more from that interesting (but outdated) idea of simulating concept checks in the library. Long term, we want proper concept checks in the language. Thus, please just build your translation unit without defining _GLIBCXX_CONCEPT_CHECKS (or do not build the entire library with --enable-concept-checks and enable the checks only on a case by case basis) -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42533
[Bug c/42494] [4.4 Regression] Missed dead-code-elimination: GCC 4.2.1 generates better code than 4.4.0
--- Comment #2 from steven at gcc dot gnu dot org 2009-12-29 11:31 --- The if (outcnt == 1) func (); bit is optimized for me with gcc-4.4.2 on x86_64 at -O1 and -O2, but not at -Os. I was a bit too hasty to call this alias related, it seems. The O2 and Os tree dumps start to diverge in the dom1 dump, where we have just one call to func after dom1 at -O2 and still two calls at -O2. -- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords|alias | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
[Bug lto/42534] New: ICE with -flto when using __attribute__((__aligned__(X)))
I'm hitting an ICE on gcc svn from 20091229 when building the Linux kernel with
-flto. A cutdown test case:
struct zot
{
void *p;
int *padding;
} __attribute__((__aligned__(128)));
void foo(struct zot *buf)
{
int i;
for (i = 0; i 4; i++)
buf-padding[i] = 0;
}
# gcc -m64 -O2 -flto -c -o test.o test.c
# gcc -m64 -O2 -flto -r -o test2.o test.o -nostdlib
In file included from :0:0:
test.c: In function 'foo':
test.c:7:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: /root/gcc-installed/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status
--
Summary: ICE with -flto when using
__attribute__((__aligned__(X)))
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc64-linux-gnu-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42534
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #7 from schwab at linux-m68k dot org 2009-12-29 11:58 --- Please report that to the provider of your inofficial builds. Neither m68k-amigaos nor m68k-atari-mint are supported by the official sources. -- schwab at linux-m68k dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug rtl-optimization/42535] New: unable to find a register to spill in class 'DREG'
seen with current 4.3 and 4.4 branches, not with trunk. removing
-fschedule-insns lets the build succeed.
Matthias
$ g++-4.4 -c -O1 -fsched-interblock -fsched-spec -fschedule-insns2
-fstrict-aliasing -fstrict-overflow -ftree-pre -ftree-vrp -fcaller-saves
-fcrossjumping -fcse-follow-jumps -fcse-skip-blocks
-fdelete-null-pointer-checks -fpeephole2 -fregmove -freorder-blocks
-freorder-functions -frerun-cse-after-loop -fexpensive-optimizations -fgcse
-fgcse-lm -foptimize-sibling-calls -fthread-jumps -falign-functions
-falign-jumps -falign-loops -falign-labels -finline-functions -funswitch-loops
-fpredictive-commoning -fgcse-after-reload -ftree-vectorize -fschedule-insns
DBmanager.ii
In file included from
/usr/local/include/boost/interprocess/containers/container/vector.hpp:64,
from
/usr/local/include/boost/interprocess/containers/vector.hpp:20,
from shared_defs.h:36,
from DBmanager.h:9,
from DBmanager.cpp:10:
/usr/local/include/boost/interprocess/containers/container/detail/utilities.hpp:
In function 'SizeType
boost::interprocess_container::containers_detail::get_next_capacity(SizeType,
SizeType, SizeType) [with SizeType = long unsigned int]':
/usr/local/include/boost/interprocess/containers/container/detail/utilities.hpp:40:
error: unable to find a register to spill in class 'DREG'
/usr/local/include/boost/interprocess/containers/container/detail/utilities.hpp:40:
error: this is the insn:
(insn 9 67 4 2
/usr/local/include/boost/interprocess/containers/container/detail/utilities.hpp:31
(parallel [
(set (reg/v:DI 2 cx [orig:58 m3 ] [58])
(truncate:DI (lshiftrt:TI (mult:TI (zero_extend:TI (reg/v:DI 5
di [orig:62 max_size ] [62]))
(zero_extend:TI (reg:DI 2 cx [65])))
(const_int 64 [0x40]
(clobber (scratch:DI))
(clobber (reg:CC 17 flags))
]) 343 {*umuldi3_highpart_rex64} (expr_list:REG_DEAD (reg:DI 2 cx [65])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (truncate:DI (lshiftrt:TI (mult:TI
(zero_extend:TI (reg/v:DI 5 di [orig:62 max_size ] [62]))
(const_double -6148914691236517205
[0xaaab] 0 [0x0] 0 [0x0] 0 [0x0]))
(const_int 64 [0x40])))
(nil)
/usr/local/include/boost/interprocess/containers/container/detail/utilities.hpp:40:
confused by earlier errors, bailing out
--
Summary: unable to find a register to spill in class 'DREG'
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42535
[Bug rtl-optimization/42535] unable to find a register to spill in class 'DREG'
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29 12:09 --- Created an attachment (id=19410) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19410action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42535
[Bug rtl-optimization/42535] unable to find a register to spill in class 'DREG'
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-29 12:17 --- You shouldn't use -fschedule-insns on i?86/x86_64. Vlad made some changes in 4.5 that make -fschedule-insns work in most cases on these arches, but in 4.3/4.4 you definitely shouldn't use them. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42535
[Bug target/42536] New: [4.4/4.5 regression] ICE in spill_failure, at reload1.c:2141
seen with 20091228 trunk and 4.4 branch on i486-linux-gnu, not seen with 4.3
branch (opening new report, because PR39431 is fixed for 4.4 and 4.5). Adding
-fomit-frame-pointer avoids the ice.
Matthias
$ /usr/lib/gcc-snapshot/bin/gcc -g -O2 -fno-gcse -fno-inline-functions
-fno-unit-at-a-time -fstack-protector -c cvm.i
cvm.c: In function '_ILCVMInterpreter':
cvm.c:889:1: error: unable to find a register to spill in class 'GENERAL_REGS'
cvm.c:889:1: error: this is the insn:
(insn 11992 11991 11993 863 cvm_ptr.c:66 (set (mem:DI (plus:SI (plus:SI
(mult:SI (reg:SI 6750 [ D.20325 ])
(const_int 8 [0x8]))
(reg/f:SI 6746 [ tempptr.3460 ]))
(const_int 4 [0x4])) [16 S8 A64])
(reg:DI 12123)) 88 {*movdi_2} (expr_list:REG_DEAD (reg:DI 12123)
(expr_list:REG_DEAD (reg:SI 6750 [ D.20325 ])
(expr_list:REG_DEAD (reg/f:SI 6746 [ tempptr.3460 ])
(nil)
cvm.c:889:1: internal compiler error: in spill_failure, at reload1.c:2141
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: [4.4/4.5 regression] ICE in spill_failure, at
reload1.c:2141
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
[Bug target/42536] [4.4/4.5 regression] ICE in spill_failure, at reload1.c:2141
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29 12:41 --- Created an attachment (id=19411) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19411action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
[Bug tree-optimization/42494] [4.4 Regression] Missed dead-code-elimination: GCC 4.2.1 generates better code than 4.4.0
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-29 12:44 --- Steven, (In reply to comment #2) The if (outcnt == 1) func (); bit is optimized for me with gcc-4.4.2 on x86_64 at -O1 and -O2, but not at -Os. I was a bit too hasty to call this alias related, it seems. Yes it seems to go away at O1 and O2. I didn't see any comment from you earlier so not sure what you are referring to here. The O2 and Os tree dumps start to diverge in the dom1 dump, where we have just one call to func after dom1 at -O2 and still two calls at -O2. FWIW I saw this removed by dom2 in trunk at -Os. In any case I think the component ought to be tree-optimization and changed. Cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
[Bug c/42537] New: [PATCH] misc spelling fixes
Misc spelling fixes (found when running the debian lintian tool) -- Summary: [PATCH] misc spelling fixes Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: documentation Severity: trivial Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmh at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
[Bug c/42537] [PATCH] misc spelling fixes
--- Comment #1 from rmh at gcc dot gnu dot org 2009-12-29 12:46 --- Created an attachment (id=19412) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19412action=view) misc spelling fixes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
[Bug c/42537] [PATCH] misc spelling fixes
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-29 12:47 --- Please submit patches to gcc-patc...@gcc.gnu.org rather than attaching the patch here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM
--- Comment #12 from mikpe at it dot uu dot se 2009-12-29 13:05 --- Created an attachment (id=19413) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19413action=view) pr40134 generic + arm bits This is the version of the PR40134 patch I intend to submit, unless Matthias wants to submit his version. This version only adds t-slibgcc-libgcc support and enables it for arm-linux-gnueabi. Mainline and debian also enables it for some powerpc and hppa targets, I'm excluding those bits to avoid involving other targets than arm at this point. (It's easy to enable other targets later on.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
[Bug c/42537] [PATCH] misc spelling fixes
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-29 13:11 --- Yes, I think can then go in as obvious. Actually, in my opinion, this kind of issue with zero impact on the end-user experience, should go *only* to gcc-patches, are not suitable for Bugzilla. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-29 13:11:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
[Bug c/42538] New: ICE on illegal-code: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7369
seen on 4.2, 4.3, 4.4, 4.5 (not checked earlier versions): $ gzip -9v ~/main.i $ gcc-4.4 main.i /home/vladimir/Documents/Sondage/main.c:12: error: declaration of 'Saisie' as array of voids /home/vladimir/Documents/Sondage/main.c:12: error: return type is an incomplete type /home/vladimir/Documents/Sondage/main.c: In function 'Saisie': /home/vladimir/Documents/Sondage/main.c:12: error: expected declaration specifiers before ')' token /home/vladimir/Documents/Sondage/main.c:31: error: expected declaration specifiers before 'main' /home/vladimir/Documents/Sondage/main.c:34: confused by earlier errors, bailing out Preprocessed source stored into /tmp/ccOvpYVY.out file, please attach this to your bugreport. $ /usr/lib/gcc-snapshot/bin/gcc main.i /home/vladimir/Documents/Sondage/main.c:12:6: error: declaration of 'Saisie' as array of voids /home/vladimir/Documents/Sondage/main.c:12:1: internal compiler error: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7369 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE on illegal-code: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7369 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42538
[Bug c/42538] ICE on illegal-code: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7369
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29 13:23 --- Created an attachment (id=19414) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19414action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42538
[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM
--- Comment #13 from debian-gcc at lists dot debian dot org 2009-12-29 13:34 --- looks fine to me (but I cannot approve). I'm using this patch already for package builds without seeing regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
[Bug c++/42539] New: C++0x: I tried to implement is_explicitly_convertible, but all I got was this lousy ICE
I tried to implement C++0x's std::is_explicitly_convertible, but decltype
crashes on my code with an internal compiler error. The code is:
#include type_traits
namespace my_std
{
namespace impl
{
template typename T T make();
template typename From, typename To
decltype( From( make To () ), make std::true_type () ) select();
template typename From, typename To
std::false_type select();
}
template typename From, typename To
struct is_explicitly_convertible
: std::is_same decltype( impl::select From, To ), std::true_type
{
};
}
struct X
{
X( double );
explicit X( int );
};
#define STATIC_ASSERT( X ) static_assert( X, #X )
int main()
{
STATIC_ASSERT(( my_std::is_explicitly_convertible double, X ::value ));
STATIC_ASSERT(( my_std::is_explicitly_convertible int, X ::value ));
STATIC_ASSERT(( !my_std::is_explicitly_convertible void*, X ::value ));
}
Tested on GCC 4.3.3 (Ubuntu 9.04) and 4.4.2 (self-compiled), error messages:
f...@viasko::~/work/test/is_explicitly_convertible$ g++ --version
g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3
Copyright (C) 2008 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.
f...@viasko::~/work/test/is_explicitly_convertible$ g++ -std=c++0x t.cc -o t
t.cc: In instantiation of pwd::is_explicitly_convertibledouble, X:
t.cc:35: instantiated from here
t.cc:21: internal compiler error: in finish_decltype_type, at
cp/semantics.c:4231
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions.
f...@viasko:1:~/work/test/is_explicitly_convertible$ . ~/work/use_gcc.sh
f...@viasko::~/work/test/is_explicitly_convertible$ g++ --version
g++ (GCC) 4.4.2
Copyright (C) 2009 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.
f...@viasko::~/work/test/is_explicitly_convertible$ g++ -std=c++0x t.cc -o t
t.cc: In instantiation of pwd::is_explicitly_convertibledouble, X:
t.cc:35: instantiated from here
t.cc:21: internal compiler error: in finish_decltype_type, at
cp/semantics.c:4689
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
f...@viasko:1:~/work/test/is_explicitly_convertible$
Regards, Daniel
--
Summary: C++0x: I tried to implement is_explicitly_convertible,
but all I got was this lousy ICE
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42539
[Bug other/42540] New: c++ error message [vtable undefined] is unhelpful
class A {
A();
virtual void B();
};
A::A() {}
/* Whoops, I forgot to define A::B() */
$ g++ -Wall a.cc
/usr/lib/../lib/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/tmp/ccaVlePI.o: In function `A::A()':
a.cc:(.text+0xf): undefined reference to `vtable for A'
collect2: ld returned 1 exit status
bug submitter writes:
To be clear: the problem is that the error message only mentions the
constructor, and the vtable. It doesn't mention the method A::B(), which is
actually the problem. On a less-minimal example it could take much longer to
work out what the real problem is.
--
Summary: c++ error message [vtable undefined] is unhelpful
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
--- Comment #1 from gcc at daryl dot haresign dot com 2009-12-29 14:55 --- I've just looked at this again. It seems the T is not being printed in the second case due to the line: 1463!DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION(t) in gcc/cp/error.c, in the function dump_function_name. If I comment out that line, I get the T. I doubt the fix is as simple as that, however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #1 from simon at pushface dot org 2009-12-29 15:01 --- Get a similar failure building GCC 4.3.3: /Users/simon/gcc-build-4.3.3-x86_64/./gcc/xgcc -B/Users/simon/gcc-build-4.3.3-x86_64/./gcc/ -B/opt/gcc-4.3.3-x86_64/x86_64-apple-darwin10.2.0/bin/ -B/opt/gcc-4.3.3-x86_64/x86_64-apple-darwin10.2.0/lib/ -isystem /opt/gcc-4.3.3-x86_64/x86_64-apple-darwin10.2.0/include -isystem /opt/gcc-4.3.3-x86_64/x86_64-apple-darwin10.2.0/sys-include -c -g -O2 -fPIC -pipe -fno-common -W -Wall -gnatpg a-direct.adb -o a-direct.o a-direct.ads:426:09: alignment for Search_Typeb82s must be at least 8 a-direct.ads:426:09: alignment for Search_Typet77s must be at least 8 make[6]: *** [a-direct.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug c++/42539] C++0x: I tried to implement is_explicitly_convertible, but all I got was this lousy ICE
--- Comment #1 from d dot frey at gmx dot de 2009-12-29 15:05 --- Note that the code is actually quite broken, the main problem which causes the ICE is: decltype( impl::select From, To ) which should read something like: decltype( impl::select From, To () ) I meanwhile have a working implementation of is_explicitly_convertible for GCC 4.4.2 (in case someone is interested), so this bug is not a big problem, but since it is an ICE, one might still want to fix it :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42539
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-29 15:05 --- I don't know if there is anything there could be done here since the linker is what is producing the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
[Bug c++/42539] C++0x: I tried to implement is_explicitly_convertible, but all I got was this lousy ICE
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-29 15:05 --- This doesn't crash in mainline, and I'm pretty sure Jason doesn't mean to fix this kind of problem in 4_4-branch at this late time in the branch. I'm Cc-ing him, anyway, because in mainline the first two assertions fail (I don't know if that was intended, I didn't study the actual implementation, in case, please just close it, as worksforme). -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42539
[Bug c++/42539] C++0x: I tried to implement is_explicitly_convertible, but all I got was this lousy ICE
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-29 15:08 --- Ah, ok, read the other message in the audit trail, we can close this. Do you have a copyright assignment on file? In that case, your contribution is certainly welcome, please send your implementation to the libstdc++ mailing list, in the proper format, try to follow the stylistic conventions, etc, of course. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.5.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42539
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-12-29 15:24 --- There is something strange: the report is about a native i386 compiler built on x86-64 but the configure line is for a native x86-64 compiler. Which one is correct? Does the base compiler target i386 or x86-64? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|blocker |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug other/28322] GCC new warnings and compatibility
--- Comment #26 from debian-gcc at lists dot debian dot org 2009-12-29
15:35 ---
No yet quiet right:
$ cat main.c
int main() {}
$ gcc -c -g -Wall -Wno-long-double main.c
main.c: In function 'main':
main.c:1:1: warning: control reaches end of non-void function
At top level:
cc1: warning: unrecognized command line option -Wno-long-double
only when no other warning is present, the warning about the unrecognized
option vanishes:
$ cat main.c
int main() {return 0;}
$ gcc -c -g -Wall -Wno-long-double main.c
$
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug lto/42532] configuring with --enable-gold introduces many fails in the testsuite
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-29 15:42 --- The -flto and -fwhopr are most a GCC bug but the rest of the issues look like gold ld issue and should be reported to binutils. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |lto Summary|configuring with --enable- |configuring with --enable- |gold introduces many|gold introduces many fails |regressions in the testsuite|in the testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42532
[Bug fortran/41219] libgfortran build warnings
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2009-12-29 15:48 --- *** Bug 29313 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
[Bug middle-end/29313] [middle-end]Possible bogus warning: argument 'type' might be clobbered
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-12-29 15:48 --- *** This bug has been marked as a duplicate of 41219 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29313
[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-12-29 15:56 --- 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. Sorry for the delay. Yes, the aforementioned patch is sufficient on Solaris 8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
[Bug other/42541] New: [PATCH] install except.h libfuncs.h version.h (plugin headers)
Please could you install except.h libfuncs.h version.h in the plugin header directory? They're necessary for building dragonegg. -- Summary: [PATCH] install except.h libfuncs.h version.h (plugin headers) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmh dot gcc at aybabtu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42541
[Bug other/42541] [PATCH] install except.h libfuncs.h version.h (plugin headers)
--- Comment #1 from rmh dot gcc at aybabtu dot com 2009-12-29 15:59 --- Created an attachment (id=19415) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19415action=view) makefile patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42541
[Bug c/42537] [PATCH] misc spelling fixes
--- Comment #4 from rmh dot gcc at aybabtu dot com 2009-12-29 16:03 --- Mail to gcc-patches sent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
[Bug other/42542] New: g++ -O3 produces incorrect results for less-than operator
seen at least on x86_64. bug submitter writes:
g++ appears to be (incorrectly) using a signed int comparison when -O3
optimization is enabled. Compiling with -O2 or lower produces the correct
output.
#include numeric
#include iostream
template typename T
struct maximum
{
T operator()(T a, T b)
{
return (a b) ? b : a;
}
};
int main(void)
{
typedef unsigned int T;
T data[13] = {2411691434, 187758716, 2874577865, 1532192406,
850395381, 3670100461, 1052104929, 352534891,
1000719294, 2219234747, 426459, 4166615811,
1898580612};
T init = 0;
T result = std::accumulate(data, data + 13, init, maximumT());
std::cout result std::endl;
return 0;
}
$ g++ -O2 -Wall bug.cpp ./a.out
426459
g++ -O3 -Wall bug.cpp ./a.out
1898580612
--
Summary: g++ -O3 produces incorrect results for less-than
operator
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug lto/42534] ICE with -flto when using __attribute__((__aligned__(X)))
--- Comment #1 from steven at gcc dot gnu dot org 2009-12-29 16:11 --- I can reproduce the ICE, but unfortunately not inside gdb yet. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, lto Last reconfirmed|-00-00 00:00:00 |2009-12-29 16:11:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42534
[Bug target/38651] Can't build bfin-elf-gcc (BASE_REG_CLASS undeclared).
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-12-29 16:18 --- Appears to be fixed (I can build a bfin-unknown-elf compiler on x86_64-apple-darwin10.2.0). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38651
[Bug other/28322] GCC new warnings and compatibility
--- Comment #27 from pmaydell at chiark dot greenend dot org dot uk 2009-12-29 16:18 --- only when no other warning is present, the warning about the unrecognized option vanishes: Um, that is the correct behaviour as described and implemented in this bug, isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug target/41311] [4.5 regression] FFmpeg crashes when converting mpg to avi
--- Comment #10 from schwab at linux-m68k dot org 2009-12-29 16:29 --- m68k-amigaos is not a supported target. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #16 from schwab at linux-m68k dot org 2009-12-29 16:31 --- m68k-amigaos is not a supported target. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug fortran/36192] ICE with wrong index types and bad parens
--- Comment #7 from debian-gcc at lists dot debian dot org 2009-12-29 16:38 --- this appears to be fixed, at least in 4.3.5 and 4.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug other/42525] gtyp-input.list contains 'n' instead of '\n' as separator
--- Comment #1 from rwild at gcc dot gnu dot org 2009-12-29 16:42 --- Created an attachment (id=19416) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19416action=view) patch to avoid tr '\n', for Solaris /usr/bin/tr You can either try the attached patch, or have a POSIX tr early in the $PATH. I think install.texi should be changed to recommend having /usr/xpg4/bin or /usr/xpg6/bin early in $PATH. Does GCC support EBCDIC hosts (that an unconditional change like in this patch would break)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42525
[Bug target/36381] preprocessing, fortran: register include paths and framework
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-29 16:49:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36381
[Bug c++/26155] ICE after error with namespace alias
--- Comment #5 from debian-gcc at lists dot debian dot org 2009-12-29 16:49 --- confirmed with trunk 20091228 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26155
[Bug bootstrap/42529] Stage 1 compiler cannot compile
--- Comment #5 from rwild at gcc dot gnu dot org 2009-12-29 16:52 ---
What happens if you enter /cygdrive/e/Home/cvsroot/gcc-obj/libgcc, create a
small conftest.c with 'int main () {}' and try to compile it with this command:
/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/xgcc
-B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include
-isystem /usr/local/i686-pc-cygwin/sys-include-c -g -O2 conftest.c
If there is still no error, can you add -v and/or run under a debugger to find
out possible error causes or at least the stage at which it fails?
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
CC||rwild at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42529
[Bug c/42543] New: internal compiler error: in gimplify_expr, at gimplify.c:7098
Hello, In the past, I was using gcc 3.4.5 and the code was compiled well. I changed my gcc to version 4.4.1 and this internal compiler occured : main.c:56: internal compiler error: in gimplify_expr, at gimplify.c:7098 That might be helpfull for you, Arnaud -- Summary: internal compiler error: in gimplify_expr, at gimplify.c:7098 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arnaud dot kodeck at lakoco dot be GCC host triplet: Windows 7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
[Bug c/42543] internal compiler error: in gimplify_expr, at gimplify.c:7098
--- Comment #1 from arnaud dot kodeck at lakoco dot be 2009-12-29 17:09 --- Created an attachment (id=19417) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19417action=view) Source file where the bug occured -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
[Bug c/42543] internal compiler error: in gimplify_expr, at gimplify.c:7098
--- Comment #2 from arnaud dot kodeck at lakoco dot be 2009-12-29 17:10 --- Created an attachment (id=19418) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19418action=view) The preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
[Bug middle-end/42543] ICE when using va_arg
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-29 17:17 --- The trunk still ICEs: gimplification failed: (char *) args2.4 nop_expr 0x43600ab8 t.c:56:40: internal compiler error: gimplification failed Please submit a full bug report, That is an ICE with i686-darwin. But I think it will also ICE on GNU/Linux too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|minor |normal Component|c |middle-end GCC host triplet|Windows 7 | GCC target triplet||i?86-*-* Keywords||ice-on-valid-code Summary|internal compiler error: in |ICE when using va_arg |gimplify_expr, at | |gimplify.c:7098 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
[Bug c/42538] ICE on illegal-code: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7369
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-29 17:23 ---
A simple testcase:
[...@gnu-26 rrs]$ cat pr42538.i
void Saisie()[3]{
}
[...@gnu-26 rrs]$ ./143523/usr/bin/gcc -S pr42538.i
pr42538.i:1: error: declaration of Saisie as array of voids
pr42538.i:1: internal compiler error: tree check: expected function_decl, have
var_decl in start_function, at c-decl.c:6113
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[...@gnu-26 rrs]$
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-12-29 17:23:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42538
[Bug c++/42450] another GCC 4.5 ICE on C++ templated code
--- Comment #3 from jacob dot benoit dot 1 at gmail dot com 2009-12-29 17:27 --- Could someone confirm that this is a 4.5 ICE regression and tag it as such? Happy holidays! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #17 from ami_stuff at o2 dot pl 2009-12-29 17:29 --- m68k-amigaos is not a supported target. LOL! So you prefere to not get any bugreports? I reported a few bugs which were next confirmed on the other hardware and after some time fixed, no matter if I use unsupported m68-amigaos target or not. I think that there is no chance to see any m68k-specific bugs fixed, so I will not waste my time in the future. Please don't forget to close the rest of my bugreports, because I also used m68k-amigaos unsupported target. You may also chage status from FIXED to INVALID if you prefere... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug middle-end/42543] ICE when using va_arg
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-29 17:32 ---
I am not sure if
---
char* FormatStringEx (char str[], size_t max_length, char templ[],
void* args, unsigned int flags)
{
...
void *args2;
char *arg,c;
...
while (index-- 0 (arg=va_arg((va_list)args2,char*)) != NULL) ;
...
---
is valid C. But gcc could do better to recover.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
[Bug middle-end/42543] ICE when using va_arg
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-29 17:33 --- Icc 11.1 generates: [...@gnu-6 rrs]$ /opt/intel/Compiler/11.1/059/bin/intel64/icc -S pr42543.c pr42543.c(55): error: cast to type va_list is not allowed while (index-- 0 (arg=va_arg((va_list)args2,char*)) != NULL) ; ^ compilation aborted for pr42543.c (code 2) [...@gnu-6 rrs]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
[Bug middle-end/41956] Segmentation fault when called by mpicc
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2009-12-29 17:42
---
I can confirm the segfault at -O3 with current trunk (rev. 155505) on
x86_64-apple-darwin10.2.0. I also generated a (much) reduced testcase:
void K (int *gpwgts, int *badminpwgt, int *badmaxpwgt)
{
int i;
for (i = 0; i 10; i += 2) {
badminpwgt[i] = badminpwgt[i+1] = gpwgts[i]+gpwgts[i];
badmaxpwgt[i] = badmaxpwgt[i+1] = gpwgts[i]+gpwgts[i];
}
}
The segfault backtrace is:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
vect_analyze_slp (loop_vinfo=value temporarily unavailable, due to
optimizations, bb_vinfo=value temporarily unavailable, due to optimizations)
at gimple.h:33
33 DEF_VEC_P(gimple);
(gdb) bt
#0 vect_analyze_slp (loop_vinfo=value temporarily unavailable, due to
optimizations, bb_vinfo=value temporarily unavailable, due to optimizations)
at gimple.h:33
#1 0x0001007bce67 in vect_analyze_loop (loop=value temporarily
unavailable, due to optimizations) at ../../trunk/gcc/tree-vect-loop.c:1433
#2 0x0001007ca08a in vectorize_loops () at
../../trunk/gcc/tree-vectorizer.c:219
#3 0x00010058d7ae in execute_one_pass (pass=0x100c3ca00) at
../../trunk/gcc/passes.c:1561
#4 0x00010058da7d in execute_pass_list (pass=0x100c3ca00) at
../../trunk/gcc/passes.c:1616
#5 0x00010058da8f in execute_pass_list (pass=0x100c3c820) at
../../trunk/gcc/passes.c:1617
#6 0x00010058da8f in execute_pass_list (pass=0x100c3be60) at
../../trunk/gcc/passes.c:1617
#7 0x0001006b86e8 in tree_rest_of_compilation (fndecl=0x141609900) at
../../trunk/gcc/tree-optimize.c:413
#8 0x0001008731e3 in cgraph_expand_function (node=value temporarily
unavailable, due to optimizations) at ../../trunk/gcc/cgraphunit.c:1544
#9 0x0001008760da in cgraph_optimize () at
../../trunk/gcc/cgraphunit.c:1623
#10 0x0001008766bd in cgraph_finalize_compilation_unit () at
../../trunk/gcc/cgraphunit.c:1093
#11 0x00010001f2a2 in c_write_global_declarations () at
../../trunk/gcc/c-decl.c:9490
#12 0x00010064e322 in toplev_main (argc=4, argv=0x7fff5fbff5d0) at
../../trunk/gcc/toplev.c:1061
#13 0x000108b4 in start ()
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.5.0
Last reconfirmed|-00-00 00:00:00 |2009-12-29 17:42:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41956
[Bug objc/40864] Designated initializers for multi-dimensional arrays fail in Objective-C
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement GCC build triplet|i686-apple-darwin9 | GCC host triplet|i686-apple-darwin9 | GCC target triplet|i686-apple-darwin9 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40864
[Bug target/41595] object-c++ mangled local labels are not correctly recognized.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-12-29 17:48 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41595
[Bug middle-end/42488] [4.4 only] spurious strict-aliasing warning
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-apple-darwin9 | GCC host triplet|i686-apple-darwin9 | GCC target triplet|i686-apple-darwin9 | Known to fail||4.4.2 Known to work|4.5.0 |4.5.0 4.3.2 Last reconfirmed|-00-00 00:00:00 |2009-12-29 17:59:50 date|| Summary|spurious strict-aliasing|[4.4 only] spurious strict- |warning |aliasing warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #18 from bonzini at gnu dot org 2009-12-29 18:01 --- True, it is P5 but it is not invalid. Andreas, if you want to close this as invalid you should first follow the target deprecation process and propose to remove the target for 4.6. -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Priority|P3 |P5 Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug c++/41779] Spurious integral promotion
--- Comment #1 from foo at mailinator dot com 2009-12-29 18:02 --- 5/9 (usual arithmetic conversions) isn't relevant until after 4.5/1 (integral promotions) has happened. Unsigned short *always* promotes to int in rvalue contexts; then *that* int is implicitly converted to double in the context of multiplication by a double (which is what's happening here). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41779
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #3 from simon at pushface dot org 2009-12-29 18:06 --- Sorry if I've caused confusion by misunderstanding the reporting system. I can build GCC4.4.2[i386-apple-darwin10.2.0] using GNAT-GPL-2009[i386-apple-darwin10.2.0]. I then try to build GCC4.4.2[x86_64-apple-darwin10.2.0] using GCC4.4.2[i386-apple-darwin10.2.0], with the reported results. So the problem arises in the middle of the compiler build process; the original host compiler was i386-apple-darwin10.2.0 but by the time the error occurs we're using the stage3 x86_64-apple-darwin10.2.0 compiler (of course it can never be installed because it can't build its RTS). I've been using --build=x86_64-apple-darwin10.2.0 to indicate that I want to build a 64-bit compiler, is that not the right method? (I picked this up from AdaCore's GNAT-GPL-2009, which is x86_64 built on Leopard; it's not a technique mentioned in documentation at gcc.gnu.org). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug fortran/42359] ICEs with specification function and init expression
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-29 18:09 --- (In reply to comment #0) I believe that this code is doubly invalid: (i) You cannot have an automatic array in the main program; and (ii) An automatic array cannot have an initialization expression. Both g95 and ifort report one or both of the errors. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42359
[Bug c/42544] New: Bad codegen with signed short cast to unsigned int, then promoted to unsigned long long
extern int puts(const char *);
int main() {
signed short 8000 = 0x8000;
if ((unsigned int)8000 = 0x1uLL) {
puts(FAIL);
}
return 0;
}
% gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
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.
% gcc -w test.c
% ./a.out
FAIL
Also reproduces with gcc-snapshot (Ubuntu 20090125-0ubuntu1) 4.3.3.
--
Summary: Bad codegen with signed short cast to unsigned int, then
promoted to unsigned long long
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foo at mailinator dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42544
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-29 18:25 --- Are you building on a Core Duo (ie non-EMT64 capable) machine? If not, the default code generation of the Apple system compiler should be to execute and generate x86_64 code under 10.6. You can't take the output of 'gcc -v' literally in 10.6. Apple builds fat binaries for their compiler and it only reports the first set of specifications that it finds. So even when their gcc executes and regenerates x86_64, the output of 'gcc -v' will report i386. I opened a radar on that issue awhile back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-29 18:32 --- You might try current gcc 4.4.2 branch. It contains the latest config.guess which determines the architecture type according to the system compiler's default code generation for intel darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-29 18:33 --- I meant gcc-4_4-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug fortran/36192] ICE with wrong index types and bad parens
--- Comment #8 from kargl at gcc dot gnu dot org 2009-12-29 18:37 --- (In reply to comment #7) this appears to be fixed, at least in 4.3.5 and 4.4.2 The problem still exist on at least x86_64-*-freebsd. troutmask:sgk[216] gfc4x -c homework-2.f90 ... Error: Different shape for array assignment at (1) on dimension 1 (0 and 2) homework-2.f90:8:0: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. troutmask:sgk[217] gfc4x -v Using built-in specs. COLLECT_GCC=/home/sgk/work/4x/bin/gfortran COLLECT_LTO_WRAPPER=/usr/home/sgk/work/4x/bin/../libexec/gcc/x86_64-unknown-freebsd9.0/4.5.0/lto-wrapper Target: x86_64-unknown-freebsd9.0 Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x --enable-languages=c,fortran Thread model: posix gcc version 4.5.0 20091222 (experimental) (GCC) Note, you need to rename homework-2.f to homework-2.f90, or explicitly tell gfortran that homework-2.f is free-form code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug fortran/42545] New: TBP: Wrongly reject inherite TBP with types with private components
Reported by Reinhold Bader. The error occurs for inherited type-bound procedures where the extending type has PRIVATE for the components and the TBP procedure is accessed using the syntax type % extended type % TBP The error message is as follows: mr_shorter.f90:23.14: call obj%tt%set() 1 Error: All components of 'ttt' are PRIVATE in structure constructor at (1) The error is wrong for two reasons: a) There is no structure constructure visible at all b) This TBP is public as there is no PRIVATE statement below the CONTAINS in the type declaration. See 4.5.4 Type-bound procedures and esp. last two normative paragraphs of this section. And see 4.5.6.1 Inheritance (all refs are F2003): An extended type has a scalar, nonpointer, nonallocatable, parent component with the type and type parameters of the parent type. The name of this component is the parent type name. It has the accessibility of the parent type. ! - module mo implicit none type :: tt private integer :: i = 1 contains procedure :: set end type type, extends(tt) :: ttt private ! real :: x = 2.0 end type contains subroutine set(this) class(tt) :: this this%i = -1 end subroutine end module program pr use mo implicit none type(ttt) :: obj call obj%tt%set() end program ! --- Variants to check: type tt ... contains PRIVATE ! (and optionally set explicitly marked as public) -- and/or -- type, extends(tt) :: t ... contains PRIVATE -- Summary: TBP: Wrongly reject inherite TBP with types with private components Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug bootstrap/35938] Fixincludes failure with 'make check'
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-12-29 18:39 --- Fixed. Now all fixincludes tests pass on x86_64-apple-darwin10. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35938
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #19 from nospamname at web dot de 2009-12-29 18:44 --- The Problem is fixed in GCC4.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #7 from simon at pushface dot org 2009-12-29 18:48 --- I think the immediate cause is that the alignment for generated tagged type support objects (see eg exp_disp.adb:4007) is derived from that of System.Storage_Elements.Integer_Address (defined as mod Memory_Size) which should be 8 and is coming out as 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug c/42522] [m68k] Wrong code generated with -O2/-O3
--- Comment #8 from nospamname at web dot de 2009-12-29 18:52 ---
I have now find out with cflag -m68000 work with -O3.
But it work not with -m68020 or -m68040 or -m68060
Here is a standalone testcode and output with -S
-
struct test{
long dummy;
unsigned long buf;
};
struct unaligned_32 { unsigned long l; } __attribute__((packed));
static int flv_probe(struct test *p)
{
const unsigned char *d;
d = p-buf;
if (d[0] == 'F' d[1] == 'L' d[2] == 'V' d[3] 5 d[5]==0
(((const struct unaligned_32 *) (d+5))-l)8) {
return 100;
}
return 0;
}
int main(int argc, char **argv)
{
printf(%ld\n,flv_probe(argc));
}
--
Mit dem 4.5.0 vom 24.12 bekomme ich mit -O3 den Outpout .Code geht nicht.
(CFLAGS -m68060 -S -O3)
#NO_APP
.text
LC0:
.ascii %ld\12\0
.even
.globl _main
_main:
link.w a5,#0
jsr ___main
clr.l 12(a5)
move.l #LC0,8(a5)
unlk a5
jra _printf
--
(CFLAGS -m68060 -S -O1)
#NO_APP
.text
LC0:
.ascii %ld\12\0
.even
.globl _main
_main:
link.w a5,#0
jsr ___main
move.l 8(a5),a0
move.l 4(a0),a0
cmp.b #70,(a0)
jne L3
cmp.b #76,1(a0)
jne L4
cmp.b #86,2(a0)
jne L5
cmp.b #4,3(a0)
jhi L6
tst.b 5(a0)
jne L7
move.l 5(a0),d0
moveq #8,d1
cmp.l d0,d1
jcs L8
clr.l d0
jra L2
L3:
clr.l d0
jra L2
L4:
clr.l d0
jra L2
L5:
clr.l d0
jra L2
L6:
clr.l d0
jra L2
L7:
clr.l d0
jra L2
L8:
moveq #100,d0
L2:
move.l d0,-(sp)
pea LC0
jsr _printf
addq.l #8,sp
unlk a5
rts
#NO_APP
.text
LC0:
.ascii %ld\12\0
.even
.globl _main
_main:
link.w a5,#0
move.l a2,-(sp)
move.l 8(a5),a2
jsr ___main
move.l 4(a2),a0
cmp.b #70,(a0)
jeq L10
L7:
moveq #0,d0
move.l d0,12(a5)
move.l #LC0,8(a5)
move.l -4(a5),a2
unlk a5
jra _printf
L10:
cmp.b #76,1(a0)
jne L7
cmp.b #86,2(a0)
jne L7
cmp.b #4,3(a0)
jhi L7
tst.b 5(a0)
jne L7
moveq #0,d1
move.b 6(a0),d1
swap d1
clr.w d1
moveq #0,d0
move.b 7(a0),d0
lsl.l #8,d0
or.l d1,d0
or.b 8(a0),d0
moveq #8,d1
cmp.l d0,d1
jcc L7
moveq #100,d0
move.l d0,12(a5)
move.l #LC0,8(a5)
move.l -4(a5),a2
unlk a5
jra _printf
(CFLAGS -m68000 -S -O3)
#NO_APP
.text
LC0:
.ascii %ld\12\0
.even
.globl _main
_main:
link.w a5,#0
move.l a2,-(sp)
move.l 8(a5),a2
jsr ___main
move.l 4(a2),a0
cmp.b #70,(a0)
jeq L10
L7:
moveq #0,d0
move.l d0,12(a5)
move.l #LC0,8(a5)
move.l -4(a5),a2
unlk a5
jra _printf
L10:
cmp.b #76,1(a0)
jne L7
cmp.b #86,2(a0)
jne L7
cmp.b #4,3(a0)
jhi L7
tst.b 5(a0)
jne L7
moveq #0,d1
move.b 6(a0),d1
swap d1
clr.w d1
moveq #0,d0
move.b 7(a0),d0
lsl.l #8,d0
or.l d1,d0
or.b 8(a0),d0
moveq #8,d1
cmp.l d0,d1
jcc L7
moveq #100,d0
move.l d0,12(a5)
move.l #LC0,8(a5)
move.l -4(a5),a2
unlk a5
jra _printf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug fortran/36192] ICE with wrong index types and bad parens
--- Comment #9 from kargl at gcc dot gnu dot org 2009-12-29 18:58 --- Some addition information from valgrind. Error: Different shape for array assignment at (1) on dimension 1 (0 and 2) ==13911== Invalid read of size 8 ==13911==at 0x1C108F8: __gmpz_get_si (in /usr/local/lib/libgmp.so.8) ==13911==by 0x4B426F: compare_actual_formal (interface.c:1704) ==13911==by 0x4B52D7: gfc_procedure_use (interface.c:2407) ==13911==by 0x4F89AF: resolve_call (resolve.c:3045) ==13911==by 0x4FBFD2: resolve_code (resolve.c:8067) ==13911==by 0x4FD7CB: gfc_resolve_blocks (resolve.c:7722) ==13911==by 0x4FBE59: resolve_code (resolve.c:7943) ==13911==by 0x4FD93F: resolve_codes (resolve.c:12293) ==13911==by 0x4F1954: gfc_resolve (resolve.c:12320) ==13911==by 0x4E7C27: gfc_parse_file (parse.c:4198) ==13911==by 0x51B8C7: gfc_be_parse_file (f95-lang.c:239) ==13911==by 0x7FB635: toplev_main (toplev.c:1049) ==13911== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==13911== homework-2.f90: At top level: homework-2.f90:8:0: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ==13911== ==13911== HEAP SUMMARY: ==13911== in use at exit: 712,926 bytes in 2,347 blocks ==13911== total heap usage: 4,585 allocs, 2,238 frees, 1,218,623 bytes allocated ==13911== ==13911== LEAK SUMMARY: ==13911==definitely lost: 520 bytes in 14 blocks ==13911==indirectly lost: 0 bytes in 0 blocks ==13911== possibly lost: 18,256 bytes in 67 blocks ==13911==still reachable: 694,150 bytes in 2,266 blocks ==13911== suppressed: 0 bytes in 0 blocks ==13911== Rerun with --leak-check=full to see details of leaked memory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug fortran/42546] New: ALLOCATED statement typo in the docs and for scalar variables
As reported by James Van Buskirk
at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3aad8fb30b5174f4
Part of the reported issue is PR 41872. Remaining issue is:
13.7.9 ALLOCATED (ARRAY) or ALLOCATED (SCALAR)
[...]
Arguments.
ARRAY shall be an allocatable array.
SCALAR shall be an allocatable scalar.
Namely:
* ALLOCATABLE(SCALAR=variable) is not supported
* No ARRAY=scalar variable is not rejected
* invoke.texi must be updated:
- @var{X} is wrong, it should be @var{ARRAY} and @var{SCALAR}
- Standard version needs to be updated
* * *
I was thinking of updating intrinsic.c's allocated by using two optional
arguments: ARRAY (ar) and SCALAR (scalar) - and then doing the checking in
check.c. However, as the check routine does not get the actual argument but
only gfc_actual_arglist-expr, one can not distinguish
ALLOCATABLE(scalar_var) ! Valid, first argument to check routine
and
ALLOCATABLE(array=scalar_var) ! Invalid, first argument to check routine
Otherwise, one could use this method and use
gfc_check_allocated (gfc_expr *array, gfc_expr *scalar)
with checks for
if (array == NULL scalar == NULL) // Missing argument
if (array != NULL scalar != NULL) // Too many arguments
if (scalar scalar-rank != 0) // Invalid: SCALAR + Array
However,
if (array array-rank == 0)
does not work as this is also the case for ALLOCATED(scalar_var), which could
only be distinguished usinggfc_actual_arglist-name !=
cf. above and intrinsic.c's do_check.
Additionally, one needs to update gfc_conv_allocated to support two arguments -
scalar and array (which can be also scalar w/o keyword=).
--
Summary: ALLOCATED statement typo in the docs and for scalar
variables
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546
[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables
--- Comment #1 from burnus at gcc dot gnu dot org 2009-12-29 19:05 ---
Created an attachment (id=19419)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19419action=view)
Incomplete draft patch (diff) + Test case (bottom, no diff format)
Draft patch.
- Misses modification to trans-intrinsic.c
- (ARRAY=scalar) diagnosis missing (needs an idea how to solve this, cf.
comment 0)
Contains:
- Test case (dg-error incomplete)
- Modifications to intrinsic.{c,h}, check.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546
[Bug fortran/42547] New: Issues in intrinsics.texi documentation
James reported some documentation issues in post 3 at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3aad8fb30b5174f4 For the first post (ALLOCATE issues), see PR 42546. -- Summary: Issues in intrinsics.texi documentation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42547
[Bug fortran/42547] Issues in intrinsics.texi documentation
--- Comment #1 from burnus at gcc dot gnu dot org 2009-12-29 19:12 --- For the .texi changes, see also http://gcc.gnu.org/ml/fortran/2009-12/msg00183.html (I have not checked whether this covers all) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42547
[Bug fortran/42546] ALLOCATED statement typo in the docs and for scalar variables
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-29 19:12 --- For the .texi changes, see also http://gcc.gnu.org/ml/fortran/2009-12/msg00183.html (I have not checked whether this covers all). Cf. also PR 42547. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-29 19:26 --- In fact it depends on the key function being declared which depends on the ABI really (ARM EABI has a slightly different key function than the rest of the abis). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
[Bug rtl-optimization/41064] [4.4 Regression]: build breakage for cris-elf building newlib, ICE in extract_insn, from r150726
--- Comment #6 from bonzini at gnu dot org 2009-12-29 19:29 --- Causes PR40414 on GCC 4.4.x, reopening to make the other PR depend on this. -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail||4.4.0 Known to work||4.5.0 Resolution|FIXED | Summary|[4.5 Regression]: build |[4.4 Regression]: build |breakage for cris-elf |breakage for cris-elf |building newlib, ICE in |building newlib, ICE in |extract_insn, from r150726 |extract_insn, from r150726 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41064
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2009-12-29 19:29 --- I then try to build GCC4.4.2[x86_64-apple-darwin10.2.0] using GCC4.4.2[i386-apple-darwin10.2.0], with the reported results. [...] I've been using --build=x86_64-apple-darwin10.2.0 to indicate that I want to build a 64-bit compiler, is that not the right method? --build=xxx means you're using a xxx compiler to build. Since you apparently don't have a x86_64 compiler at hand but only a i386, you cannot do that. You first need to build a i386 - x86-64 cross-compiler (--host=i386-apple-* --target=x86_64-apple-*) with the base i386 compiler and then use the resulting compiler to build a native x86-64 compiler (--build=x86_64-apple-*). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug fortran/42517] Bogus runtime error with -fopenmp -fcheck=recursion
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-29 19:30 --- Subject: Bug 42517 Author: janus Date: Tue Dec 29 19:29:54 2009 New Revision: 155506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155506 Log: gcc/fortran/ 2009-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/42517 * invoke.texi: Document the interference of -fcheck=recursion and -fopenmp. * trans-decl.c (gfc_generate_function_code): Disable -fcheck=recursion when used with -fopenmp. gcc/testsuite/ 2009-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/42517 * gfortran.dg/gomp/recursion1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/recursion1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
[Bug middle-end/37053] [4.3/4.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #21 from bonzini at gnu dot org 2009-12-29 19:30 --- Reopening since it is still broken on the other open branches. -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to work||4.5.0 Resolution|FIXED | Summary|[4.3/4.4/4.5 regression] ICE|[4.3/4.4 regression] ICE in |in |reload_cse_simplify_operands |reload_cse_simplify_operands|, at postreload.c:395 |, at postreload.c:395 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #20 from bonzini at gnu dot org 2009-12-29 19:30 --- Adding dependencies on the patches that fix the bug. -- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn||37053, 41064 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-29 19:30:43 date|| Bug 40414 depends on bug 41064, which changed state. Bug 41064 Summary: [4.4 Regression]: build breakage for cris-elf building newlib, ICE in extract_insn, from r150726 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41064 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | Bug 40414 depends on bug 37053, which changed state. Bug 37053 Summary: [4.3/4.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:395 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug other/42542] g++ -O3 produces incorrect results for less-than operator
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-29 19:41 --- With -Wall, icc 11.1 complains: pr42542.cc(10): remark #981: operands are evaluated in unspecified order return (a b) ? b : a; ^ detected during instantiation of _Tp std::accumulate(_InputIterator, _InputIterator, _Tp, _BinaryOperation) [with _InputIterator=unsigned int *, _Tp=unsigned int, _BinaryOperation=maximumunsigned int] at line 25 Add -fno-tree-vectorize generates the correct result. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-29 19:41:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug fortran/42548] New: I/O: libgfortran gets confused and stopps I/O
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/16f799318c80df77
If I run the test case, I have the problem that for
call writeit(11) ! write formatted STREAM
call writeit(6) ! write formatted to stdout
I do not get any output to STDOUT -- and a flush(6) does not help. And using
! call writeit(11) ! write formatted STREAM
print *, 'Hello 1'
call writeit(6) ! write formatted to stdout
flush(6)
print *, 'Hello 2'
flush(6)
I get only Hello 1 and the table, but no Hello 2. I have not tried to debug
this - the code might be wrong.
I have not checked for the other issues reported in the thread such as writing
NUL ('\0') characters instead of spaces ( ). The issue is allegedly related
to the handling of missing arguments, cf. also the quotes from Richard Maine et
al.
* * *
Independent of those issues, one could consider implementing at some point a
__gfortran_finalize()
function in libgfortran, which is called at the end of the program and when
STOP is encountered. (Possibly also for CALL EXIT().)
--
Summary: I/O: libgfortran gets confused and stopps I/O
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42548
[Bug other/42542] g++ -O -ftree-vectorize produces incorrect results for less-than operator
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-29 19:44 --- Add -ftree-vectorize will cause it to fail. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|g++ -O3 produces incorrect |g++ -O -ftree-vectorize |results for less-than |produces incorrect results |operator|for less-than operator http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug other/42542] g++ -O -ftree-vectorize produces incorrect results for less-than operator
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-29 19:45 --- It could be a target issue. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug other/42542] g++ -O -ftree-vectorize produces incorrect results for less-than operator
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-29 19:51 --- There are no unsigned integer vector compare insns on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug fortran/42548] I/O: libgfortran gets confused and stopps I/O
--- Comment #1 from kargl at gcc dot gnu dot org 2009-12-29 19:53 ---
(In reply to comment #0)
I have not checked for the other issues reported in the thread such as writing
NUL ('\0') characters instead of spaces ( ). The issue is allegedly related
to the handling of missing arguments, cf. also the quotes from Richard Maine
The NUL issue was fixed long ago. The problem is in 4.3.x. It does not
appear in 4.4.x or trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42548
