[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8
--- Comment #7 from thunderwolf66102 at yahoo dot com 2010-02-01 08:49 --- Under Gentoo, GCC x86_64-pc-linux-gnu-4.4.2 appears to also build a broken glibc 2.9. I have tried many times over the past several days to build and install gentoo's 2.9_p20081201-r3 to replace a previous 2.9_p20081201-r2. After installing the new glibc several binaries would break - among them being python, squid and init. Other binaries worked fine. The first luck I had was I created a fresh environment under a chroot, built glibc, and copied it over. Tried to build 2.9_p20081201-r3 and install again after this with the same problems. I looked at a couple of other computers that I have and noticed their default compilers were all set to 4.3.x. Switched to 4.3.4 on the problem system, built 2.9_p20081201-r3 and installed again with no issues. One of the files related to the segfaults appeared to be libm-2.9.so. Replacing this file with the backed up -r2 version restored python. I believe this has also happened once before though at that point I simply backed up the system, nuked, and reinstalled. Python was broken then as well. flags = -O2 -finline-functions -mtune=athlon64 -march=x86-64 -fomit-frame-pointer -mfpmath=sse,387 -pipe -msse3 -- thunderwolf66102 at yahoo dot com changed: What|Removed |Added CC||thunderwolf66102 at yahoo ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852
[Bug fortran/42309] [4.3/4.4/4.5 Regression] Problem with a pointer array passed to a subroutine
-- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|4.5.0 | Keywords||wrong-code Known to fail||4.4.2 4.5.0 4.3.4 Known to work||4.1.2 4.2.1 Summary|Problem with a pointer array|[4.3/4.4/4.5 Regression] |passed to a subroutine |Problem with a pointer array ||passed to a subroutine Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309
[Bug fortran/42900] gfortran.dg/stat_[12].f90 may fail on NFS filesystems
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-02-01 09:21 --- Subject: Re: gfortran.dg/stat_[12].f90 may fail on NFS filesystems --- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-29 22:35 --- I'd say add a comment to the testcase and WONTFIX. I don't think this is a good idea: this part of the testcase tests a condition that doesn't necessarily hold, and is outside the control of the testsuite. I'd rather remove that part of the test than have this confusing noise in many reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42900
[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled
--- Comment #6 from rguenther at suse dot de 2010-02-01 09:23 --- Subject: Re: [4.3/4.4/4.5 Regression] Argument unnecessarily spilled On Mon, 1 Feb 2010, matz at gcc dot gnu dot org wrote: --- Comment #4 from matz at gcc dot gnu dot org 2010-02-01 02:41 --- Well, actually it depends. The code generated by 3.4 might theoretically be slower, because it potentially uses a misaligned stack slot (incoming stack with -m32 only 4 byte aligned). With -mpreferred-stack-boundary=2 also newer compilers use the incoming stack slot instead of copying it around. When we determined we need a stack slot, the flow is like so: when the slot alignment (32bits) is not known to be enough for it's declared type (64 bits here), _and_ the preferred stack alignment (128 per default in new compilers) is larger than the known slot alignment, then allocate a new stack slot. allocate a new stack slot is what differs between old and new compilers. New compilers will simply, well, allocate a new slot :) Old compilers will only use ADDRESSOF (if the type itself can otherwise be placed into registers), a kind of deferred stack slot allocation to wait if the address really needs to be taken (in new compilers this is always the case, because we can rely on TREE_ADDRESSABLE). If it turns out to be necessary, then it will reuse the stack slot, possibly misaligned (and the latter could be regarded as bug). If the 3.4 compiler also would check for alignment in the new way (it only did so for STRICT_ALIGNMENT targets), it too wouldn't have used the incoming stack slot. This additional checking (not only for STRICT_ALIGNMENT targets) came in as fix for PR18916 (that was after ADDRESSOF was removed already, otherwise that fix would have affected that code too). So, I think, everything works as intended, as long as the alignment facts are as they are: * long long is 64 aligned * incoming stack is 32 aligned * preferred alignment is 128 (and that this matters seems fishy too) One might argue that this should only matter for STRICT_ALIGNMENT targets, and therefore that ppc (ref PR18916) is such target. But that was altivec code. And with such code (SSE) x86 also is sort of a STRICT_ALIGNMENT target. Hm, if we'd properly communicate that misalignment down to accesses it would for large structs or -Os still preferable to not do the extra spilling. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42919
[Bug middle-end/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-02-01 10:14 --- GCC 4.2.x is no longer supported. FreeBSD is on its own. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug c/42907] -fstrict-aliasing breaks valid code
--- Comment #29 from emn13+gcc at nerbonne dot org 2010-02-01 10:16 --- What's particularly unfortunate about this instance is the fact that gcc fails to warn you about the erroneous code, despite the obvious signs and despite -Wall. Line 15 is obviously potentially problematic, but it doesn't show up as such even when -Wall is used. This means that any improvement in the optimizer which causes it break similarly invalid code may be terribly hard to debug - the code violates the spec, but there's just no hint that it's wrong (and worse, it works fine when compiled with less optmization, such as for debugging). And additional factor here is that it's statically determinable that this code will violate aliasing rules; line 15 creates an alias, and the next usage of the variable is a write. I realize that perhaps such read/write dependency analysis isn't available at the time that warnings are normally output (I have no idea about gcc innards), but that means that gcc is being presented with code that raises a red flag (line 15), knowably violates the spec (line 22), and yet doesn't even issue a warning even when compiled with -Wall. That's bound to make a gcc-users life hard, particularly as there's a bunch of old c code lying around that's probably not entirely up-to-spec. So, the OP's code is clearly at fault, but that doesn't necessarily mean gcc couldn't do more to prevent this kind of error. -- emn13+gcc at nerbonne dot org changed: What|Removed |Added CC||emn13+gcc at nerbonne dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8
--- Comment #8 from mikpe at it dot uu dot se 2010-02-01 11:13 --- There are known aliasing bugs in older glibc releases that result in broken code when compiled with gcc-4.4. The fix is to update glibc or to patch it. See http://gcc.gnu.org/ml/gcc/2009-07/msg00057.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39852
[Bug middle-end/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #16 from steven at gcc dot gnu dot org 2010-02-01 11:32 --- On a not-completely-OT note: Can anyone explain what this WITHOUT_GPLV3 is about? I can't find any mentioning of it on freebsd.org... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled
--- Comment #7 from matz at gcc dot gnu dot org 2010-02-01 11:53 --- Or making STRICT_ALIGNMENT depend on the type or mode. So that e.g. !align(8) align(4) !STRICT_ALIGN(long long) would be acceptable, but !align(16) STRICT_ALIGN(m128d) would not. Or making it depend on the typesize, so that strictness would only come into play when the type is larger than 8 byte. Or something like that. I don't think propagating down (mis)alignment would help in the general case. Some instructions simply aren't possible with misaligned memory, and need large compensation code. In that case we also wouldn't want to use the incoming stack slot for -Os. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42919
[Bug c/42907] -fstrict-aliasing breaks valid code
--- Comment #30 from matz at gcc dot gnu dot org 2010-02-01 12:24 --- See comment #3 for how (newer) GCC does warn at line 15. Not with the default options, though, but this has good reasons (too many false positives). You are right that we should be able to improve our diagnostics in this case, as, as you say, line 15 and 22 together create a definitely fishy situation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
[Bug c/42907] -fstrict-aliasing breaks valid code
--- Comment #31 from fejj at novell dot com 2010-02-01 13:08 ---
Michael:
I know that tail-value = anything is clearly going to evil things (if done
before assigning one of the nodes to tail) because only the first sizeof(void*)
bytes are valid memory addresses. However, if you read the code I wrote -
OBVIOUSLY it only ever assigns to those addresses. Maybe it's not obvious to
gcc (fair enough), but it should be obvious human programmers (or at least be
able to figure it out).
Pretend, instead, that I had:
typedef struct _Node {
struct _Node *next;
} Node;
Now it should be even more obvious that it should work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
[Bug c/42907] -fstrict-aliasing breaks valid code
--- Comment #32 from emn13+gcc at nerbonne dot org 2010-02-01 13:24 --- I realize that you *can* enable a specific warning that might solve this; but that's a pretty unsatisfactory state of affairs. The point is that if you've old (or external) C code *anywhere* in your app which breaks due to this behavior, there's no hint of what's wrong anywhere; enabling all warnings doesn't actually enable the warning you need, and you're stuck. The problematic bit (to my untrained ears anyhow) isn't that the code breaks, it's that it breaks without warning and didn't previously (despite strict aliasing) and doesn't necessarily break in other compilers (just tried in msvc 10.0, for instance) - so the notion that the diagnostics could be improved should (in principle, anyhow) cover it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
[Bug libgomp/29986] testsuite failures
--- Comment #10 from ro at gcc dot gnu dot org 2010-02-01 13:35 --- Subject: Bug 29986 Author: ro Date: Mon Feb 1 13:35:10 2010 New Revision: 156427 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156427 Log: PR libgomp/29986 * doc/install.texi (Specific): Add sparc-sun-solaris2.10 entry. Document fix for TLS bug. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug libgomp/29986] testsuite failures
--- Comment #11 from ro at gcc dot gnu dot org 2010-02-01 13:36 --- Fixed for 4.5.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug fortran/42922] New: Wrongly rejected derived types with default initializers in PURE procedures 2
This is a problem very similar to this one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008 gfortran rejects the attached code because: gfortran -c err.f90 err.f90:6.20: integer :: i = 0 1 Error: Initialization of variable at (1) is not allowed in a PURE procedure However, I think that the program is fine. module mod_xyz implicit none contains pure subroutine psub() type ilist integer :: i = 0 end type ilist end subroutine psub end module mod_xyz -- Summary: Wrongly rejected derived types with default initializers in PURE procedures 2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrestelli at gmail dot com GCC build triplet: GNU Fortran (GCC) 4.5.0 20100125 (experimental) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42922
[Bug middle-end/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #17 from kargl at gcc dot gnu dot org 2010-02-01 15:07 --- (In reply to comment #16) On a not-completely-OT note: Can anyone explain what this WITHOUT_GPLV3 is about? I can't find any mentioning of it on freebsd.org... It hasn't been implemented, yet. I don't want to start a pointless license discuss, but briefly, FreeBSD developers have decided that gplv3 code will not be allowed in the repository until some mechanism is in place to completely isolate the gplv3 code from all other code. The intent, I believe, is to allow companies that use FreeBSD as a base for their products to eliminate gplv3 to avoid the newer restrictions that gplv3 places on them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug target/42671] Thumb2 generate more instructions than Thumb1 to load GOT address
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-02-01 15:34 --- Fixed in trunk with http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01403.html -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42671
[Bug target/42671] Thumb2 generate more instructions than Thumb1 to load GOT address
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42671
[Bug fortran/41507] Documentation misleading on MAXLOC/MINLOC array type requirement
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-01 15:41 --- PING - Are you still working on this for 4.5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41507
[Bug c/42923] New: ice: verify_stmts failed
reg...@john-home:~/volatile/bugs/tmp264$ current-gcc -c -O2 small.c
small.c: In function node_get_length:
small.c:33:1: error: type mismatch in binary expression
int
int
size_t
add_acc.0_12 = add_acc.0_4 + D.1984_13;
small.c:33:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
reg...@john-home:~/volatile/bugs/tmp264$ cat small.c
typedef unsigned size_t;
size_t strlen(const char *s);
typedef struct _Record
{
char *name;
} Record;
typedef struct _Node
{
char type;
union
{
struct
{
Record *record;
struct _Node *child;
}
function;
}
data;
} Node;
int node_get_length (Node * node)
{
switch (node-type)
{
case 'f':
return strlen (node-data.function.record-name) + 1 +
node_get_length (node-data.function.child) + 1;
}
return 0;
}
reg...@john-home:~/volatile/bugs/tmp264$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r156428-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r156428-install --program-prefix=r156428-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100201 (experimental) (GCC)
--
Summary: ice: verify_stmts failed
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42923
[Bug libstdc++/42408] Missing templatized seed()
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-01 16:20 --- Let's minimally fix this for 4.5.0, we have a (still confidential) draft of the de-conceptualized specifications. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42408
[Bug libstdc++/42408] Missing templatized seed()
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-01 16:20:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42408
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #26 from chrbr at gcc dot gnu dot org 2010-02-01 16:30 --- I'm afraid the unaligned access sigbug regression is another latent bug just exhibited by the fix for the original PR :-( what happens is the the GOT loading sequence is broken by a constant pool: we end up to emit: mov.l .L542,r12(X) bra .L516 nop .L542: .align 2 .long _GLOBAL_OFFSET_TABLE_ ... .L516: mova.L545,r0 (Y) ! add r0,r12 .L545: .long _GLOBAL_OFFSET_TABLE_ The reason for that is that the second mova instruction is unluckily now out of range by 2 bytes. (which could happen with any other situation, even without this patch). IMHO We should forbid the duplication of a _GLOBAL_OFFSET_TABLE_ loading constant while in a UNSPEC_MOVA sequence. We should probably reduce si_limit in find_barrier when a (set (reg:SI 0 r0) (unspec:SI [ (const:SI (unspec:SI [ (symbol_ref (*_GLOBAL_OFFSET_TABLE_)) is met and next is (set (reg:SI 12 r12) (const:SI (unspec:SI [ (symbol_ref (*_GLOBAL_OFFSET_TABLE_) in PIC. I experimenting with a couple of different solutions in this direction. this PR was a really interesting bugs finder ! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug fortran/41507] Documentation misleading on MAXLOC/MINLOC array type requirement
--- Comment #5 from domob at gcc dot gnu dot org 2010-02-01 16:30 --- Yes, in theory... But now I have holidays (since in some sense this evening) I'll get on hopefully soon so it will be well in 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41507
[Bug target/42924] New: pex-unix.c:589:1: internal compiler error: output_operand
if [ x-fPIC != x ]; then \ /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc / -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0 /hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/lib/ -i system /opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/ gcc/gcc-4.5.0/hppa64-hp-hpux11.11/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict -prototypes -pedantic -fPIC ../../gcc/libiberty/pex-unix.c -o pic/pex-unix.o; \ else true; fi ../../gcc/libiberty/pex-unix.c:589:1: internal compiler error: output_operand: i nvalid expression as operand -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa64-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.5.0 --build=hppa64-hp-hpux11.11 --enable-threads=posix --disable-nls --with-gmp=/opt/gnu64/gcc/gcc-4.5.0 --with-libelf=/opt/gnu64 -enable-languages=c,c++,objc,obj-c++,fortran Thread model: posix gcc version 4.5.0 20100201 (experimental) [trunk revision 156423] (GCC) -- Summary: pex-unix.c:589:1: internal compiler error: output_operand Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug fortran/42922] Wrongly rejected derived types with default initializers in PURE procedures 2
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-01 16:37 ---
Thanks for the report! The bug is no regression and indeed the analogue to PR
42008 works also here:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 156428)
+++ gcc/fortran/decl.c (working copy)
@@ -1809,7 +1815,8 @@ variable_decl (int elem)
m = MATCH_ERROR;
}
- if (current_attr.flavor != FL_PARAMETER gfc_pure (NULL))
+ if (current_attr.flavor != FL_PARAMETER gfc_pure (NULL)
+ gfc_state_stack-state != COMP_DERIVED)
{
gfc_error (Initialization of variable at %C is not allowed in
a PURE procedure);
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2010-02-01 16:37:46
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42922
[Bug libstdc++/42925] New: Not possible to compare unique_ptr with 0
Compiling the attached C++0x program fails on 4.5 but is successful in 4.4. I think the root cause is the missing nullptr support but that doesn't make it any more useful for 4.5. -- Summary: Not possible to compare unique_ptr with 0 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at magfr dot user dot lysator dot liu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2010-02-01 16:47 --- Created an attachment (id=19774) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19774action=view) Test case demonstrating the problem. compile with g++ -std=c++0x -c test.cpp to demonstrate the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug c++/42926] New: g++: Internal error
HI, I have tried to build Webkit on a BeagleBoard and I have a g++ internal error. I am running Ubuntu Karmic 9.10 and I am taking the source from the svn repo. To build it I am using the command $./WebKitTools/Scripts/build-webkit --qt --debug Here are some other informations: I attached the last commands of the build log and the g++ internal error. I am sorry I can be more prcise in this bug report as I did not identie the error. fabro...@testfarm-beagle2:/media/partition/fabroy01/WebKit$ svn info Path: . URL: http://svn.webkit.org/repository/webkit/trunk Repository Root: http://svn.webkit.org/repository/webkit Repository UUID: 268f45cc-cd09-0410-ab3c-d52691b4dbfc Revision: 54131 Node Kind: directory Schedule: normal Last Changed Author: oli...@apple.com Last Changed Rev: 54131 Last Changed Date: 2010-02-01 10:05:48 + (Mon, 01 Feb 2010) -- Summary: g++: Internal error Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fabien dot royer at arm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42926
[Bug c++/42926] g++: Internal error
--- Comment #1 from fabien dot royer at arm dot com 2010-02-01 17:01 --- Created an attachment (id=19775) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19775action=view) this is part of the log of the build command. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42926
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-02-01 17:01 --- I think the code is invalid. In 4.4 the expression (ptr != 0) converted ptr to an unspecified-bool-type and compared that to 0. In 4.5 the impicit conversion has been removed, and you need to say static_castbool(ptr) or (bool)ptr instead. This is required by the current working draft -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug c++/42926] g++: Internal error
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-01 17:02 --- You ran out of memory. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42926
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-01 17:03 --- I suppose it worked at some point. Please attach preprocessed source. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|pex-unix.c:589:1: internal |[4.5 Regression] pex- |compiler error: |unix.c:589:1: internal |output_operand |compiler error: ||output_operand Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug c/42907] -fstrict-aliasing breaks valid code
--- Comment #33 from rguenth at gcc dot gnu dot org 2010-02-01 17:04 --- (In reply to comment #32) I realize that you *can* enable a specific warning that might solve this; but that's a pretty unsatisfactory state of affairs. The point is that if you've old (or external) C code *anywhere* in your app which breaks due to this behavior, there's no hint of what's wrong anywhere; enabling all warnings doesn't actually enable the warning you need, and you're stuck. The problematic bit (to my untrained ears anyhow) isn't that the code breaks, it's that it breaks without warning and didn't previously (despite strict aliasing) and doesn't necessarily break in other compilers (just tried in msvc 10.0, for instance) - so the notion that the diagnostics could be improved should (in principle, anyhow) cover it. Patches welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
[Bug c/42923] ice: verify_stmts failed
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-01 17:05 --- Related to or dup of PR42749. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42749 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42923
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #3 from gcc at magfr dot user dot lysator dot liu dot se 2010-02-01 17:19 --- I think the code is valid. The unique_ptr(nullptr_t) constructor should take the 0 and build an empty unique_ptr object that is compared with ptr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-02-01 17:22 --- there is this comparison function: templateclass T1, class D1, class T2, class D2 bool operator!=(const unique_ptrT1, D1 x, const unique_ptrT2, D2 y); What should T2 and D2 be deduced as, in the conversion from nullptr_t to unique_ptrT2, D2 ? Or to put it another way: unique_ptr is not a type, it's a template. So what type do you mean when you say build an empty unique_ptr object ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-01 17:25 --- Jon, is there a thread on the reflector about related issues? I spotted something but couldn't exactly remember... Anyway, just want to add that I do not see why the C++ front-end, for some reason, decides to displays candidate comparison operators overloaded for error_code and error_condition, I don't see how this could be right. Jason, any idea? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-01 17:25:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-02-01 17:36 --- (In reply to comment #5) Jon, is there a thread on the reflector about related issues? I spotted something but couldn't exactly remember... LWG 834 is about comparing unique_ptrT,D::pointer to nullptr_t LWG 1307 is about missing != comparisons for other types. Neither is related to this issue, and I don't know of any thread on this topic. The code would work if there was: templateclass T1, class D1 bool operator!=(const unique_ptrT1, D1 x, const nullptr_t); (along with a version with the arguments reversed, and similarly for operator==) But there is no such function in the WP. Nor is there a member unique_ptr::operator!=(nullptr_t) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-01 17:38 --- Ok, agreed... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-01 17:39 --- Let's keep this open for one sec, in case Jason believes that list of candidates could be actually made less confusing to the user. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-02-01 18:08 --- Subject: Re: [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand I suppose it worked at some point. Please attach preprocessed source. Yes, it worked a few days ago. Attached. Dave --- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-02-01 18:08 --- Created an attachment (id=19776) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19776action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #9 from jason at gcc dot gnu dot org 2010-02-01 19:31 --- It does seem like it would be helpful to include templates in the list of all candidates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug c/42927] New: type mismatch in shift expression produces ice with -O3
I just tried to compile the package scsires-0.7-4.7 with the GNU C compiler version 4.5 snapshot 20100128 and the compiler said scsires.c: In function 'scsires_issue_reservation': scsires.c:911:1: error: type mismatch in shift expression vector unsigned int vector unnamed type int vect_var_.289_442 = vect_perm_odd.250_390 16; then scsires.c:911:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required. It compiles fine with -O2. -- Summary: type mismatch in shift expression produces ice with -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42927
[Bug c/42927] type mismatch in shift expression produces ice with -O3
--- Comment #1 from dcb314 at hotmail dot com 2010-02-01 19:39 --- Created an attachment (id=19777) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19777action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42927
[Bug tree-optimization/42927] [4.5 Regression] type mismatch in shift expression produces ice with -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization GCC host triplet|x86_64-suse-linux | GCC target triplet||x86_64-suse-linux Keywords||ice-on-valid-code Summary|type mismatch in shift |[4.5 Regression] type |expression produces ice with|mismatch in shift expression |-O3 |produces ice with -O3 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42927
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-01 19:40 --- I see. In principle I think the user would like to see only operator!=(int, int) built-in and indeed: templatetypename _Tp, typename _Tp_Deleter, typename _Up, typename _Up_Deleter bool operator!=(const unique_ptr_Tp, _Tp_Deleter, const unique_ptr_Up, _Up_Deleter); but I understand those overloads for std::error_condition / std::error_code combinations cannot be avoided... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug libstdc++/42408] Missing templatized seed()
--- Comment #3 from paolo at gcc dot gnu dot org 2010-02-01 19:45 --- Subject: Bug 42408 Author: paolo Date: Mon Feb 1 19:45:23 2010 New Revision: 156430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156430 Log: 2010-02-01 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/42408 * include/bits/random.h (linear_congruential_engine:: linear_congruential_engine(seed_seq), linear_congruential_engine::seed(seed_seq), mersenne_twister::mersenne_twister(seed_seq), mersenne_twister::seed(seed_seq), subtract_with_carry_engine::subtract_with_carry_engine(seed_seq), subtract_with_carry_engine::seed(seed_seq), discard_block_engine::discard_block_engine(seed_seq), discard_block_engine::seed(seed_seq), independent_bits_engine::independent_bits_engine(seed_seq), independent_bits_engine::seed(seed_seq), shuffle_order_engine::shuffle_order_engine(seed_seq), shuffle_order_engine::seed(seed_seq)): Templatize. * include/bits/random.tcc: Adjust. * testsuite/26_numerics/random/subtract_with_carry_engine/cons/ seed_seq.cc: New. * testsuite/26_numerics/random/mersenne_twister_engine/cons/ seed_seq.cc: Likewise. * testsuite/26_numerics/random/linear_congruential_engine/ cons/seed_seq.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/cons/seed_seq.cc trunk/libstdc++-v3/testsuite/26_numerics/random/mersenne_twister_engine/cons/seed_seq.cc trunk/libstdc++-v3/testsuite/26_numerics/random/subtract_with_carry_engine/cons/seed_seq.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42408
[Bug libstdc++/42408] Missing templatized seed()
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-01 19:48 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42408
[Bug target/41399] [4.5 Regression] Scheduler gives huge dependence graph compiling fortran/intrinsic.c on ARM
--- Comment #23 from vmakarov at gcc dot gnu dot org 2010-02-01 19:52 --- Subject: Bug 41399 Author: vmakarov Date: Mon Feb 1 19:52:42 2010 New Revision: 156431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156431 Log: 2010-02-01 Vladimir Makarov vmaka...@redhat.com PR target/41399 * sched-deps.c (sched_analyze_insn): Ignore fixed registers for implicitly set registers. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
[Bug lto/42928] New: crash when compiling scummvm on Ubuntu 9.10/amd64 with -flto and -fuse-linker-plugin
with trunk revision 156392 1. get and unpack the scummvm src: http://helllabs.org/scummvm/scummvm-20100201.tar.bz2 2. ./configure --enable-all-engines 3. edit config.mk so that CXXFLAGS reads as -O2 -Wall -Wextra -g -ansi -W -Wno-unused-parameter -Wno-empty-body -pedantic -flto 4. edit config.mk so that LDFLAGS reads as -lm -flto -fuse-linker-plugin -fwhole-program 5. make result: crash during final link: ~/src/scummvm$ /home/matt/bin/g++ -lm -flto -fwhole-program -fuse-linker-plugin backends/platform/sdl/events.o backends/platform/sdl/graphics.o backends/platform/sdl/hardwarekeys.o backends/platform/sdl/main.o backends/platform/sdl/sdl.o base/libbase.a engines/scumm/libscumm.a engines/agi/libagi.a engines/agos/libagos.a engines/cine/libcine.a engines/cruise/libcruise.a engines/draci/libdraci.a engines/drascula/libdrascula.a engines/gob/libgob.a engines/groovie/libgroovie.a engines/kyra/libkyra.a engines/lure/liblure.a engines/m4/libm4.a engines/made/libmade.a engines/mohawk/libmohawk.a engines/parallaction/libparallaction.a engines/queen/libqueen.a engines/saga/libsaga.a engines/sci/libsci.a engines/sky/libsky.a engines/sword1/libsword1.a engines/sword2/libsword2.a engines/teenagent/libteenagent.a engines/tinsel/libtinsel.a engines/touche/libtouche.a engines/tucker/libtucker.a engines/libengines.a gui/libgui.a graphics/libgraphics.a sound/libsound.a backends/libbackends.a common/libcommon.a sound/softsynth/mt32/libmt32.a -lasound -lz -L/usr/lib -lSDL -o scummvm lto1: internal compiler error: in get_resolution, at lto-streamer-in.c:1523 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/matt/bin/g++ returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status -- Summary: crash when compiling scummvm on Ubuntu 9.10/amd64 with - flto and -fuse-linker-plugin Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matt at use dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42928
[Bug c++/42929] New: ICE when compiling PPL
The error occurs when compiling PPL with GCC 4.5.0 revision 156383 -- Summary: ICE when compiling PPL Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-cross-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42929
[Bug c++/42929] ICE when compiling PPL
--- Comment #1 from denis dot onischenko at gmail dot com 2010-02-01 20:28 --- Created an attachment (id=19778) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19778action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42929
[Bug c++/42929] ICE when compiling PPL
--- Comment #2 from denis dot onischenko at gmail dot com 2010-02-01 20:28 --- Created an attachment (id=19779) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19779action=view) console output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42929
[Bug c++/42929] [4.5 Regression] ICE when compiling PPL
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-01 20:30 --- I think this is a dup of bug 42915. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42915 Keywords||ice-on-valid-code Summary|ICE when compiling PPL |[4.5 Regression] ICE when ||compiling PPL Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42929
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-02-01 21:00 --- Subject: Re: New: pex-unix.c:589:1: internal compiler error: output_operand Breakpoint 3, output_addr_const (file=0x83fffdfd0020, x=0x83fffdc75228) at ../../gcc/gcc/final.c:3521 3521 switch (GET_CODE (x)) (gdb) p debug_rtx (x) (unspec:DI [ (symbol_ref:DI (environ) [flags 0x240] var_decl 83fffddcedc0 environ) ] 2) $6 = void (gdb) bt #0 output_addr_const (file=0x83fffdfd0020, x=0x83fffdc75228) at ../../gcc/gcc/final.c:3521 #1 0x410910d0 in dw2_assemble_integer (size=-2147482625, x=0x83fffdc75228) at ../../gcc/gcc/dwarf2asm.c:59 #2 0x41091a90 in dw2_asm_output_addr_rtx (size=-2147482625, addr=Cannot access memory at address 0x1a ) at ../../gcc/gcc/dwarf2asm.c:253 #3 0x410e6f68 in output_loc_operands (loc=0x83fffdfd0020) at ../../gcc/gcc/dwarf2out.c:5034 ... See: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01471.html Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug middle-end/42930] New: crash when compiling scummvm on Ubuntu 9.10/amd64 with
with trunk revision 156392 1. get and unpack the scummvm src: http://helllabs.org/scummvm/scummvm-20100201.tar.bz2 2. ./configure --enable-all-engines 3. edit config.mk so that CXXFLAGS := -O2 -funswitch-loops -ftree-loop-linear -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-vectorize -fvariable-expansion-in-unroller -fpredictive-commoning -fweb -ffast-math -fsee -fgcse-after-reload -fgcse-sm -g -ansi -W -Wno-unused-parameter -Wno-empty-body -pedantic 4. edit config.mk so that LDFLAGS reads as -lm -flto -fuse-linker-plugin -fwhole-program 5. make result: engines/cine/gfx.cpp: In member function virtual void Cine::OSRenderer::transformPalette(int, int, int, int, int): engines/cine/gfx.cpp:1243:6: internal compiler error: in scan_tree_for_params, at graphite-sese-to-poly.c:815 -- Summary: crash when compiling scummvm on Ubuntu 9.10/amd64 with Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matt at use dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930
[Bug tree-optimization/42931] New: -ftree-loop-linear - valgrind warns about using uninitialized variable
Command line:
valgrind --trace-children=yes gcc -O1 -ftree-loop-linear -c testcase.c
Tested revisions:
trunk r156367 - fail
trunk r155363 - fail
trunk r153685 - fail
4.4 r156256 - fail
4.4 r155966 - fail
4.4 r155463 - fail
4.4 r155365 - fail
4.4 r154975 - fail
4.4 r153668 - OK
4.4 r149995 - OK
4.4.2 (gentoo) - OK
4.3.4 (gentoo) - fail
Output:
$ valgrind --track-origins=yes
/mnt/svn/gcc-trunk/binary-156367-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
-O1 -ftree-loop-linear jquant2-noempty.i
...
Analyzing compilation unit
Performing interprocedural optimizations
visibility *free_lang_data early_local_cleanups whole-program inline
static-var pure-constAssembling functions:
prescan_quantize update_box==15347== Conditional jump or move depends on
uninitialised value(s)
==15347==at 0x61E845: mul_double_with_sign (fold-const.c:422)
==15347==by 0xBE645C: double_int_mul (double-int.c:179)
==15347==by 0xC63273: linear_transform_loops (tree-loop-linear.c:249)
==15347==by 0x8955A6: tree_linear_transform (tree-ssa-loop.c:261)
==15347==by 0x72261A: execute_one_pass (passes.c:1561)
==15347==by 0x7228A4: execute_pass_list (passes.c:1616)
==15347==by 0x7228B6: execute_pass_list (passes.c:1617)
==15347==by 0x7228B6: execute_pass_list (passes.c:1617)
==15347==by 0x818364: tree_rest_of_compilation (tree-optimize.c:413)
==15347==by 0x9997D0: cgraph_expand_function (cgraphunit.c:1543)
==15347==by 0x99C1F4: cgraph_optimize (cgraphunit.c:1622)
==15347==by 0x99C754: cgraph_finalize_compilation_unit (cgraphunit.c:1093)
==15347== Uninitialised value was created by a stack allocation
==15347==at 0xC62B71: linear_transform_loops (tree-loop-linear.c:317)
==15347==
==15347== Conditional jump or move depends on uninitialised value(s)
==15347==at 0x61E854: mul_double_with_sign (fold-const.c:427)
==15347==by 0xBE645C: double_int_mul (double-int.c:179)
==15347==by 0xC63273: linear_transform_loops (tree-loop-linear.c:249)
==15347==by 0x8955A6: tree_linear_transform (tree-ssa-loop.c:261)
==15347==by 0x72261A: execute_one_pass (passes.c:1561)
==15347==by 0x7228A4: execute_pass_list (passes.c:1616)
==15347==by 0x7228B6: execute_pass_list (passes.c:1617)
==15347==by 0x7228B6: execute_pass_list (passes.c:1617)
==15347==by 0x818364: tree_rest_of_compilation (tree-optimize.c:413)
==15347==by 0x9997D0: cgraph_expand_function (cgraphunit.c:1543)
==15347==by 0x99C1F4: cgraph_optimize (cgraphunit.c:1622)
==15347==by 0x99C754: cgraph_finalize_compilation_unit (cgraphunit.c:1093)
==15347== Uninitialised value was created by a stack allocation
==15347==at 0xC62B71: linear_transform_loops (tree-loop-linear.c:317)
==15347==
fill_inverse_cmap {GC 5348k - 2791k} pass2_no_dither pass2_fs_dither
init_error_limit finish_pass1 finish_pass2 new_color_map_2_quant
start_pass_2_quant jinit_2pass_quantizer
--
Summary: -ftree-loop-linear - valgrind warns about using
uninitialized variable
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86(_64)-pc-linux-gnu
GCC target triplet: x86(_64)-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42931
[Bug tree-optimization/42931] -ftree-loop-linear - valgrind warns about using uninitialized variable
--- Comment #1 from zsojka at seznam dot cz 2010-02-01 21:27 --- Created an attachment (id=19780) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19780action=view) original, unreduced testcase (from jpeg sources) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42931
[Bug fortran/42922] Wrongly rejected derived types with default initializers in PURE procedures 2
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-01 21:38 --- Subject: Bug 42922 Author: burnus Date: Mon Feb 1 21:37:49 2010 New Revision: 156433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156433 Log: 2010-02-01 Tobias Burnus bur...@net-b.de PR fortran/42922 * decl.c (variable_decl): Allow default initializer in TYPE declarations in PURE functions. 2010-02-01 Tobias Burnus bur...@net-b.de PR fortran/42922 * gfortran.dg/pure_initializer_3.f90: News test. Added: trunk/gcc/testsuite/gfortran.dg/pure_initializer_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42922
[Bug fortran/42922] Wrongly rejected derived types with default initializers in PURE procedures 2
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-01 21:38 --- FIXED on the trunk (4.5). Thanks for the report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42922
[Bug libstdc++/42847] [4.5 Regression] failure while configuring libstdc++
--- Comment #5 from rainer at emrich-ebersheim dot de 2010-02-01 21:46 --- (In reply to comment #3) I haven't tried a whole lot of cross compiler building. There's no reference to cygwin anywhere in crossconfig.m4, so perhaps we need --with-newlib? Sorry guys, my fault. Indeed I missed --with-newlib. So, closing as invalid. Rainer -- rainer at emrich-ebersheim dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42847
[Bug target/42920] gcc does not produce necessary vec_lvrx instructions
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-02-01 21:54 --- if it ain't in Ubuntu repos anymore, I can't remember how to build these things. :) Well it works in 4.4.0 so closing as invalid as the support for these intrinsics were not added until 4.4 and they were fixed before submitting them to the upstream code. [apin...@dhcp-10-98-10-216 ~]$ ~/gcc-mainline/bin/gcc -V4.4.0 t.c -maltivec -mcpu=cell -O2 [apin...@dhcp-10-98-10-216 ~]$ ./a.out 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 11.00 12.00 13.00 14.00 15.00 [apin...@dhcp-10-98-10-216 ~]$ ~/gcc-mainline/bin/gcc -V4.4.0 t.c -maltivec -mcpu=cell -O3 [apin...@dhcp-10-98-10-216 ~]$ ./a.out 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 11.00 12.00 13.00 14.00 15.00 [apin...@dhcp-10-98-10-216 ~]$ ~/gcc-mainline/bin/gcc t.c -maltivec -mcpu=cell -O3 ^[[a[apin...@dhcp-10-98-10-216 ./a.out 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 11.00 12.00 13.00 14.00 15.00 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42920
[Bug bootstrap/42932] New: unknown endianness, Solaris 10 SPARC
% export PATH=/cairo/tmp/jblaine:/usr/sfw/bin:/usr/ccs/bin:/usr/bin:/bin:/sbin:/usr/sbin # # Note /cairo/tmp/jblaine is in PATH for GNU find per bug # 38715. Everything else in the PATH is standard Solaris 10 SPARC. # % uname -a SunOS cairo 5.10 Generic_13-08 sun4u sparc SUNW,Sun-Fire-280R % alias make=/usr/sfw/bin/gmake % which gcc /usr/sfw/bin/gcc % gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Copyright (C) 2004 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-4.4.3/configure --prefix=/cairo/tmp/4.4.3 --disable-shared ... finishes fine ... % make ... checking whether byte ordering is bigendian... unknown configure: error: unknown endianness presetting ac_cv_c_bigendian=no (or yes) will help gmake[1]: *** [configure-target-libiberty] Error 1 -- Summary: unknown endianness, Solaris 10 SPARC Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jblaine at mitre dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42932
[Bug target/41399] [4.5 Regression] Scheduler gives huge dependence graph compiling fortran/intrinsic.c on ARM
--- Comment #24 from steven at gcc dot gnu dot org 2010-02-01 22:13 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
[Bug fortran/42650] F90: DT function with in-line DT definition and RESULT is rejected
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-01 22:16 ---
The problem is somehow that for the second parsing using decl.c's
gfc_match_decl_type_spec one has in:
else if (ts-kind == -1)
{
int iface = gfc_state_stack-previous-state != COMP_INTERFACE
|| gfc_current_ns-has_import_set;
if (gfc_find_symbol (name, NULL, iface, sym))
{
gfc_error (Type name '%s' at %C is ambiguous, name);
return MATCH_ERROR;
}
the result sym == NULL with RESULT() but not without RESULT(); while
iface==1 and name == t for both cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42650
[Bug middle-end/42930] crash when compiling scummvm on Ubuntu 9.10/amd64 with -floop-block
--- Comment #1 from matt at use dot net 2010-02-01 22:24 --- I have narrowed it to the following commandline (-O1 -floop-block): ~/src/scummvm$ /home/matt/bin/g++ -Wp,-MMD,engines/cine/.deps/gfx.d,-MQ,engines/cine/gfx.o,-MP -Wall -O1 -floop-block -ansi -fcheck-new -DSCUMMVM_SVN_REVISION=\47802\ -DHAVE_CONFIG_H -DUNIX -DDATA_PATH=\/usr/local/share/scummvm\ -DPLUGIN_DIRECTORY=\/usr/local/lib/scummvm\ -DSDL_BACKEND -DENABLE_SCUMM=STATIC_PLUGIN -DENABLE_SCUMM_7_8 -DENABLE_HE -DENABLE_AGI=STATIC_PLUGIN -DENABLE_AGOS=STATIC_PLUGIN -DENABLE_AGOS2 -DENABLE_CINE=STATIC_PLUGIN -DENABLE_CRUISE=STATIC_PLUGIN -DENABLE_DRACI=STATIC_PLUGIN -DENABLE_DRASCULA=STATIC_PLUGIN -DENABLE_GOB=STATIC_PLUGIN -DENABLE_GROOVIE=STATIC_PLUGIN -DENABLE_GROOVIE2 -DENABLE_KYRA=STATIC_PLUGIN -DENABLE_LOL -DENABLE_LURE=STATIC_PLUGIN -DENABLE_M4=STATIC_PLUGIN -DENABLE_MADE=STATIC_PLUGIN -DENABLE_MOHAWK=STATIC_PLUGIN -DENABLE_PARALLACTION=STATIC_PLUGIN -DENABLE_QUEEN=STATIC_PLUGIN -DENABLE_SAGA=STATIC_PLUGIN -DENABLE_IHNM -DENABLE_SAGA2 -DENABLE_SCI=STATIC_PLUGIN -DENABLE_SCI32 -DENABLE_SKY=STATIC_PLUGIN -DENABLE_SWORD1=STATIC_PLUGIN -DENABLE_SWORD2=STATIC_PLUGIN -DENABLE_TEENAGENT=STATIC_PLUGIN -DENABLE_TINSEL=STATIC_PLUGIN -DENABLE_TOUCHE=STATIC_PLUGIN -DENABLE_TUCKER=STATIC_PLUGIN -I. -I. -I./engines -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c engines/cine/gfx.cpp -o engines/cine/gfx.o Pre-processed source is attached. -- matt at use dot net changed: What|Removed |Added Summary|crash when compiling scummvm|crash when compiling scummvm |on Ubuntu 9.10/amd64 with |on Ubuntu 9.10/amd64 with - ||floop-block http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930
[Bug middle-end/42930] crash when compiling scummvm on Ubuntu 9.10/amd64 with -floop-block
--- Comment #2 from matt at use dot net 2010-02-01 22:25 --- Created an attachment (id=19781) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19781action=view) pre-processed source file that causes the crash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930
[Bug fortran/42650] F90: DT function with in-line DT definition and RESULT is rejected
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-01 22:46 --- Patch: Index: gcc/fortran/parse.c === --- gcc/fortran/parse.c (Revision 156433) +++ gcc/fortran/parse.c @@ -111,7 +111,7 @@ decode_specification_statement (void) match (import, gfc_match_import, ST_IMPORT); match (use, gfc_match_use, ST_USE); - if (gfc_current_block ()-ts.type != BT_DERIVED) + if (gfc_current_block ()-result-ts.type != BT_DERIVED) goto end_of_block; match (NULL, gfc_match_st_function, ST_STATEMENT_FUNCTION); -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-08 05:47:58 |2010-02-01 22:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42650
[Bug ada/42554] Can't build gnatlink, gnatmake
--- Comment #5 from simon at pushface dot org 2010-02-01 22:53 --- I think this bug is caused by a much more fundamental problem: the -c switch to ranlib, which seems to be a Darwin special, appears to cause this problem (at any rate with Xcode = 3.2, ie darwin10. The top-level configure.ac includes the following *-*-darwin*) # ranlib from Darwin requires the -c flag to look at common symbols. extra_ranlibflags_for_target= -c ;; and the SVN log for ths says r60397 | geoffk | 2002-12-22 06:46:41 + (Sun, 22 Dec 2002) | 4 lines * configure.in (extra_ranlibflags_for_target): New variable. (*-*-darwin): Add -c to ranlib commands. * configure (tooldir): Handle extra_ranlibflags_for_target. The Darwin man page for ranlib says -c Include common symbols as definitions with respect to the ta- ble of contents. This is seldom the intended behavior for linking from a library, as it forces the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This option is included only because this was the original behavior of ran- lib. This option is not the default. Apple, in response to Jack Howarth re: radar 6320843 Darwin static archives traditionally do not have common symbols in there table of contents. The -c option forces common symbols into the table of contents and causes this problem. I have replaced the section of configure.ac above by this: *-*-darwin1[[0123456789]]*) # ranlib from Darwin 10 (Xcode 3.2) does not require the -c flag # to look at common symbols. ;; *-*-darwin*) # ranlib from older Darwins requires the -c flag to look at common # symbols. extra_ranlibflags_for_target= -c ;; and the build proceeds to completion -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug ada/42554] Can't build gnatlink, gnatmake
--- Comment #6 from simon at pushface dot org 2010-02-01 22:55 --- Created an attachment (id=19782) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19782action=view) Patch to configure.ac, configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug testsuite/42933] New: Test suite reports excess unexpected failures when using RUNTESTFLAGS to pass extra options
While investigating configuration-dependent behavior in GCC, I ran the test suite twice as shown below. In the first case, RUNTESTFLAGS passes no extra flags, and the summary shows 13 unexpected failures. In the second case I send a great many options and get 188 unexpected failures. I am willing to provide more details and to minimize the flags on the most recent release (rather than r152840), but first somebody should check whether this is ``reason: invalid.'' In particular, are there restrictions on what flags should be passed with RUNTESTFLAGS? -std=c++0x, for instance, jumps out at me as maybe off-limits. Thanks, Brady $ svn -r152840 co svn://gcc.gnu.org/svn/gcc/tags/gcc_4_4_2_release # (output snipped) $ mkdir 4_4_2_binary $ cd 4_4_2_binary $ ../gcc_4_4_2_release/configure # (output snipped) $ make # (output snipped) $ ./gcc/xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc_4_4_2_release/configure Thread model: posix gcc version 4.4.2 (GCC) $ make check RUNTESTFLAGS=--target_board=unix # (output snipped) $ make check RUNTESTFLAGS=--target_board=unix/-fno-peephole2/-fno-crossjumping/-fno-expensive-optimizations/-fno-split-wide-types/-falign-loops/-fno-defer-pop/-fno-forward-propagate/-std=c++0x/-fno-regmove/-m32/-fno-reorder-functions/-fno-ipa-cp/-fno-ipa-reference/-fno-tree-dce/-fno-cse-follow-jumps/-fno-merge-constants/-ftree-sra/-fno-tree-dominator-opts/-fno-tree-builtin-call-dce/-fno-tree-ccp/-fno-align-functions/-fno-tree-dse/-fno-optimize-register-move/-fno-guess-branch-probability/-ftree-pre/-fno-tree-sink/-ftree-vrp/-finline-small-functions/-fno-ipa-pure-const/-fno-if-conversion2/-fno-reorder-blocks/-fno-align-labels/-fno-optimize-sibling-calls/-fno-omit-frame-pointer/-fno-strict-aliasing/-fno-gcse/-fno-caller-saves/-fno-tree-copy-prop/-fno-rerun-cse-after-loop/-fno-align-jumps/-fno-tree-ch/-fno-tree-copyrename/-fno-schedule-insns2/-fno-thread-jumps/-fno-if-conversion/-O2/-fno-tree-ter/-fno-tree-fre/-fno-cprop-registers/-fno-delete-null-pointer-checks # (output snipped) -- Summary: Test suite reports excess unexpected failures when using RUNTESTFLAGS to pass extra options Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bgarvin at acm dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42933
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-02 01:04 --- Ok, I guess we can close this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
[Bug testsuite/42933] Test suite reports excess unexpected failures when using RUNTESTFLAGS to pass extra options
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-02 01:14 --- Well RUNTESTFLAGS is really only useful for options which change the ABI and have a multilib. Like -fPIC/-m64/-m32, etc. -std=c++0x changes the input language which is used so therefor changes the whole testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42933
[Bug testsuite/42933] Test suite reports excess unexpected failures when using RUNTESTFLAGS to pass extra options
--- Comment #2 from bgarvin at acm dot org 2010-02-02 01:30 --- (In reply to comment #1) Well RUNTESTFLAGS is really only useful for options which change the ABI and have a multilib. Like -fPIC/-m64/-m32, etc. -std=c++0x changes the input language which is used so therefor changes the whole testsuite. Consequently marking as invalid. I take it then that for exercising various configurations I should restrict myself to the torture tests? -- bgarvin at acm dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42933
[Bug testsuite/42933] Test suite reports excess unexpected failures when using RUNTESTFLAGS to pass extra options
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-02 01:36 --- torture For the torture test you can set the TORTURE OPTIONS separately and let the testsuite do the rest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42933
[Bug testsuite/42933] Test suite reports excess unexpected failures when using RUNTESTFLAGS to pass extra options
--- Comment #4 from bgarvin at acm dot org 2010-02-02 01:43 --- (In reply to comment #3) torture For the torture test you can set the TORTURE OPTIONS separately and let the testsuite do the rest. Yeah, that's what I meant. Thanks for the clarification and sorry about the invalid bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42933
[Bug ada/42554] Can't build gnatlink, gnatmake
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-02-02 01:55 --- Why not remove the duplicate linkage of s-secsta.o in gnatlink and gnatmake? There is no reason to link it in a second time since it is already in libgnat.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug fortran/42309] Problem with a pointer array passed to a subroutine
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-02 05:17 --- I am not at all happy with designating this bug a regression. This worked with 4.1 and 4.2 because the stride measure for the derived type was the same as an integer; add more components and see what happens I am at that stage, where I can fix the testcase but other things break :-) Watch this space. This is another bug, where the array descriptor reform will afford a permanent fix. If I do not see a quick fix soon, I will concentrate on array descriptors. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression]|Problem with a pointer array |Problem with a pointer array|passed to a subroutine |passed to a subroutine | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309
[Bug ada/42554] Can't build GNAT tools
--- Comment #8 from simon at pushface dot org 2010-02-02 06:26 --- It's much worse than that.. Aside from the other object file which triggers the same bug, the make of gnatlink and gnatmake calls in libgnat.a twice. And when you build the other GNAT tools, it calls in all the Ada-derived RTS object files explicitly as well as libgnat.a. I did try deleting them, but (a) the C-derived object files are required, (b) that would mean rebuilding the entire RTS for the smallest change. So I reorganised the bind/link not to call in libgnat.a; to do that you need a libgnatc.a for the C-derived object files. So far so good; but now 'make check-ada' fails for every test in exactly the same way! See http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01596.html (also referenced in comment #4) for the last attempt at this approach (NB it has one error, see http://gcc.gnu.org/ml/gcc-patches/2010-02/msg5.html). I agree my latest patch here is rather global, but Fortran builds fine and 'make check-fortran' is only showing XFAILs. I can probably make an alternative, restricted to Ada only, might stand more chance of being accepted. -- simon at pushface dot org changed: What|Removed |Added Summary|Can't build gnatlink, |Can't build GNAT tools |gnatmake| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
