[Bug c++/40497] invalid std::next / std::prev declaration
--- Comment #20 from jason at gcc dot gnu dot org 2009-07-27 05:46 --- Actually, no. It seems that T being invalid doesn't result in a SFINAE situation. 14.9.2/8: Only invalid types and expressions in the immediate context of the function type and its template parameter types can result in a deduction failure. [ Note: The evaluation of the substituted types and expressions can result in side effects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-defined functions, etc. Such side effects are not in the immediate context and can result in the program being ill-formed. end note ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libgcj/40868] New: ecjx.cc should be compiled by host gcc
gcc version: 4.4.1 with gcc-4.4.1-branch_update-1.patch host system: Ubuntu 9.04 x86_64 configured by: ./configure --prefix=/usr --build=x86_64-linux-gnu \ --host=x86_64-linux-gnu \ --target=arm-none-linux-gnueabi --with-sysroot=$TOOLCHAIN_DIR \ --with-gmp=$STATIC_LIB_DIR --with-mpfr=$STATIC_LIB_DIR \ --disable-multilib --disable-nls --enable-shared \ --enable-__cxa_atexit --enable-c99 --enable-long-long \ --enable-threads=posix --enable-languages=c,c++,java \ --with-float=soft --with-cpu=arm926ej-s \ --enable-libgcj-bc --disable-sjlj-exceptions \ --with-ecj-jar=/source/ecj.jar compiled by: make AS_FOR_TARGET=arm-none-linux-gnueabi-as LD_FOR_TARGET=arm-none-linux-gnueabi-ld error message: architecture of input file `ecjx.o' is incompatible with i386:x86_64 output I solved this error message as follows: First chdir to 'arm-none-linux-gnueabi/libjava', then run 'gcc ecjx.cc -o ecjx.o' then run 'make AS_FOR_TARGET=arm-none-linux-gnueabi-as LD_FOR_TARGET=arm-none-linux-gnueabi-ld' and no more error happens, and the toolchain works without problem. This error is because ecjx.cc is compiled by arm-none-linux-gnueabi-gcc, not by gcc. I think that libjava/Makefile.in should be changed, as diff -Narup gcc-4.4.1.origin/libjava/Makefile.in gcc-4.4.1/libjava/Makefile.in --- gcc-4.4.1.origin/libjava/Makefile.in2009-07-22 15:43:59.0 +0800 +++ gcc-4.4.1/libjava/Makefile.in 2009-07-27 08:40:50.702375251 +0800 @@ -9739,6 +9739,9 @@ distclean-compile: @AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ @am__fastdepCC_FALSE@ $(LTCOMPILE) -c -o $@ $< +ecjx.o: + gcc -c -o $@ $< + .cc.o: @am__fastdepCXX_TRUE@ depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`; \ @am__fastdepCXX_TRUE@ if $(CXXCOMPILE) -MT $@ -MD -MP -MF "$$depbase.Tpo" -c -o $@ $<; \ -- Summary: ecjx.cc should be compiled by host gcc Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dsdsdds at 126 dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug c++/40497] invalid std::next / std::prev declaration
--- Comment #19 from jason at gcc dot gnu dot org 2009-07-27 01:08 --- That does seem like a SFINAE bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libgcj/40867] New: [4.5 Regression] FAIL: StackTrace2 output - source compiled test
Executing on host: /home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /home/dave/gnu/gcc/objdir/./gcc/gcj -B/home/dave/gnu/gcc/objdir/hppa-linux/libjava/ -B/home/dave/gnu/gcc/objdir/./gcc/ -B/ho me/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include--encoding=UTF-8 -B/home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/../ /home/dave/gnu/gcc/gcc/libjava/testsuite/libjava.lang/StackTrace2.jar -w -specs=libgcj-test.spec -no-install --main=StackTrace2 -g -L/home/dave/gnu/gcc/objdir/hppa-linux/./libjava/.libs -lm -o /home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/StackTrace2.exe (timeout = 300)PASS: StackTrace2 compilation from sourceset_ld_library_path_env_vars: ld_library_path=.:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc/objdir/gcc invoke: /home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/StackTrace2.exe Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc/objdir/gcc:.:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava /.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux/libstd c++-v3/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gccTrace length = 4StackTrace2$Inner.doCrash:FAIL - expected 33, got: 34, in file StackTrace2.javaStackTrace2$Inner.foo:OK StackTrace2.a:OK StackTrace2.main:OK PASS: StackTrace2 execution - source compiled test FAIL: StackTrace2 output - source compiled test Also, the following fail in the same way: FAIL: StackTrace2 -findirect-dispatch output - source compiled test FAIL: StackTrace2 -O3 output - source compiled test FAIL: StackTrace2 -O3 -findirect-dispatch output - source compiled test -- Summary: [4.5 Regression] FAIL: StackTrace2 output - source compiled test Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* (32 bit) GCC host triplet: hppa*-*-* (32 bit) GCC target triplet: hppa*-*-* (32 bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-07-26 22:09 --- Created an attachment (id=18257) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18257&action=view) Preprocessed sources of failing testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866
[Bug c++/40866] New: [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504
The code below used to compile fine. I'll also attach a preprocessed version as
it depends on Qt4.
$> cat ice.cpp
#include
class myDialog : public QDialog {
public:
myDialog();
};
myDialog::myDialog() {
foreach (QAction *action, actions()) {
}
}
$> g++-svn -g -Wall -I. -I/usr/include/qt4 -I/usr/include/qt4/QtGui -c ice.cpp
ice.cpp: In constructor 'myDialog::myDialog()':
ice.cpp:9:3: warning: unused variable 'action'
ice.cpp: In constructor 'myDialog::myDialog()':
ice.cpp:9:3: internal compiler error: in create_tmp_var, at gimplify.c:504
Please submit a full bug report
$> g++-svn -v
gcc version 4.5.0 20090725 (experimental) (GCC)
--
Summary: [4.5 Regression] ICE in create_tmp_var, at
gimplify.c:504
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866
[Bug objc/40864] Designated initializers for multi-dimensional arrays fail in Objective-C
--- Comment #1 from joseph at codesourcery dot com 2009-07-26 21:43 --- Subject: Re: New: Designated initializers for multi-dimensional arrays fail in Objective-C On Sun, 26 Jul 2009, sergei dot yakovlev at gmail dot com wrote: > Designated initializers for multi-dimensional arrays work great in C (C99), > but > fail in Objective-C (see example below). Given that Objective-C is proclaimed > a > strict superset of C, I consider this a bug. This was a property of the old C parser I carefully replicated when writing the new one. I do not know if there exists a C99-based specification of ObjC that clarifies what is intended (and note that this interacts with the old GNU form of designated initializers as well); I took it as given by the implementation at that time. /* ??? Following the old parser, [ objc-receiver objc-message-args ] is accepted as an initializer, being distinguished from a designator by what follows the first assignment expression inside the square brackets, but after a first array designator a subsequent square bracket is for Objective-C taken to start an expression, using the obsolete form of designated initializer without '=', rather than possibly being a second level of designation: in LALR terms, the '[' is shifted rather than reducing designator to designator-list. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40864
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-26 21:37 --- Subject: Re: [4.5 Regression] Build failure in libgfortran > (In reply to comment #7) > > (In reply to comment #6) > > > Can you try whether the following works (place somewhere in > > > intrinsics/c99_functions.c): > > > > Enhanced version with yet another version for I: > > > > #ifndef I > > # if defined(_Imaginary_I) > > # define I _Imaginary_I > > # elif defined(_Complex_I) > > # define I _Complex_I > > # else > > # define I (1.0fi) > > # endif > > #endif > > This compiles on Cygwin, when applied on top of your other patch. Same on hppa2.0w-hp-hpux11.11. There are no warnings. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-07-26 21:23 --- 3323 gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE 3324 || TYPE_CONTEXT (decl) == sym->ns->proc_name->backend_decl); 3325 gcc_assert (DECL_CONTEXT (TYPE_STUB_DECL (decl)) == NULL_TREE 3326 || DECL_CONTEXT (TYPE_STUB_DECL (decl)) 3327 == sym->ns->proc_name->backend_decl); if the second assert isn't bogus then both types (the one in the replica_type module and the imported one) have to have separate type-stub-decls (thus two debug information entries). Personally I think it is quite reasonable to use the replica_type modules debug info for the USE imported one, thus simply remove the 2nd assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-07-26 21:22 --- (In reply to comment #7) > (In reply to comment #6) > > Can you try whether the following works (place somewhere in > > intrinsics/c99_functions.c): > > Enhanced version with yet another version for I: > > #ifndef I > # if defined(_Imaginary_I) > # define I _Imaginary_I > # elif defined(_Complex_I) > # define I _Complex_I > # else > # define I (1.0fi) > # endif > #endif This compiles on Cygwin, when applied on top of your other patch. Good work! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug objc/40864] New: Designated initializers for multi-dimensional arrays fail in Objective-C
Designated initializers for multi-dimensional arrays work great in C (C99), but
fail in Objective-C (see example below). Given that Objective-C is proclaimed a
strict superset of C, I consider this a bug.
$ gcc -x c - <<<"int main(){ int a[3][4] = {[1][2] = 5}; }"
$ gcc -x objective-c - <<<"int main(){ int a[3][4] = {[1][2] = 5}; }"
: In function 'main':
:1: error: syntax error before ']' token
$
--
Summary: Designated initializers for multi-dimensional arrays
fail in Objective-C
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei dot yakovlev at gmail dot com
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40864
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #19 from davek at gcc dot gnu dot org 2009-07-26 20:57 --- (In reply to comment #18) > No, the support that was implemented is that the suffix of gnatmake > is the one that gcc gets suffixed with. Ah ok, I see. Then it's working as designed. Sorry for the noise in your inbox.Judging from the way your patch only changes the names at install time, I expect that if I manually rename the files after they've been installed, they'll also notice their new suffixes and it should all work ok. Bug reclosed. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #18 from rguenther at suse dot de 2009-07-26 20:44 --- Subject: Re: --program-suffix is ignored (for ada) On Sun, 26 Jul 2009, davek at gcc dot gnu dot org wrote: > --- Comment #17 from davek at gcc dot gnu dot org 2009-07-26 20:39 > --- > (In reply to comment #15) > > Right, my change fixed gnatmake so that it would call the proper gcc (based > > on > > the > > previous comments on this PR), but Makefiles have never supported > > --program-suffix, so that's not even a regression. > > Uh, you both focussed on the line where I mentioned in passing that the gnat > executables don't get suffixed, and missed the actual bug report: it does > *not* > call the proper GCC. Regardless of whether gnatmake itself gets a suffix or > not, it should have invoked "gcc-4", not "gcc", shouldn't it? No, the support that was implemented is that the suffix of gnatmake is the one that gcc gets suffixed with. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #17 from davek at gcc dot gnu dot org 2009-07-26 20:39 --- (In reply to comment #15) > Right, my change fixed gnatmake so that it would call the proper gcc (based on > the > previous comments on this PR), but Makefiles have never supported > --program-suffix, so that's not even a regression. Uh, you both focussed on the line where I mentioned in passing that the gnat executables don't get suffixed, and missed the actual bug report: it does *not* call the proper GCC. Regardless of whether gnatmake itself gets a suffix or not, it should have invoked "gcc-4", not "gcc", shouldn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-07-26 20:37 --- Created an attachment (id=18256) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18256&action=view) patch FYI this is what SUSE carries along. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #29 from giffordj at la dot twcbc dot com 2009-07-26 20:28 --- STAGE1_CFLAGS="-g -O2" is a workaround, -O1 gave failure later in the build. -O2 built GCC all the way through, with only one unexpected testsuite failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #15 from charlet at gcc dot gnu dot org 2009-07-26 20:33 --- Right, my change fixed gnatmake so that it would call the proper gcc (based on the previous comments on this PR), but Makefiles have never supported --program-suffix, so that's not even a regression. Feel free to submit a patch, I think it would be fair for someone with an interest in this feature to do so, since Ada maintainers have no specific interest in this option, and this is really a Makefile/infrastructure issue at this stage rather than an Ada issue (I did fix the Ada specific issue reported in gnatmake, and this feature is still working AFAIK). -- charlet at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|charlet at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|REOPENED|NEW Target Milestone|4.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #7 from burnus at gcc dot gnu dot org 2009-07-26 20:32 --- (In reply to comment #6) > Can you try whether the following works (place somewhere in > intrinsics/c99_functions.c): Enhanced version with yet another version for I: #ifndef I # if defined(_Imaginary_I) # define I _Imaginary_I # elif defined(_Complex_I) # define I _Complex_I # else # define I (1.0fi) # endif #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug c/40862] ICE in simplify_subreg, at simplify-rtx.c:4981
--- Comment #2 from regehr at cs dot utah dot edu 2009-07-26 20:30 --- Argh sorry... a search on "simplify_subreg" appeared to return no matches but perhaps I had a typo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40862
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-26 20:28 --- (In reply to comment #4) > The prototype warnings have been there foreever. They should be fixed with the patch ... Do they still appear? > On hpux, the error > appears as a result of your change: > ../../../gcc/libgfortran/intrinsics/c99_functions.c: In function 'casin': > ../../../gcc/libgfortran/intrinsics/c99_functions.c:1433:11: error: 'I' > undeclared (first use in this function) Hmm. Do you know how the macro is called which provides "I", where I*I = -1? On a POSIX/C99 system one has: The header shall define the following macros: complex Expands to _Complex. _Complex_I Expands to a constant expression of type const float _Complex, with the value of the imaginary unit (that is, a number i such that i**2=-1). imaginary Expands to _Imaginary. _Imaginary_I Expands to a constant expression of type const float _Imaginary with the value of the imaginary unit. I Expands to either _Imaginary_I or _Complex_I. If _Imaginary_I is not defined, I expands to _Complex_I. Which of those macros are defined on hppa2.0w-hp-hpux11.11 and on Cygwin ? Seemingly not the last one ... Can you try whether the following works (place somewhere in intrinsics/c99_functions.c): #ifndef I # if defined(_Imaginary_I) # define I _Imaginary_I # elif defined(_Complex_I) # define I _Complex_I # endif #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-26 20:11 --- Subject: Re: [4.5 Regression] Build failure in libgfortran On Sun, 26 Jul 2009, John David Anglin wrote: > > Patch. As I cannot test all the combinations, I would be happy if someone > > could > > test it or read the patch. (I will reread it and also do some testing, but > > by > > default I am not affect by this bug.) > > Will do. With the patch, I see the same errors and warnings on hppa2.0w-hp-hpux11.11 as reported for cygwin in comment #3. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-07-26 19:53 --- > None of the newly built gnat* executables had the --program-suffix appended. that never happened. Distros carry patches for this since ages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug rtl-optimization/40861] [4.5 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-26 19:15 --- *** Bug 40862 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
[Bug c/40862] ICE in simplify_subreg, at simplify-rtx.c:4981
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-26 19:15 --- *** This bug has been marked as a duplicate of 40861 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40862
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-26 19:09 --- Subject: Re: [4.5 Regression] Build failure in libgfortran > Patch. As I cannot test all the combinations, I would be happy if someone > could > test it or read the patch. (I will reread it and also do some testing, but by > default I am not affect by this bug.) Will do. > The problem is that the C99 fall back functions are defined in c99_proto.h, > but > it is not included in intrinsics/c99*.c. Thus there is no prototype and due to > the -W* settings, there is an error. > > I do not quite understand why this has not come up before. Only about 10% of > the functions had prototypes - presumably the other 90% of the fall backs are > not used... The prototype warnings have been there foreever. On hpux, the error appears as a result of your change: ../../../gcc/libgfortran/intrinsics/c99_functions.c: In function 'casin': ../../../gcc/libgfortran/intrinsics/c99_functions.c:1433:11: error: 'I' undeclared (first use in this function) Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-07-26 18:50 --- (In reply to comment #2) Still fails for me on Cygwin with libtool: compile: /home/Thomas/trunk-bin/./gcc/xgcc -B/home/Thomas/trunk-bin/./ gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I../../../trunk/libgfortran -I. -iquote../../../trunk/libg fortran/io -I../../../trunk/libgfortran/../gcc -I../../../trunk/libgfortran/../g cc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmis sing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rule s -ffunction-sections -fdata-sections -g -O2 -MT c99_functions.lo -MD -MP -MF .d eps/c99_functions.Tpo -c ../../../trunk/libgfortran/intrinsics/c99_functions.c -DDLL_EXPORT -DPIC -o .libs/c99_functions.o ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'casinf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1573:11: error: 'I' undecl ared (first use in this function) ../../../trunk/libgfortran/intrinsics/c99_functions.c:1573:11: error: (Each unde clared identifier is reported only once ../../../trunk/libgfortran/intrinsics/c99_functions.c:1573:11: error: for each f unction it appears in.) ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'casin': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1585:11: error: 'I' undecl ared (first use in this function) ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'cacosf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1612:11: error: 'I' undecl ared (first use in this function) ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'cacos': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1624:11: error: 'I' undecl ared (first use in this function) ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'catanf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1651:10: error: 'I' undecl ared (first use in this function) ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'catan': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1663:10: error: 'I' undecl ared (first use in this function) ../../../trunk/libgfortran/intrinsics/c99_functions.c:1664:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'catanf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1652:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'cacos': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1625:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'cacosf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1613:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'casin': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1586:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'casinf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1574:1: warning: control r eaches end of non-void function make[3]: *** [c99_functions.lo] Error 1 make[3]: Leaving directory `/home/Thomas/trunk-bin/i686-pc-cygwin/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/Thomas/trunk-bin/i686-pc-cygwin/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/Thomas/trunk-bin' make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-26 18:42 --- Created an attachment (id=18255) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18255&action=view) Draft patch Patch. As I cannot test all the combinations, I would be happy if someone could test it or read the patch. (I will reread it and also do some testing, but by default I am not affect by this bug.) The problem is that the C99 fall back functions are defined in c99_proto.h, but it is not included in intrinsics/c99*.c. Thus there is no prototype and due to the -W* settings, there is an error. I do not quite understand why this has not come up before. Only about 10% of the functions had prototypes - presumably the other 90% of the fall backs are not used... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #1 from danglin at gcc dot gnu dot org 2009-07-26 17:40 --- On hppa2.0w-hp-hpux11.11, libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.5.0/hp pa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/i nclude -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_ CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io - I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../. ././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT c99 _functions.lo -MD -MP -MF .deps/c99_functions.Tpo -c ../../../gcc/libgfortran/in trinsics/c99_functions.c -fPIC -DPIC -o .libs/c99_functions.o ../../../gcc/libgfortran/intrinsics/c99_functions.c:177:1: warning: no previous prototype for 'acoshf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:194:1: warning: no previous prototype for 'asinhf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:220:1: warning: no previous prototype for 'atanhf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:229:1: warning: no previous prototype for 'ceilf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:283:1: warning: no previous prototype for 'floorf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:301:1: warning: no previous prototype for 'frexpf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:310:1: warning: no previous prototype for 'hypotf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:350:1: warning: no previous prototype for 'scalbnf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:419:1: warning: no previous prototype for 'truncf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:536:1: warning: no previous prototype for 'roundl' ../../../gcc/libgfortran/intrinsics/c99_functions.c:590:1: warning: no previous prototype for 'roundf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:619:1: warning: no previous prototype for 'lroundf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:637:1: warning: no previous prototype for 'lroundl' ../../../gcc/libgfortran/intrinsics/c99_functions.c:646:1: warning: no previous prototype for 'llroundf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:664:1: warning: no previous prototype for 'llroundl' ../../../gcc/libgfortran/intrinsics/c99_functions.c:676:1: warning: no previous prototype for 'log10l' ../../../gcc/libgfortran/intrinsics/c99_functions.c:714:1: warning: no previous prototype for 'floorl' ../../../gcc/libgfortran/intrinsics/c99_functions.c:740:1: warning: no previous prototype for 'fmodl' ../../../gcc/libgfortran/intrinsics/c99_functions.c:812:1: warning: no previous prototype for 'cexpf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:827:1: warning: no previous prototype for 'cexp' ../../../gcc/libgfortran/intrinsics/c99_functions.c:859:1: warning: no previous prototype for 'clogf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:871:1: warning: no previous prototype for 'clog' ../../../gcc/libgfortran/intrinsics/c99_functions.c:935:1: warning: no previous prototype for 'cpowf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:944:1: warning: no previous prototype for 'cpow' ../../../gcc/libgfortran/intrinsics/c99_functions.c:964:1: warning: no previous prototype for 'csqrtf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1017:1: warning: no previous prototype for 'csqrt' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1125:1: warning: no previous prototype for 'csinhf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1140:1: warning: no previous prototype for 'csinh' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1172:1: warning: no previous prototype for 'ccoshf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1187:1: warning: no previous prototype for 'ccosh' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1219:1: warning: no previous prototype for 'ctanhf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1236:1: warning: no previous prototype for 'ctanh' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1272:1: warning: no previous prototype for 'csinf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1287:1: warning: no previous prototype for 'csin' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1319:1: warning: no previous prototype for 'ccosf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1334:1: warning: no previous prototype for 'ccos' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1366:1: warning: no previous prototype for 'ctanf' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1383:1: warning: no previous prototype for 'ctan' ../../../gcc/libgfortran/intrinsics/c99_functions.c:1421:1: warning: no previous prototype for 'casinf' ../../../gcc/libgfortran/intrinsics/c99_func
[Bug middle-end/30789] complex folding inexact
--- Comment #2 from joseph at codesourcery dot com 2009-07-26 17:32 ---
Subject: Re: complex folding inexact
The example in this bug deals with excess overflow for division. For
infinities computing as NaN + iNaN, an example is (NaN + iInf) * (NaN
+iInf) (where NaN +iInf is obtained as (__builtin_inf () * (0.0 + 1.0i)))
- this works if computed at runtime but not constant folded. ("Works"
here means that at least one part of the result is an infinity - I do not
believe there is a specific requirement beyond that.)
For division producing NaN + iNaN, (1.0 + 0.0i) / (0.0 + 0.0i) should
produce an infinity, (__builtin_inf () * (0.0 + 1.0i)) / (1.0 + 0.0i)
should produce an infinity, (1.0 + 0.0i) / (__builtin_inf () * (0.0 +
1.0i)) should produce a zero (in which each part may have either sign).
All the above can usefully be tested for both constant folding and runtime
evaluation.
There are also cases for exact rounding where you'd expect MPC to produce
the right results but would *not* expect operations executed at runtime to
produce exactly those results. For example, (1.0 + DBL_EPSILON + 1.0i) *
(1.0 - DBL_EPSILON + 1.0i), which would only work at runtime if the code
happens to use exactly the right fused multiply-add operation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #31 from burnus at gcc dot gnu dot org 2009-07-26 17:26 --- Subject: Bug 33197 Author: burnus Date: Sun Jul 26 17:25:56 2009 New Revision: 150100 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150100 Log: 2009-07-26 Tobias Burnus PR fortran/33197 * intrinsic.c (make_generic): Remove assert as "atan" can be both ISYM_ATAN and ISYM_ATAN2. (add_functions): Add two-argument variant of ATAN. * intrinsic.h (gfc_check_atan_2): Add check for it. * intrinsic.texi (ATAN2): Correct and enhance description. (ATAN): Describe two-argument variant of ATAN. 2009-07-26 Tobias Burnus PR fortran/33197 * gfortran.dg/atan2_1.f90: New test * gfortran.dg/atan2_2.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/atan2_1.f90 trunk/gcc/testsuite/gfortran.dg/atan2_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug libfortran/40863] New: [4.5 Regression] Build failure in libgfortran
Just ran into this. A forgotten commit, maybe? ../../../trunk/libgfortran/intrinsics/c99_functions.c: At top level: ../../../trunk/libgfortran/intrinsics/c99_functions.c:1520:1: warning: no previo us prototype for 'casinhf' ../../../trunk/libgfortran/intrinsics/c99_functions.c:1530:1: warning: no previo us prototype for 'casinh' ../../../trunk/libgfortran/intrinsics/c99_functions.c:1553:1: warning: no previo us prototype for 'cacoshf' ../../../trunk/libgfortran/intrinsics/c99_functions.c:1563:1: warning: no previo us prototype for 'cacosh' ../../../trunk/libgfortran/intrinsics/c99_functions.c:1586:1: warning: no previo us prototype for 'catanhf' ../../../trunk/libgfortran/intrinsics/c99_functions.c:1596:1: warning: no previo us prototype for 'catanh' ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'catan': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1500:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'catanf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1490:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'cacos': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1467:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'cacosf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1457:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'casin': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1434:1: warning: control r eaches end of non-void function ../../../trunk/libgfortran/intrinsics/c99_functions.c: In function 'casinf': ../../../trunk/libgfortran/intrinsics/c99_functions.c:1424:1: warning: control r eaches end of non-void function make[3]: *** [c99_functions.lo] Error 1 make[3]: Leaving directory `/home/Thomas/trunk-bin/i686-pc-cygwin/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/Thomas/trunk-bin/i686-pc-cygwin/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/Thomas/trunk-bin' make: *** [bootstrap] Error 2 -- Summary: [4.5 Regression] Build failure in libgfortran Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug c++/40749] [4.3 Regression] g++ doesnt report missing return if return is of type const
--- Comment #6 from simartin at gcc dot gnu dot org 2009-07-26 16:11 --- Fixed in 4.5 and 4.4. I don't plan to commit this to 4.3. -- simartin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|simartin at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|4.3.3 4.4.0 4.5.0 |4.3.3 4.4.0 Known to work|4.2.4 |4.2.4 4.4.2 4.5.0 Summary|[4.3/4.4/4.5 Regression] g++|[4.3 Regression] g++ doesnt |doesnt report missing return|report missing return if |if return is of type const |return is of type const | | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40749
[Bug c++/40749] [4.3/4.4/4.5 Regression] g++ doesnt report missing return if return is of type const
--- Comment #5 from simartin at gcc dot gnu dot org 2009-07-26 16:05 --- Subject: Bug 40749 Author: simartin Date: Sun Jul 26 16:05:22 2009 New Revision: 150099 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150099 Log: gcc/cp/ 2009-07-26 Simon Martin PR c++/40749 * decl.c (grokdeclarator): Do not set TREE_NO_WARNING for functions with a qualified return type. gcc/testsuite/ 2007-07-26 Simon Martin PR c++/40749 * g++.dg/warn/Wreturn-type-6.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/warn/Wreturn-type-6.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/decl.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40749
[Bug c++/40497] invalid std::next / std::prev declaration
--- Comment #18 from paolo dot carlini at oracle dot com 2009-07-26 15:45 --- Never mind the draft next, of course doesn't work, grunt (_Distance?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug c/40862] New: ICE in simplify_subreg, at simplify-rtx.c:4981
Seen on Ubuntu Hardy.
reg...@john-home:~/volatile/tmp179$ current-gcc -O3 -c small.c
small.c: In function box:
small.c:29:3: warning: overflow in implicit constant conversion
small.c:31:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4981
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
reg...@john-home:~/volatile/tmp179$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r150096-install
--program-prefix=r150096- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090726 (experimental) (GCC)
reg...@john-home:~/volatile/tmp179$ cat small.c
int foo (int _left, int _right)
{
return 1 >= 1 * 8 || 9223372036854775807LL >> _right ? : 0;
}
signed char bar (signed char _ui1, signed char _ui2)
{
return _ui1;
}
signed char baz (int _ui1, signed char _ui2)
{
return _ui1 * _ui2;
}
volatile signed char g_35;
int func_16 (int p_17, signed char p_19)
{
if (foo (1, bar (p_17, 1)))
if (g_35)
{
}
return 0;
}
void box (signed char p_13, signed char p_14)
{
signed char l_133 = 0xF5C80580;
func_16 (baz (l_133, g_35), 1);
}
--
Summary: ICE in simplify_subreg, at simplify-rtx.c:4981
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40862
[Bug rtl-optimization/40861] [4.5 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Keywords||ice-on-valid-code Summary|ICE in simplify_subreg, at |[4.5 Regression] ICE in |simplify-rtx.c:4981 |simplify_subreg, at ||simplify-rtx.c:4981 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
[Bug c/40861] New: ICE in simplify_subreg, at simplify-rtx.c:4981
Seen on Ubuntu Hardy.
reg...@john-home:~/volatile/tmp179$ current-gcc -O3 -c small.c
small.c: In function box:
small.c:29:3: warning: overflow in implicit constant conversion
small.c:31:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4981
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
reg...@john-home:~/volatile/tmp179$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r150096-install
--program-prefix=r150096- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090726 (experimental) (GCC)
reg...@john-home:~/volatile/tmp179$ cat small.c
int foo (int _left, int _right)
{
return 1 >= 1 * 8 || 9223372036854775807LL >> _right ? : 0;
}
signed char bar (signed char _ui1, signed char _ui2)
{
return _ui1;
}
signed char baz (int _ui1, signed char _ui2)
{
return _ui1 * _ui2;
}
volatile signed char g_35;
int func_16 (int p_17, signed char p_19)
{
if (foo (1, bar (p_17, 1)))
if (g_35)
{
}
return 0;
}
void box (signed char p_13, signed char p_14)
{
signed char l_133 = 0xF5C80580;
func_16 (baz (l_133, g_35), 1);
}
--
Summary: ICE in simplify_subreg, at simplify-rtx.c:4981
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #9 from davek at gcc dot gnu dot org 2009-07-26 15:13 --- All done now. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #8 from davek at gcc dot gnu dot org 2009-07-26 15:09 --- Subject: Bug 40578 Author: davek Date: Sun Jul 26 15:09:10 2009 New Revision: 150098 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150098 Log: PR bootstrap/40578 * adaint.h (FOPEN, STAT, FSTAT, LSTAT, STRUCT_STAT): Rename from these (GNAT_FOPEN, GNAT_STAT, GNAT_FSTAT, GNAT_LSTAT, GNAT_STRUCT_STAT): ... to these. (__gnat_stat): Adjust reference to STAT in prototype. * adaint.c (__gnat_try_lock, __gnat_fopen, __gnat_file_length, __gnat_named_file_length, __gnat_file_time_name, __gnat_file_time_fd, __gnat_get_libraries_from_registry, __gnat_stat, __gnat_file_exists, __gnat_is_regular_file, __gnat_is_directory, __gnat_is_readable_file, __gnat_is_writable_file, __gnat_is_executable_file, __gnat_set_writable, __gnat_set_executable, __gnat_set_non_writable, __gnat_set_readable, __gnat_set_non_readable, __gnat_is_symbolic_link, __gnat_copy_attribs): Adjust all references to the above. * cstreams.c (__gnat_is_regular_file_fd): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/adaint.c trunk/gcc/ada/adaint.h trunk/gcc/ada/cstreams.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug c++/40497] invalid std::next / std::prev declaration
--- Comment #17 from paolo dot carlini at oracle dot com 2009-07-26 14:46
---
Maybe Jason can help confirming that we don't have a C++ issue here?!? In that
case, however, since Concepts are gone, I think we should probably file a
library DR or raise the issue vs the rolled-back Draft. Opinions about that?
Anyway, something consistent with the C++03 advance, would be probably ok, in a
non-Concepts context:
template
inline _InputIterator
next(_InputIterator __x, _Distance __n = 1)
{
std::advance(__x, __n);
return __x;
}
I'm thinking of changing the libstdc++ code like this, for now, instead of
removing it completely to be safe.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #13 from davek at gcc dot gnu dot org 2009-07-26 14:26 --- Broken again on HEAD :-( Configured with --program-suffix=-4, bootstrapped, and installed into a new $prefix that I then placed at the front of $PATH. None of the newly built gnat* executables had the --program-suffix appended. When trying to run the testsuite, host_gnatmake invokes plain unadorned 'gnatmake', which finds the newly-installed one in $prefix. That attempts to invoke plain unadorned 'gcc' unfortunately, which is the distro compiler installed in /usr/bin, and not the newly installed $prefix/bin/gcc-4, resulting in the following error: > + host_gnatmake -gnatws macrosub.adb > > GNATMAKE 4.5.0 20090707 (experimental) > Copyright (C) 1995-2009, Free Software Foundation, Inc. > "macrosub.ali" being checked ... > -> "macrosub.ali" missing. > gcc -c -gnatV -gnatws macrosub.adb > gnat1: invalid switch: -gnatea > End of compilation I tried hacking host_gnatmake and host_gnatchop to pass --GCC=gcc-4, but that only got me a little way further: > + host_gnatmake -gnatws macrosub.adb > > GNATMAKE 4.5.0 20090707 (experimental) > Copyright (C) 1995-2009, Free Software Foundation, Inc. > "macrosub.ali" being checked ... > -> "macrosub.ali" missing. > gcc-4 -c -gnatws macrosub.adb > "defs.ali" being checked ... > -> "defs.ali" missing. > gcc-4 -c -gnatws defs.ads > "getsubs.ali" being checked ... > -> "getsubs.ali" missing. > gcc-4 -c -gnatws getsubs.adb > "parsemac.ali" being checked ... > -> "parsemac.ali" missing. > gcc-4 -c -gnatws parsemac.adb > "text_io.ali" is a read-only library > End of compilation > gnatbind -x macrosub.ali > gnatlink macrosub.ali > b~macrosub.o:b~macrosub.adb:(.eh_frame+0x11): undefined reference to > `___gnat_eh > _personality' > collect2: ld returned 1 exit status > gnatlink: error when calling /usr/bin/gcc.exe > gnatmake: *** link failed. ... the problem being that yet again the unsuffixed system compiler has been invoked, and it's using the system runtime libs rather than the ones that go with the newly-built compiler in $prefix (and which happen to be ABI incompatible because they use ZCX instead of SJLJ). Should gnatmake have passed down the --GCC= option to gnatbind and gnatlink? -- davek at gcc dot gnu dot org changed: What|Removed |Added CC|dave dot korn dot cygwin at |davek at gcc dot gnu dot org |gmail dot com | Status|RESOLVED|REOPENED Resolution|FIXED | Version|2.95.2 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug libgcj/40859] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #1 from mikpe at it dot uu dot se 2009-07-26 12:54 --- Looks like fallout from revision 144323. As far as I can tell the "warning" is informational (ABI change from 4.3) so should be suppressed or ignored in the test suite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40859
[Bug ada/39061] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
--- Comment #5 from ubizjak at gmail dot com 2009-07-26 11:07 --- (In reply to comment #4) > With -mieee they indeed pass. > > Was the default changed for 4.4? No, but code generation is different, just use -mieee. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug rtl-optimization/27467] -fsee introduces spurious movs
--- Comment #5 from ubizjak at gmail dot com 2009-07-26 11:01 --- -fsee was removed some time ago by: 2009-06-18 Sergei Dyshel * see.c: Remove. * Makefile.in (OBJS-common): Remove see.o. (see.o): Remove. * common.opt (fsee): Mark as preserved for backward compatibility. * opts.c (common_handle_option): Add OPT_fsee to the backward compatibility section. * passes.c (init_optimization_passes, pass_see): Remove pass. * timevar.def (TV_SEE): Remove. * tree-pass.h (pass_see): Remove declaration. * doc/invoke.texi (-fsee): Remove documentation. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27467
[Bug libgcj/40860] New: [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
seen with 4.4.1 and trunk, 4.4.1 cannot be used anymore to bootstrap OpenJDK: Matthias Executing on host: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/gcj -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/ --encoding=UTF-8 -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../ /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/libjava.lang/StackTrace2.jar -w -specs=libgcj-test.spec -no-install --main=StackTrace2 -g -L/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs -lm -o /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/StackTrace2.exe (timeout = 600) PASS: StackTrace2 compilation from source set_ld_library_path_env_vars: ld_library_path=.:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc invoke: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/StackTrace2.exe Setting LD_LIBRARY_PATH to .:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc:.:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc Trace length = 9 FAIL - expected StackTrace2$Inner, got: java.lang.Throwable.FAIL - expected doCrash, got: :FAIL - expected 33, got: 161, in file Throwable.java FAIL - expected StackTrace2$Inner, got: java.lang.Throwable.FAIL - expected foo, got: :FAIL - expected 28, got: 149, in file Throwable.java FAIL - expected StackTrace2, got: java.lang.Throwable.FAIL - expected a, got: :FAIL - expected 21, got: 66, in file Exception.java FAIL - expected StackTrace2, got: java.lang.Throwable.FAIL - expected main, got: :FAIL - expected 10, got: 64, in file RuntimeException.java PASS: StackTrace2 execution - source compiled test FAIL: StackTrace2 output - source compiled test Executing on host: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/gcj -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/ --encoding=UTF-8 -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../ /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/libjava.lang/Throw_2.jar -w -specs=libgcj-test.spec -no-install --main=Throw_2 -g -L/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs -lm -o /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/Throw_2.exe (timeout = 600) PASS: Throw_2 compilation from source set_ld_library_path_env_vars: ld_library_path=.:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc invoke: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/Throw_2.exe Setting LD_LIBRARY_PATH to .:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc:.:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc 1 FAIL: Throw_2 execution - source compiled test UNTESTED: Throw_2 output - source compiled test Executing on host: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/gcj -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/ --encoding=UTF-8 -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../ /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/libjava.lang/Throw_3.jar -w -specs=libgcj-test.spec -no-install --main=Throw_3 -g -L/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs -lm -o /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/Throw_3.exe (timeout = 600) PASS: Throw_3 compilation from source set_ld_library_path_env_vars: ld_library_path=.:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc invoke: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/Throw_3.exe Setting LD_LIBRARY_PATH to .:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc:.:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/./libjava/.libs:/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc bad PASS: Throw_3 execution - source compiled test FAIL: Throw_3 output - source compiled test Executing on host: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/gcj -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/ --encoding=UTF-8 -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../ /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/l
[Bug libgcj/40859] New: [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
seen with 4.4.1: Executing on host: /home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/xgcc -B/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/gcc/ -g -I. -I.. -fdollars-in-identifiers -I/home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/.. -I/home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/../include -I/home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/../classpath/include -I/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../include -I/home/doko/gcc/4.4/gcj-4.4-4.4.1/build/arm-linux-gnueabi/libjava/testsuite/../../boehm-gc/include -c -o natevents.o /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/libjava.jvmti/natevents.cc (timeout = 600) In file included from /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/../classpath/include/jvmti.h:46, from /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/libjava.jvmti/natevents.cc:4: /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/../classpath/include/jni.h:660: note: the mangling of 'va_list' has changed in GCC 4.4 output is: In file included from /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/../classpath/include/jvmti.h:46, from /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/libjava.jvmti/natevents.cc:4: /home/doko/gcc/4.4/gcj-4.4-4.4.1/src/libjava/testsuite/../classpath/include/jni.h:660: note: the mangling of 'va_list' has changed in GCC 4.4 FAIL: natevents.cc compilation and some more -- Summary: [4.4/4.5 regression] regressions in libjava testsuite on arm-linux Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40859
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #52 from arekm at pld-linux dot org 2009-07-26 10:38 --- btw. this patch backported to gcc 4.4 [1] causes build problems with -g flags like: https://svn.boost.org/trac/boost/ticket/3287 I just tested gcc trunk and the problem is the same. How to test? On linux x86_64 (it's 4MB preprocessed source so won't work on other architectures) do: wget http://carme.pld-linux.org/~arekm/gcc-pr14912.cxx [ar...@carme-pld ~]$ ~/gcc-test/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/home/users/arekm/gcc-test --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20090726 (experimental) (GCC) [ar...@carme-pld ~]$ ~/gcc-test/bin/g++ -c gcc-pr14912.cxx /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp: In constructor âPluginRegistry::PluginRegistry()â: /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:157:172: internal compiler error: in create_tmp_var, at gimplify.c:504 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. zsh: exit 1 ~/gcc-test/bin/g++ -c gcc-pr14912.cxx So looks ok (beside internal compiler error which is not interesting for us in this case). But now look what happens if -g2 is used: [ar...@carme-pld ~]$ ~/gcc-test/bin/g++ -g2 -c gcc-pr14912.cxx In file included from /usr/include/boost/graph/adjacency_list.hpp:39:0, from /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:39: /usr/include/boost/graph/graph_traits.hpp: In instantiation of âboost::graph_traits >â: /usr/include/boost/graph/adjacency_iterator.hpp:53:3: instantiated from âboost::adjacency_iterator_generator, long unsigned int, boost::detail::out_edge_iter<__gnu_cxx::__normal_iterator*, std::vector > >, long unsigned int, boost::detail::edge_desc_impl, long int> >â /usr/include/boost/graph/detail/adjacency_list.hpp:2346:56: instantiated from âboost::detail::adj_list_gen, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::configâ /usr/include/boost/graph/detail/adjacency_list.hpp:516:7: instantiated from âboost::directed_edges_helper, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::config>â /usr/include/boost/graph/detail/adjacency_list.hpp:568:46: instantiated from âboost::directed_graph_helper, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::config>â /usr/include/boost/graph/detail/adjacency_list.hpp:1489:5: instantiated from âboost::adj_list_helper, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::config, boost::directed_graph_helper, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::config> >â /usr/include/boost/graph/detail/adjacency_list.hpp:2069:5: instantiated from âboost::vec_adj_list_impl, boost::detail::adj_list_gen, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::config, boost::directed_graph_helper, boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>::config> >â /usr/include/boost/graph/adjacency_list.hpp:380:3: instantiated from âboost::adjacency_list<>â /home/users/arekm/rpm/BUILD/kdepimlibs-4.2.98/akonadi/itemserializer.cpp:184:38: instantiated from here /usr/include/boost/graph/graph_traits.hpp:29:47: error: no type named âvertex_descriptorâ in âclass boost::adjacency_list<>â /usr/include/boost/graph/graph_traits.hpp:30:45: error: no type named âedge_descriptorâ in âclass boost::adjacency_list<>â /usr/include/boost/graph/graph_traits.hpp:31:48: error: no type named âadjacency_iteratorâ in âclass boost::adjacency_list<>â /usr/include/boost/graph/graph_traits.hpp:32:47: error: no type named âout_edge_iteratorâ in âclass boost::adjacency_list<>â /usr/include/boost/graph/graph_traits.hpp:33:46: error: no type named âin_edge_iteratorâ in âclass boost::adjacency_list<>â /usr/include/boost/graph/graph_traits.hpp:34:45: error: no type named âvertex_iteratorâ in âclass boost::adjacency_list<>â /usr/include/boost/graph/graph_traits.hpp:35:43: error: no type name
[Bug bootstrap/40788] [4.5 regression] ICE : tree check: expected class 'expression', have 'declaration' (var_decl) in gimplify_va_arg_expr, at builtins.c:5107
--- Comment #2 from doko at ubuntu dot com 2009-07-26 10:37 --- seen on sparc-linux-gnu as well Matthias -- doko at ubuntu dot com changed: What|Removed |Added CC||doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40788
[Bug target/40577] ICE on valid code: in extract_insn
--- Comment #3 from ubizjak at gmail dot com 2009-07-26 10:11 --- Created an attachment (id=18254) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18254&action=view) patch to fix the failure This patch fixes the failure on x86_64 -> alpha crosscompiler. Since gcc30 of compile farm fame apparently lost its bluesmoke, can someone bootstrap and regression test it on alpha? BTW: This patch should also fix many failures at [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg02192.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40577
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #33 from burnus at gcc dot gnu dot org 2009-07-26 09:50 --- (In reply to comment #32) > > Regarding the just committed inline version: It would be interesting to know > > whether it is vectorizable (with/without -ffinite-math-only [i.e. > > -ffast-math]). > > It depends on where it is inlined. It has to be vectorized in outer loop (see > my previous comment), so it needs another loop around it. Using the example from comment 23 with a) gfortran -O3 -ffast-math -march=native -ftree-vectorize -ftree-vectorizer-verbose=5 b) ifort -O3 -xHost -diag-enable all ifort shows: test.f90(12): (col. 9) remark: LOOP WAS VECTORIZED. and needs 1.476s. gfortran shows: test.f90:12: note: not vectorized: unsupported use in stmt. and needs 2.272s. (By comparison. 4.4 needs 3.688s.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-26 09:26 --- Certainly not a bug, at most an enhancement: in the current and future C++ Standards there is no mention of such types, of course. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
[Bug c++/40749] [4.3/4.4/4.5 Regression] g++ doesnt report missing return if return is of type const
--- Comment #4 from simartin at gcc dot gnu dot org 2009-07-26 08:16 --- Subject: Bug 40749 Author: simartin Date: Sun Jul 26 08:16:41 2009 New Revision: 150097 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150097 Log: gcc/cp/ 2009-07-26 Simon Martin PR c++/40749 * decl.c (grokdeclarator): Do not set TREE_NO_WARNING for functions with a qualified return type. gcc/testsuite/ 2007-07-26 Simon Martin PR c++/40749 * g++.dg/warn/Wreturn-type-6.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wreturn-type-6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40749
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #32 from irar at il dot ibm dot com 2009-07-26 07:48 --- (In reply to comment #30) > Regarding the just committed inline version: It would be interesting to know > whether it is vectorizable (with/without -ffinite-math-only [i.e. > -ffast-math]). It depends on where it is inlined. It has to be vectorized in outer loop (see my previous comment), so it needs another loop around it. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug tree-optimization/40801] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1096
--- Comment #5 from irar at il dot ibm dot com 2009-07-26 07:04 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
[Bug tree-optimization/40801] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1096
--- Comment #4 from irar at gcc dot gnu dot org 2009-07-26 07:00 --- Subject: Bug 40801 Author: irar Date: Sun Jul 26 07:00:23 2009 New Revision: 150096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150096 Log: PR tree-optimization/40801 * tree-vect-stmts.c (vectorizable_call): Get previous copy of vector operand from the previous copy of vector statement. Pass the correct definition type value to vect_get_vec_def_for_stmt_copy(). Added: trunk/gcc/testsuite/gfortran.dg/vect/fast-math-real8-pr40801.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/vect.exp trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
