[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 unit size align 32 symtab 0 alias set -1 canonical type 0xb785edd0 precision 32 min max > readonly used public static unsigned external nonlocal decl_3 decl_5 decl_6 SI file t.ii line 2 col 27 size unit size align 32 context chain > 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 > > type size > unit size > align 32 symtab 0 alias set -1 canonical type 0xb785edd0 precision 32 > min max > > readonly used public static unsigned external nonlocal decl_3 decl_5 > decl_6 > SI file t.ii line 2 col 27 size unit size > > align 32 context > chain > > > 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=gcc&view=rev&rev=13 > Log: 2008-02-10 H.J. Lu > Backport from mainline: > 2007-08-06 H.J. Lu > Daniel Jacobowitz > 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] New: Internal server error during FreeBSD 7.1 kernel compilation
Here is the gcc log : ===> scsi_low (all) /usr/local/libexec/ccache/world-cc -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 /usr/src/sys/modules/scsi_low/../../cam/scsi/scsi_low.c: In function 'scsi_low_disconnected': /usr/src/sys/modules/scsi_low/../../cam/scsi/scsi_low.c:4194: internal compiler error: in unify_nodes, at tree-ssa-structalias.c:1231 I have little more to add than this. Hope it might help improve gcc even if know it's not really a very useful bug report. I don't know the kernel build system well and I don't really have time to find a lot more than that. -- Summary: Internal server error during FreeBSD 7.1 kernel compilation Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla-gcc at undoso dot eu GCC host triplet: FreeBSD x86 GCC target triplet: FreeBSD x86 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 #4 from rguenth at gcc dot gnu dot org 2009-02-14 18:48 --- Btw, this looks like similar to PR36207 which was fixed in the Ada frontend. Still I think that i386_pe_binds_local_p is completely bogus. -- 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 #5 from rguenth at gcc dot gnu dot org 2009-02-14 18:49 --- Jason, can we fix this in the C++ frontend? Having both TREE_STATIC and DECL_EXTERNAL set seems bogus. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c/39194] New: options -O3 and -msse does not cooperate ?
Hi,
I try the following code:
#define MAX_N 40
#define MAX_R 25
#ifndef FALSE
#define FALSE 0
#define TRUE 1
#endif
static unsigned int bin_coeff_tab[ MAX_N ][ MAX_R ];
static int is_calculated = FALSE;
static void
bin_coeff_init( void )
{
int i, j;
for( i = 0; i < MAX_N; i++ )
bin_coeff_tab[ i ][ 0 ] = i + 1;
for( j = 1; j < MAX_R; j++ )
bin_coeff_tab[ 0 ][ j ] = 0;
for( i = 1; i < MAX_N; i++ )
for( j = 1; j < MAX_R; j++ )
bin_coeff_tab[ i ][ j ] = bin_coeff_tab[ i - 1 ][ j - 1 ] +
bin_coeff_tab[ i - 1 ][ j ];
is_calculated = TRUE;
}
int main()
{
bin_coeff_init();
return 0;
}
(There is no header file included, so I won't include the .i file)
If I try to compile this with both -O3 and -msse, I get a segmentation fault.
> gcc --version
gcc (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
the assembler code file becomes:
.file "mytest.c"
.def___main;.scl2; .type 32; .endef
.text
.p2align 2,,3
.globl _main
.def_main; .scl2; .type 32; .endef
_main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %esi
pushl %ebx
pushl %ecx
subl$12, %esp
call___main
movl$_bin_coeff_tab, %edx
xorl%eax, %eax
.p2align 2,,3
L2:
incl%eax
movl%eax, (%edx)
addl$100, %edx
cmpl$40, %eax
jne L2
movl$0, _bin_coeff_tab+4
movl$0, _bin_coeff_tab+8
movl$0, _bin_coeff_tab+12
xorps %xmm0, %xmm0
movaps %xmm0, _bin_coeff_tab+16
movaps %xmm0, _bin_coeff_tab+32
movaps %xmm0, _bin_coeff_tab+48
movaps %xmm0, _bin_coeff_tab+64
movaps %xmm0, _bin_coeff_tab+80
movl$0, _bin_coeff_tab+96
movl$1, %esi
.p2align 2,,3
L3:
leal(%esi,%esi,4), %eax
leal(%eax,%eax,4), %eax
leal_bin_coeff_tab-100(,%eax,4), %edx
leal_bin_coeff_tab+4(,%eax,4), %ebx
movl$1, %ecx
.p2align 2,,3
L4:
movl4(%edx), %eax
addl(%edx), %eax
movl%eax, (%ebx)
incl%ecx
addl$4, %edx
addl$4, %ebx
cmpl$25, %ecx
jne L4
incl%esi
cmpl$40, %esi
jne L3
movl$1, _is_calculated
xorl%eax, %eax
addl$12, %esp
popl%ecx
popl%ebx
popl%esi
leave
leal-4(%ecx), %esp
ret
.lcomm _is_calculated,16
.lcomm _bin_coeff_tab,4000
Best regards,
-Øystein
--
Summary: options -O3 and -msse does not cooperate ?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oystein at gnubg dot org
GCC host triplet: windows (mingw)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39194
[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
>
> type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0xb785edd0 precision 32
> min max >
> readonly used public static unsigned external nonlocal decl_3 decl_5
> decl_6
> SI file t.ii line 2 col 27 size unit size
>
> align 32 context
> chain >
>
> 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=17300&action=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=17301&action=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=17302&action=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 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
