[Bug c++/37765] Printf of typed null pointer causes a run-time error
--- Comment #1 from schwab at suse dot de 2008-10-08 07:36 --- %s requires a pointer to a string, which (char*)0 isn't. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37765
[Bug middle-end/37730] [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-08 08:01 --- Well, the RHS scalar alias set is IMHO irrelevant. What is relevant is the alias set of the store. Which is why I think the assert is somewhat bogus. Note that the gimple type-system allows assignment of any pointer to a void * pointer without a conversion, which is what happens here. It looks like on RTL we treat the RHS as memory load (because of the constructor) and for this reason verify that the alias sets are compatible. But I think there is no reason to assert that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37730
[Bug rtl-optimization/37341] Internal error: Segmentation fault (program cc1)
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-08 08:13 --- Subject: Bug 37341 Author: jakub Date: Wed Oct 8 08:12:25 2008 New Revision: 140966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140966 Log: PR target/36635 PR target/37290 PR rtl-optimization/37341 * cse.c (cse_cc_succs): Add ORIG_BB argument, don't follow edges to ORIG_BB, pass through ORIG_BB recursively. (cse_condition_code_reg): Adjust caller. * gcc.c-torture/compile/pr37341.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37341.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37341
[Bug target/37290] [4.4 Regression] Endless recursion in cse_cc_succs
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-08 08:13 --- Subject: Bug 37290 Author: jakub Date: Wed Oct 8 08:12:25 2008 New Revision: 140966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140966 Log: PR target/36635 PR target/37290 PR rtl-optimization/37341 * cse.c (cse_cc_succs): Add ORIG_BB argument, don't follow edges to ORIG_BB, pass through ORIG_BB recursively. (cse_condition_code_reg): Adjust caller. * gcc.c-torture/compile/pr37341.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37341.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37290
[Bug target/36635] [4.4 Regression] cc1 segfault from svn 137122
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-08 08:13 --- Subject: Bug 36635 Author: jakub Date: Wed Oct 8 08:12:25 2008 New Revision: 140966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140966 Log: PR target/36635 PR target/37290 PR rtl-optimization/37341 * cse.c (cse_cc_succs): Add ORIG_BB argument, don't follow edges to ORIG_BB, pass through ORIG_BB recursively. (cse_condition_code_reg): Adjust caller. * gcc.c-torture/compile/pr37341.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37341.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36635
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
--- Comment #11 from jakub at gcc dot gnu dot org 2008-10-08 08:16 --- If fixed, it should be closed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug target/36635] [4.4 Regression] cc1 segfault from svn 137122
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-08 08:16 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36635
[Bug target/37290] [4.4 Regression] Endless recursion in cse_cc_succs
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-08 08:16 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37290
[Bug c++/37770] New: static structures initialization, undefined reference to `_0'
The bug is present with both system `gcc 4.2.1 20070719' and `gcc 4.2.5
20080702 (prerelease)' built from ports. Also present on both i386 and amd64,
althrough symptoms are different.
- Code:
struct struct1 {
int int1;
int int2;
};
struct struct2 {
struct2(const struct1 REF s) { S = s; }
struct1 S;
};
static const struct2 arr[] = {
struct2( (struct1){1,2} )
};
int main() {
return arr[0].S.int1 + arr[0].S.int2;
}
-
Symptoms:
$ g++ test.c -DREF=''
/var/tmp//ccad9L64.o(.text+0x40): In function
`__static_initialization_and_destruction_0(int, int)':
: undefined reference to `_0'
/var/tmp//ccad9L64.o(.text+0x45): In function
`__static_initialization_and_destruction_0(int, int)':
: undefined reference to `_0'
collect2: ld returned 1 exit status
$ g++ test.c -DREF=''
$
-O2 reverses this behavior:
$ g++ -O2 test.c -DREF=''
/var/tmp//ccPsUIZY.o(.text+0x31): In function
`__static_initialization_and_destruction_0(int, int)':
: undefined reference to `_0'
/var/tmp//ccPsUIZY.o(.text+0x3b): In function
`__static_initialization_and_destruction_0(int, int)':
: undefined reference to `_0'
collect2: ld returned 1 exit status
$ g++ -O2 test.c -DREF=''
$
On amd64 error messages are different:
$ g++ test.c -DREF=''
/var/tmp//cclgnYrV.s: Assembler messages:
/var/tmp//cclgnYrV.s:63: Error: junk `(%rip)' after expression
$ g++ test.c -DREF=''
$ g++ -O2 test.c -DREF=''
$ g++ -O2 test.c -DREF=''
/var/tmp//ccG5mp46.s: Assembler messages:
/var/tmp//ccG5mp46.s:31: Error: junk `(%rip)' after expression
/var/tmp//ccG5mp46.s:33: Error: junk `(%rip)' after expression
$
--
Summary: static structures initialization, undefined reference to
`_0'
Product: gcc
Version: 4.2.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amdmi3 at amdmi3 dot ru
GCC build triplet: i386-portbld-freebsd7.0
GCC host triplet: i386-portbld-freebsd7.0
GCC target triplet: i386-portbld-freebsd7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37770
[Bug c/37771] warning: implicit declaration of function 'fileno'
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-08 12:48 --- The warning is correct: by default, fileno, not being a standard C function, is simply not declared in the stdio.h header of your linux machine. A quick look to the man page reveals that the function is declared when, e.g., _POSIX_SOURCE is defined. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary| warning: implicit |warning: implicit |declaration of function |declaration of function |'fileno'|'fileno' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37771
[Bug c/37771] warning: implicit declaration of function 'fileno'
--- Comment #2 from mathieu dot malaterre at gmail dot com 2008-10-08 12:52 --- Hum... ok nevermind. My man page must be outdated. ref: FERROR(3) Linux Programmer's Manual FERROR(3) NAME clearerr, feof, ferror, fileno - check and reset stream status SYNOPSIS #include stdio.h void clearerr(FILE *stream); int feof(FILE *stream); int ferror(FILE *stream); int fileno(FILE *stream); DESCRIPTION The function clearerr() clears the end-of-file and error indicators for the stream pointed to by stream. The function feof() tests the end-of-file indicator for the stream pointed to by stream, returning non-zero if it is set. The end-of-file indicator can only be cleared by the function clearerr(). The function ferror() tests the error indicator for the stream pointed to by stream, returning non-zero if it is set. The error indicator can only be reset by the clearerr() function. The function fileno() examines the argument stream and returns its integer descriptor. For non-locking counterparts, see unlocked_stdio(3). ERRORS These functions should not fail and do not set the external variable errno. (However, in case fileno() detects that its argument is not a valid stream, it must return -1 and set errno to EBADF.) CONFORMING TO The functions clearerr(), feof(), and ferror() conform to C89. SEE ALSO open(2), fdopen(3), stdio(3), unlocked_stdio(3) 2001-10-16 FERROR(3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37771
[Bug c/37771] warning: implicit declaration of function 'fileno'
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-08 12:56 --- Note, anyway, that fileno is not present in CONFORMING TO as a C89 function. Which indeed it is not. In any case, the ultimate reference is the C Standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37771
[Bug c/37772] New: ICE with empty asm statement
[forwarded from https://bugs.launchpad.net/bugs/280107]
seen with 4.2, 4.3 branches and trunk 20080915.
int foo() {
asm();
return 0;
}
$ /usr/lib/gcc-snapshot/bin/gcc -g -O0 foo.c
foo.c: In function 'foo':
foo.c:2: error: expected string literal before ')' token
foo.c:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: ICE with empty asm statement
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37772
[Bug c++/37769] New: internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525
gcc-4.3.0 fails to compile with this message when compiling qtpfsgui-1.9.1. g++ -c -pipe -funroll-loops -fstrength-reduce -fschedule-insns2 -felide-constructors -frerun-loop-opt -fexceptions -fno-strict-aliasing -fexpensive-optimizations -ffast-math -pipe -O2 -g -mieee -fno-schedule-insns -D_REENTRANT -Wall -W -DQT_NO_DEBUG_OUTPUT -DHAVE_FFTW -DI18NDIR=\/usr/share/qtpfsgui/i18n\ -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include -I/usr/include/exiv2 -I/usr/include/OpenEXR -I/usr/include -Igenerated_moc -Igenerated_uic -o generated_obj/pde.o src/TM_operators/fattal02/pde.cpp src/TM_operators/fattal02/pde.cpp: In function 'void exact_sollution(pfs::Array2D*, pfs::Array2D*)': src/TM_operators/fattal02/pde.cpp:273: warning: unused variable 'h' src/TM_operators/fattal02/pde.cpp: In function 'void atimes(long unsigned int, float*, float*, int)': src/TM_operators/fattal02/pde.cpp:654: internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccXkDOUC.out file, please attach this to your bugreport. make: *** [generated_obj/pde.o] Error 1 $ gcc -v Using built-in specs. Target: sh4-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --build=sh4-redhat-linux Thread model: posix gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) -- Summary: internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: masaki dot chikama at gmail dot com GCC build triplet: sh4-redhat-linux GCC target triplet: sh4-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37769
[Bug libstdc++/37767] after many config No support for this host/target combination. message
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-08 09:08 --- Your issue definitely does not qualify as a bug for Bugzilla. Of course you are welcome to work on this cross-configuration, you can ask for help on the libstd++ mailing list and eventually post a patch (please make sure to have filed your Copyright assignment, in that case). Note, any change is vs current mainline SVN (would be 4.4.0), not 4.3.x. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37767
[Bug c/37771] New: warning: implicit declaration of function 'fileno'
The following piece of code should compile without warning:
#include stdio.h
int main()
{
(void)fileno(0);
return 0;
}
Using:
$ gcc -Wall -W -pedantic -ansi -Werror f.c
cc1: warnings being treated as errors
f.c: In function 'main':
f.c:5: warning: implicit declaration of function 'fileno'
With:
$ gcc --version
gcc (GCC) 4.2.3 (Debian 4.2.3-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
thanks
--
Summary: warning: implicit declaration of function 'fileno'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mathieu dot malaterre at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37771
[Bug c++/37770] static structures initialization, undefined reference to `_0'
--- Comment #1 from amdmi3 at amdmi3 dot ru 2008-10-08 12:39 --- Just tested gcc 4.3: this version doesn't seem to have this bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37770
[Bug c++/37213] Declaration/expression ambiguity resolution does not extend beyond initializer
--- Comment #3 from akyrtzi at gmail dot com 2008-10-08 09:19 --- And some bit of C++ standard wisdom: C++ 6.8p1: To disambiguate, the whole statement might have to be examined to determine if it is an expression-statement or a declaration And there's this example given: T(a)-m = 7; // expression-statement I think the same applies to the example I gave: T(a)(x,y)-m = 7; // should be an expression -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37213
[Bug c++/18770] g++ accepts invalid code with scopes on ifs
--- Comment #3 from akyrtzi at gmail dot com 2008-10-08 09:09 ---
Note that the same rule applies to the 'switch' statement too:
switch (int x = 1)
{
default:
int x = 2; // there should be an error because of redeclaration
}
--
akyrtzi at gmail dot com changed:
What|Removed |Added
CC||akyrtzi at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18770
[Bug c++/37769] internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525
--- Comment #1 from masaki dot chikama at gmail dot com 2008-10-08 10:29 --- Created an attachment (id=16478) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16478action=view) ccXkDOUC.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37769
[Bug c/37768] New: bogus warnings on x86_64-mingw32 due to attribute((format(printf))) breakage
When gcc is configured to generate code for x86_64-pc-mingw32, that is MinGW
for 64-bit Windows, attribute((format(printf))) is redefined by the backend to
be compatible with MSVC's runtime library, which differs significantly from
C99.
This is fine for calls that link to MSVC's library, but it breaks code that
uses private implementations of C99-compliant formatting routines, because the
backend redefines ALL uses of attribute((format(printf))) to mean MSVC's printf
not C99. The result is that C99-compliant code gets stray warnings and
inadequate printf format checking on x86_64-pc-mingw32.
The program below illustrates the issue. It declares a private C99-compliant
snprintf() implementation and invokes it with %zu and %llx formats. This
triggers the following bogus warnings on x86_64-pc-mingw32:
x86_64-pc-mingw32-gcc -std=c99 -O -Wall -c badwarning.c
badwarning.c: In function 'main':
badwarning.c:16: warning: unknown conversion type character 'z' in format
badwarning.c:16: warning: unknown conversion type character 'l' in format
badwarning.c:16: warning: too many arguments for format
What I think the backend should do is to implement an msprintf format type,
and then Mingw-w64 should declare printf() et al using that not plain printf.
/* badwarning.c */
#include stddef.h
#include stdarg.h
int __attribute__((format(printf, 3, 4)))
my_snprintf(char *buf, size_t n, const char *fmt, ...)
{
/* invoke C99 compliant private vsnprintf() here */
return 0;
}
int main(void)
{
char buf[64];
return my_snprintf(buf, sizeof buf, %zu %llx,
sizeof buf, 0ULL);
}
--
Summary: bogus warnings on x86_64-mingw32 due to
attribute((format(printf))) breakage
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37768
[Bug libstdc++/37767] New: after many config No support for this host/target combination. message
I want create libstdc++ of GCC4.3.2 on Target amigaos 68k after some configure i get this lines then this error No support for this host/target combination. I look on older versions and find in file /gcc/gcc/libstdc++-v3/crossconfig.m4 that there is target amigaos miss now. I add now this lines at end of file crossconfig.m4 - AC_DEFINE(HAVE_TANL) AC_DEFINE(HAVE_TANHF) AC_DEFINE(HAVE_TANHL) ;; +*-amigaos*) +AC_CHECK_HEADERS([nan.h ieeefp.h endian.h sys/isa_defs.h \ + machine/endian.h machine/param.h sys/machine.h sys/types.h \ + fp.h locale.h float.h inttypes.h]) +SECTION_FLAGS='-ffunction-sections -fdata-sections' +AC_SUBST(SECTION_FLAGS) +GLIBCXX_CHECK_LINKER_FEATURES +GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT +GLIBCXX_CHECK_WCHAR_T_SUPPORT +AC_DEFINE(HAVE_COPYSIGN) +;; *) AC_MSG_ERROR([No support for this host/target combination.]) ;; esac ]) --- but, i get this messages. Are there more places to add target now ? . checking for C locale to use... generic checking for std::allocator base class... new configure: C header strategy set to c_global checking for enabled long long specializations... yes checking wchar.h usability... no checking wchar.h presence... no checking for wchar.h... no checking for mbstate_t... no checking wctype.h usability... no checking wctype.h presence... no checking for wctype.h... no checking for enabled wchar_t specializations... no checking for sin in -lm... no checking for ISO C99 support in math.h... no checking tgmath.h usability... yes checking tgmath.h presence... yes checking for tgmath.h... yes checking complex.h usability... no checking complex.h presence... no checking for complex.h... no no checking for ISO C99 support in stdio.h... no checking for ISO C99 support in stdlib.h... no checking for fully enabled ISO C99 support... no configure: Debug build flags set to -g3 -O0 checking for additional debug build... no configure: /bernd/obj_68k_4/m68k-amigaos/libstdc++-v3/../libgomp/omp.h not found checking for parallel mode support... no checking for extra compiler flags for building... checking for thread model used by GCC... single checking for atomic builtins... no checking for g++ that supports -ffunction-sections -fdata-sections... no configure: error: No support for this host/target combination. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/bernd/obj_68k_4' make: *** [all] Error 2 -- Summary: after many config No support for this host/target combination. message Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nospamname at web dot de GCC host triplet: cygwin 686 GCC target triplet: amigaos 68k http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37767
[Bug c++/37737] [c++0x] ICE in get_innermost_template_args at cp/pt.c:516 during variadic function overload deduction
--- Comment #3 from cfairles at gcc dot gnu dot org 2008-10-08 14:06 --- changed summary to something more specific -- cfairles at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE on variadic template|[c++0x] ICE in |function|get_innermost_template_args ||at cp/pt.c:516 during ||variadic function overload ||deduction http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37737
[Bug target/33120] Large module object files when declare arrays on Mac OSX
--- Comment #5 from meihome at gmail dot com 2008-10-08 14:28 --- FORTRAN Unit Testing Framework (Fruit) 2.5 is released. The pre-fixed message of 30 is not a dynamic allocated array. The problem should be solved. The project site is: http://fortranxunit.wiki.sourceforge.net/ -- meihome at gmail dot com changed: What|Removed |Added CC||meihome at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug target/33120] Large module object files when declare arrays on Mac OSX
--- Comment #6 from meihome at gmail dot com 2008-10-08 15:35 --- Sorry, the previous fruit_2.5.zip was not tested under gfortran. Please use the new fruit_2.5.1.zip. That corrected the 450MB file problem, and compiled under gfortran. https://sourceforge.net/project/platformdownload.php?group_id=152125sel_platform=6415 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug middle-end/37418] [4.4 Regression] error: type mismatch in address expression, verify_gimple failed
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-08 15:59 --- Looks like I taked over ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jsm28 at gcc dot gnu dot org|rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37418
[Bug c/37768] bogus warnings on x86_64-mingw32 due to attribute((format(printf))) breakage
--- Comment #1 from joseph at codesourcery dot com 2008-10-08 16:15 --- Subject: Re: New: bogus warnings on x86_64-mingw32 due to attribute((format(printf))) breakage On Wed, 8 Oct 2008, mikpe at it dot uu dot se wrote: When gcc is configured to generate code for x86_64-pc-mingw32, that is MinGW for 64-bit Windows, attribute((format(printf))) is redefined by the backend to be compatible with MSVC's runtime library, which differs significantly from C99. Correct. This is the conclusion we eventually reached, that printf would be for the system formats (e.g. for a function wrapping a call to a system function), that gnu_printf would be for the formats accepted by the GNU C Library (including GNU extensions) on all platforms and that ms_printf would be for the MSVC formats, on Windows platforms only. The program below illustrates the issue. It declares a private C99-compliant snprintf() implementation and invokes it with %zu and %llx formats. This triggers the following bogus warnings on x86_64-pc-mingw32: Use gnu_printf for such an implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37768
[Bug c++/37773] New: -Wfatal-errors aborts too early
Many errors span multiple lines. However, any of the first lines start with 'error:' (or so it seems) the rest is not printed anymore (with using -Wfatal-errors). For example: hikaru:~/projects/cwchessboard/cwchessboard-objdirmake tstpgn source='PgnDatabase.cc' object='tstpgn-PgnDatabase.o' libtool=no \ DEPDIR=.deps depmode=pch /bin/sh ../cwchessboard/depcomp \ g++ -DHAVE_CONFIG_H -I. -I../cwchessboard-DCWDEBUG -I/usr/local/install/4.3.1/include $(pkg-config --cflags giomm-2.4) -g3 -Winline -Wfatal-errors -DDEBUG -c -o tstpgn-PgnDatabase.o `test -f 'PgnDatabase.cc' || echo '../cwchessboard/'`PgnDatabase.cc ../cwchessboard/MemoryBlockList.h: In member function âvoid cwchess::pgn::DatabaseSeekable::read_async_open_ready(Glib::RefPtrGio::AsyncResult)â: ../cwchessboard/MemoryBlockList.h:124: error: âchar* util::MemoryBlockNode::block_begin()â is private compilation terminated due to -Wfatal-errors. make: *** [tstpgn-PgnDatabase.o] Error 1 This is little useful. Now I have to recompile without -Wfatal-errors to find: ../cwchessboard/PgnDatabase.cc:52: error: within this context -- Summary: -Wfatal-errors aborts too early Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773
[Bug target/33120] Large module object files when declare arrays on Mac OSX
--- Comment #7 from meihome at gmail dot com 2008-10-08 16:43 --- Sorry for keep on updating this bug report. Fruit 2.6 is now tested and run with gfortran. The rake build system also works. Download and information here: http://fortranxunit.wiki.sourceforge.net/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug c++/37773] -Wfatal-errors aborts too early
--- Comment #1 from carlo at gcc dot gnu dot org 2008-10-08 16:48 --- Here's another one: ../cwchessboard/PgnDatabase.cc:65: error: no matching function for call to âutil::MemoryBlockList::append(gssize)â ../cwchessboard/MemoryBlockList.h:232: note: candidates are: void util::MemoryBlockList::append(Glib::RefPtrutil::MemoryBlockNode, size_t) With -Wfatal-errors the second line is not printed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773
Re: [Bug c++/37773] -Wfatal-errors aborts too early
Sent from my iPhone On Oct 8, 2008, at 9:48 AM, carlo at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from carlo at gcc dot gnu dot org 2008-10-08 16:48 --- Here's another one: This expected behaviour of this option. It was not designed for users really to use it. It was designed to make it easier and faster for automatic reduction of ICEs. Thanks, Andrew Pinski ../cwchessboard/PgnDatabase.cc:65: error: no matching function for call to ‘util::MemoryBlockList::append(gssize)’ ../cwchessboard/MemoryBlockList.h:232: note: candidates are: void util::MemoryBlockList::append(Glib::RefPtrutil::MemoryBlockNode, size_t) With -Wfatal-errors the second line is not printed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773
[Bug c++/37773] -Wfatal-errors aborts too early
--- Comment #2 from pinskia at gmail dot com 2008-10-08 16:57 --- Subject: Re: -Wfatal-errors aborts too early Sent from my iPhone On Oct 8, 2008, at 9:48 AM, carlo at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from carlo at gcc dot gnu dot org 2008-10-08 16:48 --- Here's another one: This expected behaviour of this option. It was not designed for users really to use it. It was designed to make it easier and faster for automatic reduction of ICEs. Thanks, Andrew Pinski ../cwchessboard/PgnDatabase.cc:65: error: no matching function for call to âutil::MemoryBlockList::append(gssize)â ../cwchessboard/MemoryBlockList.h:232: note: candidates are: void util::MemoryBlockList::append(Glib::RefPtrutil::MemoryBlockNode, size_t) With -Wfatal-errors the second line is not printed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773
[Bug middle-end/37774] New: [4.4 Regression] Unnecessary load instruction in a loop
Gcc 4.4 generates an extra load in a loop:
[EMAIL PROTECTED] gcc]$ cat /tmp/b.c
#include tmmintrin.h
extern __m128i src[10];
extern __m128i resdst[10];
void
foo (void)
{
int i;
for (i = 0; i 10; i++)
resdst[i] = _mm_abs_epi16 (src[i]);
}
[EMAIL PROTECTED] gcc]$ gcc -O2 -S /tmp/b.c -o old.s -mssse3
-fno-asynchronous-unwind-tables
[EMAIL PROTECTED] gcc]$ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] gcc]$ cat old.s
.file b.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
pabsw src(%rax), %xmm0
movdqa %xmm0, resdst(%rax)
addq$16, %rax
cmpq$160, %rax
jne .L2
rep
ret
.size foo, .-foo
.ident GCC: (GNU) 4.3.0 20080428 (Red Hat 4.3.0-8)
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O2 -mssse3 -S /tmp/b.c
-fno-asynchronous-unwind-tables
[EMAIL PROTECTED] gcc]$ cat b.s
.file b.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
movdqu src(%rax), %xmm0
pabsw %xmm0, %xmm0
movdqu %xmm0, resdst(%rax)
addq$16, %rax
cmpq$160, %rax
jne .L2
rep
ret
.size foo, .-foo
.ident GCC: (GNU) 4.4.0 20081006 (experimental) [trunk revision
140917]
There are 2 problems:
1. Alignment info is lost and unaligned load is generated.
2. The load isn't needed at all.
--
Summary: [4.4 Regression] Unnecessary load instruction in a loop
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37774
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #21 from ro at techfak dot uni-bielefeld dot de 2008-10-08
17:20 ---
Subject: Re: [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad
cie version 0: offset 0x0
FTR: I've long been using this patch as a workaround until the neccessary
Sun ld patch is available:
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 140759)
+++ gcc/config.gcc (working copy)
@@ -1205,7 +1205,10 @@ i[34567]86-*-solaris2*)
*-*-solaris2.1[0-9]*)
tm_file=${tm_file} i386/x86-64.h i386/sol2-10.h
tm_defines=${tm_defines} TARGET_BI_ARCH=1
- tmake_file=$tmake_file i386/t-crtstuff i386/t-sol2-10
+ tmake_file=$tmake_file i386/t-sol2-10
+ if test x$gnu_ld = xyes; then
+ tmake_file=$tmake_file i386/t-crtstuff
+ fi
need_64bit_hwint=yes
case X${with_cpu} in
Xgeneric|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2008-10-08 17:22 --- FTR: I've long been using this patch as a workaround until the neccessary Sun ld patch is available: Ah, this is helpful, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug c++/37773] -Wfatal-errors aborts too early
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-08 20:00 --- Works as desigened. Really ;) -- 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=37773
[Bug middle-end/37774] [4.4 Regression] Unnecessary load instruction in a loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-08 20:06 --- How is the load not needed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37774
[Bug middle-end/37774] [4.4 Regression] Alignment information is lost for ARRAY_REFs
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-08 20:18 --- Just the alignment information is lost really: (mem/s:V16QI (plus:SI (reg/f:SI 68) (reg:SI 63 [ ivtmp.68 ])) [4 resdst S16 A8]) Which I think is fixed via http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00325.html . The load is needed. If we use a pointer instead of an array we get: L2: pabsw (%ecx,%eax), %xmm0 movdqa %xmm0, (%edx,%eax) addl$16, %eax cmpl$160, %eax jne L2 Note since __m128i has the attribute of may_alias you have to do the load of the global pointer before the loop. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-10-08 20:18:35 date|| Summary|[4.4 Regression] Unnecessary|[4.4 Regression] Alignment |load instruction in a loop |information is lost for ||ARRAY_REFs Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37774
[Bug c/37772] ICE with empty asm statement
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-08 20:30 --- Confirmed, most likely caused by the new C parser. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.2.4 4.3.2 4.4.0 |4.2.4 4.3.2 4.4.0 4.1.1 Known to work||4.0.2 Last reconfirmed|-00-00 00:00:00 |2008-10-08 20:30:55 date|| Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37772
[Bug c++/37775] New: Templated private class visible through friend declaration
The following example compiles cleanly with g++, while I think the friend
declaration should be rejected, as the templated private class A::Inner
should not be visible except from within A.
#include iostream
class A {
public:
static int h();
private:
templatetypename T
struct Inner {
static int f();
};
};
class B {
friend class A::Innerint; // Should not be visible
static int g() { return 42; }
};
template
int A::Innerint::f()
{
return B::g();
}
int A::h()
{
return Innerint::f();
}
int main()
{
std::cout A::h() std::endl;
}
--
Summary: Templated private class visible through friend
declaration
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sam at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37775
[Bug middle-end/37774] [4.4 Regression] Alignment information is lost for ARRAY_REFs
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-08 20:51 --- Newer patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00350.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00350.html Status|NEW |ASSIGNED Last reconfirmed|2008-10-08 20:18:35 |2008-10-08 20:51:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37774
[Bug middle-end/37774] [4.4 Regression] Alignment information is lost for ARRAY_REFs
--- Comment #4 from hjl dot tools at gmail dot com 2008-10-08 20:55 --- (In reply to comment #3) Newer patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00350.html With this patch, I got .globl foo .type foo, @function foo: xorl%eax, %eax .p2align 4,,10 .p2align 3 .L2: pabsw src(%rax), %xmm0 movdqa %xmm0, resdst(%rax) addq$16, %rax cmpq$160, %rax jne .L2 rep ret The load is combined into pabsw. The extra load insn and unaligned move are gone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37774
[Bug target/37633] [4.4 Regression] wrong register use on sh64
--- Comment #2 from vmakarov at redhat dot com 2008-10-08 21:55 --- Thanks for working on the problem. I am afraid that preventing to use partially clobbered hard regs for allocnos living through calls is wrong. In most general case I believe the problem should be fixed in caller-saves.c: they should saved and restored around calls. As temporary workaround would be correct calculation of costs in IRA for partially clobbered hard regs (as it was done in global.c) in order to force IRA avoid the hard regs. But without fixing the problem in caller-saves.c IRA and the old RA are still error-prune for this problem in general case. I'll work on the patch for correct partially clobbered hard register calculation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug target/37769] internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-08 21:57 --- You are using an modified compiler from Redhat you should report it to them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37769
[Bug target/32277] indir-call-prof fails on ia64-linux-gnu
--- Comment #2 from schwab at suse dot de 2008-10-08 22:59 ---
This patch works for me:
Index: libgcov.c
===
--- libgcov.c (revision 140731)
+++ libgcov.c (working copy)
@@ -777,7 +777,11 @@ void
__gcov_indirect_call_profiler (gcov_type* counter, gcov_type value,
void* cur_func, void* callee_func)
{
+#ifdef __ia64__
+ if (callee_func *(void **) cur_func == *(void **) callee_func)
+#else
if (cur_func == callee_func)
+#endif
__gcov_one_value_profiler_body (counter, value);
}
#endif
--
schwab at suse dot de changed:
What|Removed |Added
CC||schwab at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32277
[Bug c++/37765] Printf of typed null pointer causes a run-time error
--- Comment #2 from hosoda-t at palette dot plala dot or dot jp 2008-10-08
23:02 ---
(In reply to comment #1)
%s requires a pointer to a string, which (char*)0 isn't.
%s is a c-style string.
try the code below, and please notice that the code works well on g++ 3.4.4 and
also on Microsoft Visual C++ 2005 without a run-time error.
#include cstdio
int main()
{
const char* p = This is a c-syle string.;
printf(%s\n, p);
char* q = 0;
printf(%s\n, q);
}
--
hosoda-t at palette dot plala dot or dot jp changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37765
[Bug c++/37765] Printf of typed null pointer causes a run-time error
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-08 23:05 --- printf (%s\n, NULL); is undefined. So GCC is optimizing the printf in this case to puts which creates smaller and faster code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37765
[Bug c/37776] New: ICE compiling Matrix.c in pymol using -fgraphite
When the -fgraphite flag is passed while compiling pymol (http://pymol.sourceforge.net), an ICE occurs for Matrix.c of the form... gcc-4 --save-temps -Wall -fgraphite -I../layer0 -I../layer1 -I../layer2 -I../layer3 -I../layer4 -I../layer5 -Wmissing-prototypes -Wno-long-double -O3 -funroll-loops -fomit-frame-pointer -ffast-math -I/sw/include -I/sw/include/python2.5 -I/sw/include/python2.5/Numeric -I/usr/X11R6/include -D_HAVE_LIBPNG -D_PYMOL_MODULE -D_PYMOL_NUMPY -D_PYMOL_FINK -I../ov/src -c -o Matrix.o Matrix.c Matrix.c: In function pymol_rg_: Matrix.c:3059: error: edge from 12 to 539 should be marked irreducible Matrix.c:3059: error: basic block 539 should be marked irreducible Matrix.c:3059: internal compiler error: in verify_loop_structure, at cfgloop.c:1569 -- Summary: ICE compiling Matrix.c in pymol using -fgraphite Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37776
[Bug c/37776] ICE compiling Matrix.c in pymol using -fgraphite
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-10-08 23:36 --- Created an attachment (id=16479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16479action=view) preprocessed source for Matrix.c from pymol -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37776
[Bug middle-end/37776] ICE compiling Matrix.c in pymol using -fgraphite
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-10-08 23:40 --- If this is really PR37485, can we get the fix from revision 140844 moved into gcc trunk? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37776
[Bug middle-end/37776] ICE compiling Matrix.c in pymol using -fgraphite
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-10-09 00:56 --- Applying r140844 to gcc trunk and rebuilding xgcc doesn't eliminate this ICE so this may be a different problem from PR37485. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37776
[Bug bootstrap/37777] New: error: 'ASM_SHORT' undeclared (first use in this function)
../../src/gcc/config/i386/i386.md: In function 'output_615': ../../src/gcc/config/i386/i386.md:21149: error: 'ASM_SHORT' undeclared (first use in this function) ../../src/gcc/config/i386/i386.md:21149: error: (Each undeclared identifier is reported only once ../../src/gcc/config/i386/i386.md:21149: error: for each function it appears in.) ../../src/gcc/config/i386/i386.md:21149: error: expected ';' before string constant ../../src/gcc/config/i386/i386.md:21150: warning: control reaches end of non-void function make[3]: *** [insn-output.o] Error 1 -- Summary: error: 'ASM_SHORT' undeclared (first use in this function) Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cnstar9988 at gmail dot com GCC build triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug target/37777] error: 'ASM_SHORT' undeclared (first use in this function)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-09 02:11 ---
Did you change config.gcc ?
It contains the following line:
tm_file=${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h svr4.h
i386/sysv4.h sol2.h
Which means i386/att.h should be included and therefor define ASM_SHORT.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug target/37777] error: 'ASM_SHORT' undeclared (first use in this function)
--- Comment #2 from cnstar9988 at gmail dot com 2008-10-09 02:14 ---
yes, I changed config.gcc, to workaround PR33100.
I want to build gcc 4.3.2 on solaris 10.
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 140759)
+++ gcc/config.gcc (working copy)
@@ -1205,7 +1205,10 @@ i[34567]86-*-solaris2*)
*-*-solaris2.1[0-9]*)
tm_file=${tm_file} i386/x86-64.h i386/sol2-10.h
tm_defines=${tm_defines} TARGET_BI_ARCH=1
- tmake_file=$tmake_file i386/t-crtstuff i386/t-sol2-10
+ tmake_file=$tmake_file i386/t-sol2-10
+ if test x$gnu_ld = xyes; then
+ tmake_file=$tmake_file i386/t-crtstuff
+ fi
need_64bit_hwint=yes
case X${with_cpu} in
Xgeneric|Xcore2|Xnocona|Xx86-64|Xamdfam10|Xbarcelona|Xk8|Xopteron|Xathlon64|Xathlon-fx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-10-09 02:40 --- The following simple patch fixes this. I will commit under the obvious and simple rule. (Obvious once you spend several hours studying it to see what is going wrong!) Index: io/list_read.c === --- io/list_read.c (revision 140900) +++ io/list_read.c (working copy) @@ -2839,6 +2839,9 @@ get_name: goto nml_err_ret; } + if (first_nl != NULL first_nl-var_rank 0) +nl = first_nl; + if (nml_read_obj (dtp, nl, 0, pprev_nl, nml_err_msg, nml_err_msg_size, clow, chigh) == FAILURE) goto nml_err_ret; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug c++/37765] Printf of typed null pointer causes a run-time error
--- Comment #4 from hosoda-t at palette dot plala dot or dot jp 2008-10-09 02:40 --- Thank you for your time. I am sure that you are right, because the Null pointer does not point to a string which must have the terminator '\0' at the end. However, please kindly adivise me if the folloing code also work on a undefined behavior or not. cout (char*)0; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37765
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-10-09 04:16 --- Subject: Bug 37707 Author: jvdelisle Date: Thu Oct 9 04:14:48 2008 New Revision: 140997 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140997 Log: 2008-10-08 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * gfortran.dg/namelist_54.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_54.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-10-09 04:04 --- Subject: Bug 37707 Author: jvdelisle Date: Thu Oct 9 04:02:35 2008 New Revision: 140995 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140995 Log: 2008-10-08 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37707 * io/list_read.c (nml_get_obj_data): If the first namelist object rank is greater than zero, call nml_object_read with the first object rather than the sub-object. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug target/37769] internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525
--- Comment #3 from kkojima at gcc dot gnu dot org 2008-10-09 04:46 --- Created an attachment (id=16480) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16480action=view) a reduced test case A reduced test case which ICEs with -funroll-loops -ffast-math -O2. It fails with 4.3/4.4 compilers and doesn't fail with 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37769
[Bug rtl-optimization/37769] internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525
--- Comment #4 from kkojima at gcc dot gnu dot org 2008-10-09 04:50 ---
The regmove pass changes insns in .160r.ce2 dump
(insn 285 77 78 6 foo.C:14 (set (reg/f:SI 260)
(reg/f:SI 269 [ ivtmp.66 ])) -1 (expr_list:REG_DEAD (reg/f:SI 269 [
ivtmp.66 ])
(nil)))
(insn 78 285 79 6 foo.C:14 (parallel [
(set (reg:SF 280)
(mem:SF (post_inc:SI (reg/f:SI 260)) [2 S4 A32]))
(use (reg/v:PSI 151 ))
(clobber (scratch:SI))
]) 205 {movsf_ie} (expr_list:REG_INC (reg/f:SI 260)
(nil)))
to
(insn:HI 285 77 78 6 foo.C:14 (set (reg/f:SI 269 [ ivtmp.66 ])
(reg/f:SI 269 [ ivtmp.66 ])) -1 (nil))
(insn:HI 78 285 79 6 foo.C:14 (parallel [
(set (reg:SF 280)
(mem:SF (post_inc:SI (reg/f:SI 269 [ ivtmp.66 ])) [2 S4 A32]))
(use (reg/v:PSI 151 ))
(clobber (scratch:SI))
]) 205 {movsf_ie} (expr_list:REG_INC (reg/f:SI 260)
(nil)))
in .162r.regmove.
It seems that regmove forgets to update the register 260 to 269
in REG_INC note of the insn 78 and this wrong REG_INC note causes
the ICE.
Now I'm testing the attached patch, for 4.3-branch.
BTW, please use the compiler based on the vanilla FSF tree
for bugzilla as Andrew has pointed out already.
--- ORIG/gcc-4_3-branch/gcc/regmove.c 2008-02-20 06:48:51.0 +0900
+++ LOCAL/gcc-4_3-branch/gcc/regmove.c 2008-10-09 10:50:29.0 +0900
@@ -687,6 +687,12 @@ optimize_reg_copy_2 (rtx insn, rtx dest,
if (reg_mentioned_p (dest, PATTERN (q)))
{
PATTERN (q) = replace_rtx (PATTERN (q), dest, src);
+ if (FIND_REG_INC_NOTE (q, dest))
+ {
+ remove_note (q, find_reg_note (q, REG_INC, dest));
+ REG_NOTES (q)
+ = gen_rtx_EXPR_LIST (REG_INC, src, REG_NOTES (q));
+ }
df_insn_rescan (q);
}
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever Confirmed|0 |1
GCC target triplet|sh4-*-linux |sh4-*-*
Keywords||ice-on-valid-code
Known to fail||4.3.2 4.4.0
Known to work||4.2.4
Priority|P3 |P4
Last reconfirmed|-00-00 00:00:00 |2008-10-09 04:50:48
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37769
