[Bug gcov-profile/38292] [4.3/4.4 Regression] corrupted profile info with -O[23] -fprofile-use
--- Comment #7 from doko at ubuntu dot com 2009-02-14 09:08 --- seen as well on sparc-linux, x86_64-linux and i486-linux (when built with -mcpu=i686 -mtune=i586), although triggered in different files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
[Bug c++/39191] New: Wrong warning with control reaches end of non-void function
In this code:
//Load a style icon as a pixmap
QPixmap loadImagePixmap(const QString fileName)
{
for (int i = 0; i cacheOfPixmaps.size(); ++i) {
if(ScacheOfPixmaps.at(i)==fileName)
return cacheOfPixmaps.at(i);
}
QString fullPath=loadFilePathIntheStyle(fileName);
if(!QFile::exists(fullPath))
{
return QPixmap();
DEBUGCONSOLE(10,loadImagePixmap,fileName+ not found.);
}
else
{
QPixmap theReturnedImage(fullPath);
if(theReturnedImage.isNull())
{
DEBUGCONSOLE(10,loadImagePixmap,fileName+ can't be
opened.);
}
else
{
cacheOfPixmaps.append(theReturnedImage);
ScacheOfPixmaps.append(fileName);
}
return theReturnedImage;
}
}
It's say me:
main.cpp: In function 'QPixmap loadImagePixmap(const QString)':
main.cpp:313: warning: control reaches end of non-void function
It's wrong because need always return a value.
--
Summary: Wrong warning with control reaches end of non-void
function
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alpha dot super-one at laposte dot net
GCC host triplet: linux x86_64
GCC target triplet: linux x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39191
[Bug fortran/39192] New: poor error message
gfortran test.f90 test.f90:1.10: IF (i==2) b(3) 1 Error: Cannot assign to a named constant at (1) cat test.f90 IF (i==2) b(3) END (The correct code would have been, the error message is confusing, syntax error would have been better) IF (i==2) CALL b(3) END -- Summary: poor error message Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39192
[Bug fortran/39192] poor error message
--- Comment #1 from domob at gcc dot gnu dot org 2009-02-14 09:50 --- Confirmed. -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-02-14 09:50:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39192
[Bug c++/36254] [4.2/4.3 Regression] wrong control reaches end of non-void function warning with IF_STMT
--- Comment #16 from pinskia at gcc dot gnu dot org 2009-02-14 10:05 --- *** Bug 39191 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||alpha dot super-one at ||laposte dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36254
[Bug c++/39191] Wrong warning with control reaches end of non-void function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-14 10:05 --- This has since been fixed for 4.4.0 (on the trunk). *** This bug has been marked as a duplicate of 36254 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39191
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #9 from rob1weld at aol dot com 2009-02-14 14:36 --- The Beast raises it's head (just C only): # x86_64-pc-solaris2.11-gcc -v Using built-in specs. Target: x86_64-pc-solaris2.11 Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11 --target=x86_64-pc-solaris2.11 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090214 (experimental) [trunk revision 144177] (GCC) Tada, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug target/39149] [4.4 Regression] Typo in i386.c
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-14 14:37 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|Typo in i386.c |[4.4 Regression] Typo in ||i386.c Target Milestone|4.3.4 |4.4.0 Version|4.3.3 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #92 from stevenb dot gcc at gmail dot com 2009-02-14 14:42 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines Re: Comment #88 I think the patch is perfectly acceptable as a stop-gap solution. I don't think we have anything better for 4.4. Maybe you can add a FIXME, though... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug fortran/39189] Improvement in handling COMMON'ed pointers to allocatable arrays
--- Comment #1 from kargl at gcc dot gnu dot org 2009-02-14 16:00 --- I'm inclined to think that this should be closed with WONTFIX. Deallocation of an allocated array when a subprogram returns is a fundamental concept of Fortran. A user should know what to expect and code accordingly. I'll let one of the other gfortran contributors make a final determination of the merits of a warning. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39189
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-14 16:55 ---
Single-file testcase, reproduces with a x86_64-pc-mingw32 cross at any
optimization level. get_symbol_constant_value returns zero for K::k.
struct K {
static const unsigned k;
};
extern C void abort (void);
int main() {
if ( K::k != 1 )
abort ();
return 1;
}
--
rguenth 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-02-14 16:55:18
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-14 17:03 --- The problem is that targetm.binds_local_p returns true for var_decl 0xb7866000 k type integer_type 0xb785edd0 unsigned int readonly unsigned SI size integer_cst 0xb778b4a4 constant 32 unit size integer_cst 0xb778b1f8 constant 4 align 32 symtab 0 alias set -1 canonical type 0xb785edd0 precision 32 min integer_cst 0xb778b4c8 0 max integer_cst 0xb778b480 4294967295 readonly used public static unsigned external nonlocal decl_3 decl_5 decl_6 SI file t.ii line 2 col 27 size integer_cst 0xb778b4a4 32 unit size integer_cst 0xb778b1f8 4 align 32 context record_type 0xb785ec30 K chain type_decl 0xb785ed00 K though probably nobody thought of handling TREE_STATIC DECL_EXTERNAL being true at the same time. Thus, this looks like a possible C++ FE problem to me? A simple fix would be for i386_pe_binds_local_p to return false if DECL_EXTERNAL is set, as this is what default_binds_local_p_1 does. Or better, it should dispatch to default_binds_local_p_1 and only adjust the shlib flag according to DECL_DLLIMPORT_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-02-14 17:16 --- The problem is that targetm.binds_local_p returns true for var_decl 0xb7866000 k type integer_type 0xb785edd0 unsigned int readonly unsigned SI size integer_cst 0xb778b4a4 constant 32 unit size integer_cst 0xb778b1f8 constant 4 align 32 symtab 0 alias set -1 canonical type 0xb785edd0 precision 32 min integer_cst 0xb778b4c8 0 max integer_cst 0xb778b480 4294967295 readonly used public static unsigned external nonlocal decl_3 decl_5 decl_6 SI file t.ii line 2 col 27 size integer_cst 0xb778b4a4 32 unit size integer_cst 0xb778b1f8 4 align 32 context record_type 0xb785ec30 K chain type_decl 0xb785ed00 K though probably nobody thought of handling TREE_STATIC DECL_EXTERNAL being true at the same time. Thus, this looks like a possible C++ FE problem to me? FWIW we had the same problem in Ada on this platform and we fixed Gigi. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/31868] Non-Linux DWARF EH x86-64 targets have broken crtend.o
--- Comment #9 from rob1weld at aol dot com 2009-02-14 17:28 --- (In reply to comment #8) Subject: Bug 31868 Author: hjl Date: Sun Feb 10 22:25:24 2008 New Revision: 13 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=13 Log: 2008-02-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2007-08-06 H.J. Lu hongjiu...@intel.com Daniel Jacobowitz d...@codesourcery.com PR target/31868 * config.gcc (x86_64-*-freebsd*): Add i386/t-crtstuff to tmake_file. (x86_64-*-netbsd*): Likewise. (x86_64-*-linux*): Likewise. (x86_64-*-kfreebsd*-gnu): Likewise. (x86_64-*-knetbsd*-gnu): Likewise. (i[34567]86-*-solaris2.1[0-9]*): Likewise. * config/i386/t-linux64 (CRTSTUFF_T_CFLAGS): Removed. * config/i386/t-crtstuff (CRTSTUFF_T_CFLAGS): Update comments. Add -fno-asynchronous-unwind-tables. * config/t-freebsd (CRTSTUFF_T_CFLAGS_S): Add $(CRTSTUFF_T_CFLAGS). * config/t-libc-ok (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-lynx (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-netbsd (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-svr4 (CRTSTUFF_T_CFLAGS_S): Likewise. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config.gcc branches/gcc-4_2-branch/gcc/config/i386/t-crtstuff branches/gcc-4_2-branch/gcc/config/i386/t-linux64 branches/gcc-4_2-branch/gcc/config/t-freebsd branches/gcc-4_2-branch/gcc/config/t-libc-ok branches/gcc-4_2-branch/gcc/config/t-lynx branches/gcc-4_2-branch/gcc/config/t-netbsd branches/gcc-4_2-branch/gcc/config/t-svr4 Notification: This issue affects the (missing / new ?) Target: x86_64-pc-solaris2.11 The x86_64-pc-solaris2.11 Target refers to a Native-Cross on OpenSolaris 2009.06 (snv_106) from i386-pc-solaris2.11 to x86_64-pc-solaris2.11. In either 32 or 64 bit Boot Mode the Solaris Platform's uname will say we are i386. The correct thing to do is use isainfo -k. Here is a bit of info on this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150 Here is it's -v: # x86_64-pc-solaris2.11-gcc -v Using built-in specs. Target: x86_64-pc-solaris2.11 Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11 --target=x86_64-pc-solaris2.11 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090214 (experimental) [trunk revision 144177] (GCC) If and when x86_64-pc-solaris2.11 becomes popular this Bug Report may need to be reopened, and this patch fixed and applied. Then we can check if we missed any other Targets and close this Bug for good. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
[Bug c/39193] Internal server error during FreeBSD 7.1 kernel compilation
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-14 19:21 --- We need preprocessed source of the testcase which you can obtain by appending -save-temps to the command line. The file will be called scsi_low.i. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug target/39194] options -O3 and -msse does not cooperate ?
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-14 19:24 --- I suppose _bin_coeff_tab is not properly aligned. Maybe PE support is not properly honoring DECL_ALIGN. Please try also GCC 4.3.3 which has many bugfixes compared to 4.3.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC host triplet|windows (mingw) | GCC target triplet||mingw32-*-* Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39194
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-02-14 20:10 ---
(In reply to comment #2)
The problem is that targetm.binds_local_p returns true for
var_decl 0xb7866000 k
type integer_type 0xb785edd0 unsigned int readonly unsigned SI
size integer_cst 0xb778b4a4 constant 32
unit size integer_cst 0xb778b1f8 constant 4
align 32 symtab 0 alias set -1 canonical type 0xb785edd0 precision 32
min integer_cst 0xb778b4c8 0 max integer_cst 0xb778b480 4294967295
readonly used public static unsigned external nonlocal decl_3 decl_5
decl_6
SI file t.ii line 2 col 27 size integer_cst 0xb778b4a4 32 unit size
integer_cst 0xb778b1f8 4
align 32 context record_type 0xb785ec30 K
chain type_decl 0xb785ed00 K
though probably nobody thought of handling TREE_STATIC DECL_EXTERNAL being
true at the same time. Thus, this looks like a possible C++ FE problem to me?
A simple fix would be for i386_pe_binds_local_p to return false if
DECL_EXTERNAL is set, as this is what default_binds_local_p_1 does.
Or better, it should dispatch to default_binds_local_p_1 and only
adjust the shlib flag according to DECL_DLLIMPORT_P.
Right in winnt.c (i386_pe_bind_local_p) should be something like this patch,
but sadly we get then emitted @GOTPCREL, which aren't handled proper by COFF
targets.
Index: gcc/gcc/config/i386/winnt.c
===
--- gcc.orig/gcc/config/i386/winnt.c
+++ gcc/gcc/config/i386/winnt.c
@@ -321,13 +321,14 @@ i386_pe_encode_section_info (tree decl,
bool
i386_pe_binds_local_p (const_tree exp)
{
+ bool flag = true;
/* PE does not do dynamic binding. Indeed, the only kind of
non-local reference comes from a dllimport'd symbol. */
if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
DECL_DLLIMPORT_P (exp))
-return false;
+flag = false;
- return true;
+ return flag default_binds_local_p_1 (exp, flag_shlib);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #2 from bugzilla-gcc at undoso dot eu 2009-02-14 20:12 --- I have tried to get the file but when I execute /usr/local/libexec/ccache/world-cc -save-temps -Os -pipe -mmmx -msse -msse2 -msse3 -march=pentiumpro -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/scsi_low/../../cam/scsi/scsi_low.c The ICE is stil there but no scsi_low.i file is generated. A file called scsi_low.tmp..16101.s des appear but that is all I have. -- bugzilla-gcc at undoso dot eu changed: What|Removed |Added Summary|Internal server error during|Internal compiler error |FreeBSD 7.1 kernel |during FreeBSD 7.1 kernel |compilation |compilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-14 21:10 --- You need to remove -pipe from the commandline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-14 21:12 --- What happens if you just use return default_binds_local_p_1 (exp, (TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) DECL_DLLIMPORT_P (exp)); ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #17 from sebor at roguewave dot com 2009-02-14 21:21 --- Created an attachment (id=17300) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17300action=view) Unified money_get and num_get test case and results. Attached is a unified test case with test results on popular platforms. The assertions reflect the behavior described in comment #4 which may actually turn out to be incorrect in the end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #4 from bugzilla-gcc at undoso dot eu 2009-02-14 21:24 --- gcc told me it was ignored before. But I tried anyway. The file is still not created even without -pipe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-14 21:25 --- (In reply to comment #7) What happens if you just use return default_binds_local_p_1 (exp, (TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) DECL_DLLIMPORT_P (exp)); ? Same issue @GOTPCREL code gets emitted. ... movq__zn1k...@gotpcrel(%rip), %rax cmpl$1, (%rax) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #18 from sebor at roguewave dot com 2009-02-14 21:41 --- I was too hasty -- the attached test case is buggy: it's missing a seek to the beginning of the stream after the first extraction, making the results for the num_get part meaningless. (In reply to comment #7) Arbitrary length is not quite correct here - 123,456 violates grouping, given with string(1, CHAR_MAX). Standard use term unlimited length, which means(as I understand) that all other digits should incorporate in only one group - only 123456 is correct. That seems like a reasonable interpretation but others appear to be possible as well. Looks like this needs to be clarified. (In reply to comment #12) Let's consider the following situation (seems lifelike to me). Suppose one needs a representation of numbers in which only the last 3 digits are separated from all other digits (grouped), like 1234,567 or 1234567,890. Other separators shouldn't appear. It seems that \003\000 should do that, and unless I'm mistaken, does with libstc++ (but not other implementations). (In reply to comment #13) POSIX seems a good point, probably you should have mentioned it much earlier. Let's hear Martin again, then. Certainly, however, I'm concerned about having a behavior different from all the other implementations mentioned by Martin. I agree. It would be good to reconcile any accidental differences between C++ and POSIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-14 21:50 --- Hm, if you add -v as well you should see a separate pre-processing and compilation sub-commands. The compilation subcommand should refer to the scsi_low.i file, wherever it is created. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #19 from paolo dot carlini at oracle dot com 2009-02-14 21:54 --- Thanks Martin. Then, as requested by submitter, for now I'm just going to tweak a bit the behaviour of libstdc++ to bring consistency between unsigned and signed char platforms, in other terms, value = 0 and value == CHAR_MAX will lead to the same behavior everywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #93 from lucier at math dot purdue dot edu 2009-02-14 21:58 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines I instrumented the compiler and looked how many nodes were in each loop processed by LICM for the Gambit runtime and compiler. For generated code, except for the loop that contained the entire function, the greatest number of nodes was 30. (Because computed gotos are used in the code that checks for heap and stack overflows after allocations and for waiting interrupts, it's hard to go long in Scheme code without hitting the big loop.) For hand-written code, the greatest number of nodes in a loop was 123. When bootstrapping gcc with --enable-languages=c, the largest number of nodes in a loop was 803, and there were 12 loops detected that had over 500 nodes. 548 loops had 100 nodes or greater. (This is a bootstrap, so some files were compiled twice with the instrumented compiler.) So perhaps an -O1 default for LICM of 100 nodes is reasonable, or perhaps one might up it to 1000 just to catch everything reasonable. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #20 from sebor at roguewave dot com 2009-02-14 21:58 --- Created an attachment (id=17301) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17301action=view) Corrected unified demo. Attached a corrected unified demo with assertions removed and with output on popular implementations for reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #6 from bugzilla-gcc at undoso dot eu 2009-02-14 22:01 --- I'm probably blind, but I don't see it : /usr/libexec/cc1 -E -quiet -nostdinc -v -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC -D_LONGLONG -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h /usr/src/sys/modules/scsi_low/../../cam/scsi/scsi_low.c -march=pentiumpro -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fno-strict-aliasing -finline-limit=8000 -fno-common -ffreestanding -fformat-extensions -fworking-directory -Os -fpch-preprocess -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #7 from bugzilla-gcc at undoso dot eu 2009-02-14 22:03 --- Oops, I forgot the next line : /usr/libexec/cc1 -fpreprocessed /root/.ccache/scsi_low.tmp..22970.i -quiet -dumpbase scsi_low.tmp..22970.i -march=pentiumpro -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -auxbase-strip /root/.ccache/tmp.hash..22970.o -g -Os -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -std=c99 -version -fno-strict-aliasing -finline-limit=8000 -fno-common -ffreestanding -fformat-extensions --param inline-unit-growth=100 --param large-function-growth=1000 -o scsi_low.tmp..22970.s And I would like to add that wherever a *.i file is signaled, there is no in the place it should be. Maybe it fails before it can be generated ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-14 22:54 --- It would be this one: /root/.ccache/scsi_low.tmp..22970.i Maybe instead of /usr/local/libexec/ccache/world-cc use the system gcc command? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug target/39179] Wrong code in c++ for const members initialized in external file
--- Comment #9 from nightstrike at gmail dot com 2009-02-14 22:56 --- Verified to fail on win32 and win64, not just win64. Can someone with sufficient privileges adjust Target? Verified to work in 4.3, so this is a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c/39193] Internal compiler error during FreeBSD 7.1 kernel compilation
--- Comment #9 from bugzilla-gcc at undoso dot eu 2009-02-14 23:06 --- Created an attachment (id=17302) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17302action=view) Proprocessed source of the error Yes, should have thought to do that before. It was obvious that ccache might not help there. Here is the file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #94 from dberlin at gcc dot gnu dot org 2009-02-14 23:06 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines One of the reasons LCM in RTL is so slow is because it uses a crappy iteration order. With the right iteration order, it should be fast enough to turn it back on and remove the address calculations in these testcases. If it was block based, it would have been converted to use the DF solver and gotten this automatically, but because it's edge based, pretty much nobody has touched it since it was created :) Even adding qsorts in the right place that sort the worklists into the right order on each iteration would probably help orders of magnitude here (though moving to the two worklist solver that DF now uses would be even better). On Sat, Feb 14, 2009 at 4:58 PM, lucier at math dot purdue dot edu gcc-bugzi...@gcc.gnu.org wrote: --- Comment #93 from lucier at math dot purdue dot edu 2009-02-14 21:58 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines I instrumented the compiler and looked how many nodes were in each loop processed by LICM for the Gambit runtime and compiler. For generated code, except for the loop that contained the entire function, the greatest number of nodes was 30. (Because computed gotos are used in the code that checks for heap and stack overflows after allocations and for waiting interrupts, it's hard to go long in Scheme code without hitting the big loop.) For hand-written code, the greatest number of nodes in a loop was 123. When bootstrapping gcc with --enable-languages=c, the largest number of nodes in a loop was 803, and there were 12 loops detected that had over 500 nodes. 548 loops had 100 nodes or greater. (This is a bootstrap, so some files were compiled twice with the instrumented compiler.) So perhaps an -O1 default for LICM of 100 nodes is reasonable, or perhaps one might up it to 1000 just to catch everything reasonable. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug target/39179] Wrong code in c++ for const members initialized in external file
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-14 23:38 --- This latent bug is triggered by the part of revision 143157: --- Index: i386.c === --- i386.c (revision 143154) +++ i386.c (working copy) @@ -22183,6 +22183,11 @@ ix86_init_mmx_sse_builtins (void) V8SI_type_node, V4SI_type_node, integer_type_node, NULL_TREE); + tree pv4di_type_node = build_pointer_type (V4DI_type_node); + tree void_ftype_pv4di_v4di += build_function_type_list (void_type_node, + pv4di_type_node, V4DI_type_node, + NULL_TREE); tree v8sf_ftype_v8sf_v4sf_int = build_function_type_list (V8SF_type_node, V8SF_type_node, V4SF_type_node, --- This patch: Index: cp/decl.c === --- cp/decl.c (revision 143157) +++ cp/decl.c (working copy) @@ -1549,6 +1549,7 @@ duplicate_decls (tree newdecl, tree oldd error (after previous specification in %q+#D, olddecl); } + return error_mark_node; } } } works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
