--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-15 06:40 ---
As I said, the branch is still open for regression bugfixes, so I don't see why
this couldn't be added there provided sufficient testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39767
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-04-15 07:05 ---
Sorry for missing that 4.4 is still open for regressions.
I'll apply the patch on trunk if the normal tests are done
successfully and backport it on 4.4-branch.
--
--- Comment #2 from ubizjak at gmail dot com 2009-04-15 07:30 ---
Confirmed on i686-pc-linux-gnu with '-O -ffinite-math-only' on trunk.
--
ubizjak at gmail dot com changed:
What|Removed |Added
On Solaris 11, we observed execution abort for the testcase below:
+libstdc++.sum:FAIL: ext/throw_allocator/check_delete.cc execution test
The testcase check_delete.cc and its related header files are included in the
attachment bug.tar.
# g++ check_delete.cc -D_GLIBCXX_ASSERT -I.
# ./a.out
--- Comment #29 from dcb314 at hotmail dot com 2009-04-15 07:41 ---
(In reply to comment #27)
Noticed while building binutils (with -Werror):
../binutils-2.19.1/bfd/elf.c: In function '_bfd_elf_print_private_bfd_data':
../binutils-2.19.1/bfd/elf.c:1236: error: offset '2' outside
--- Comment #1 from hailijuan at gmail dot com 2009-04-15 07:43 ---
Created an attachment (id=17642)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17642action=view)
check_delete.cc and its header files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39775
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-15 11:21 ---
Indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Between revisions 145899 (working, may be also 145928) and 145941 (failing) the
test g++.dg/ext/altivec-15.C started to fail:
...
output is:
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:7: error: 'Float'
does not name a type^M
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-15 12:17 ---
I have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-15 12:30 ---
*** This bug has been marked as a duplicate of 28105 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-04-15 12:30 ---
*** Bug 39772 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-15 12:31 ---
We drop back from CONSTANT (NaN) to UNDEFINED because of
canonicalize_float_value.
I have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-04-15 12:32 ---
Closing, see comment #5.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from paolo dot carlini at oracle dot com 2009-04-15 13:09
---
Hi, and sorry about my delay. I think we should definitely resolve this in time
for 4.4.0.
I agree, the new proposed fix looks much better. Still, I must admit, there is
something I do not understand
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-15 13:21 ---
not a duplicate of PR28105. The allocate is fine (on an x86_64).
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-15 13:56
---
Probably it's too late anyway for 4.4.0...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
--- Comment #3 from kargl at gcc dot gnu dot org 2009-04-15 13:57 ---
(In reply to comment #2)
not a duplicate of PR28105. The allocate is fine (on an x86_64).
Actually, the entire program is fine. But, it does not do
what you expected! Try using your allocated array in something
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-15 13:59 ---
This started failing since PR28301, which has been committed to trunk/4.4/4.3.
I guess the last two dg-error comments should be nuked from this testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39776
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-15 14:18 ---
Subject: Bug 39764
Author: rguenth
Date: Wed Apr 15 14:17:35 2009
New Revision: 146120
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146120
Log:
2009-04-15 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-15 14:23 ---
For some reason 4.3 and 4.4 work for me (though they definitely have the
same problem).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following C++ program aims to calculate the sum of some ints at compile
time:
//BEGINS SUM.CPP
templateint N
class Sum {
public:
enum { val = N };
templateint K
class Inc : public Sumval + K { };
};
int main() {
return(Sum2::Inc3::Inc6::Inc4::val);
}
//ENDS SUM.CPP
Now GCC
--- Comment #1 from pietro dot braione at polimi dot it 2009-04-15 15:20
---
Created an attachment (id=17643)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17643action=view)
the example program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39777
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-15 15:39 ---
The issue comes down to how is Inc injected into Inc. I can't remember the
exact rules but I think GCC's behavior is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39777
C:\DJGPP\CPPgcc -v
Using built-in specs.
Target: djgpp
Configured with: /v203/gcc-4.32/configure msdosdjgpp
Thread model: single
gcc version 4.3.2 (GCC)
C:\DJGPP\CPPgcc PPID_update.cpp -o PPID_Update.exe -lm
gcc.exe: Internal error: (null) (program cc1plus)
Please submit a full bug report.
See
--- Comment #1 from darklingduck at gmail dot com 2009-04-15 15:42 ---
I get the failure that I sent every time I try to compile the source file using
the command prompt or in rhide.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39778
--- Comment #9 from danglin at gcc dot gnu dot org 2009-04-15 16:01 ---
This regression was introduced by the following change:
2009-04-07 Richard Guenther rguent...@suse.de
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Non-aliased
decls are only used if passes as
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-04-15 16:19
---
Hmm, are you sure that revision is the cause? What happens is that the
variable thrs is appearantly a translation-unit local constant variable
with a constant initializer of 4. CCP looks that up via
--- Comment #4 from jv244 at cam dot ac dot uk 2009-04-15 17:03 ---
But, it does not do
what you expected! Try using your allocated array in something
other than SIZE().
It's doing exactly what I expect... including the size intrinsic returning a
garbage result because it returns a
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-15 17:04
---
For the record, the Intel compiler - which I trust much more than DM, sorry -
behaves the same as GCC. I strongly believe GCC is correct. I even think we
have something closed about this issue, let me see if I
--- Comment #5 from kargl at gcc dot gnu dot org 2009-04-15 17:43 ---
(In reply to comment #4)
But, it does not do
what you expected! Try using your allocated array in something
other than SIZE().
It's doing exactly what I expect... including the size intrinsic returning a
--- Comment #1 from lcwu at gcc dot gnu dot org 2009-04-15 17:56 ---
Subject: Bug 39551
Author: lcwu
Date: Wed Apr 15 17:55:50 2009
New Revision: 146132
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146132
Log:
PR c++/39551
* gcc/cp/call.c (build_over_call): Set
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-15
17:56 ---
Subject: Re: [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
Hmm, are you sure that revision is the cause? What happens is that the
No, but it exposed the problem.
static int thrs =
--- Comment #2 from lcwu at gcc dot gnu dot org 2009-04-15 18:03 ---
The fix for this bug was committed at revision 146132.
--
lcwu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jb at gcc dot gnu dot org 2009-04-15 19:38 ---
Subject: Bug 38688
Author: jb
Date: Wed Apr 15 19:38:32 2009
New Revision: 146134
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146134
Log:
2009-04-15 Janne Blomqvist j...@gcc.gnu.org
PR
--- Comment #5 from jb at gcc dot gnu dot org 2009-04-15 19:42 ---
Er, sorry, wrong PR in the ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38688
--- Comment #4 from jb at gcc dot gnu dot org 2009-04-15 19:46 ---
Fixed in trunk as r146134 r146135.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
/install --enable-multilib
--with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
Thread model: single
gcc version 4.4.0 20090415 (prerelease) (GCC)
--
jingyu at google dot com changed:
What|Removed |Added
--- Comment #1 from vmakarov at redhat dot com 2009-04-15 21:49 ---
The compiler is broken in IRA on this test because ira_register_move_cost is
not initialized for DFmode, AREG, GENERAL_REGS.
It is supposed that all necessary elements of this array are initialized in
ira-costs.c by
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-15 22:11 ---
Testing a fix for this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
% gcc --version
gcc (Debian 4.3.3-7) 4.3.3
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.
% cat gcc4-bug.c
#include stdint.h
int main(void) {
$ uname -a
MINGW32_NT-6.0 *** 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys
$ gcc -v
Using built-in specs.
Target: i586-elf
Configured with: ../gcc-4.3.3/configure --target=i586-elf --prefix=/mingw/cross
--disable-nls --enable-languages=c,c++ --without-headers
Thread model: single
gcc version 4.3.3
--- Comment #1 from kuchen_ at gmx dot de 2009-04-15 22:48 ---
Created an attachment (id=17645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17645action=view)
The preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
--- Comment #3 from jingyu at google dot com 2009-04-15 23:35 ---
GCC puts destructors in .fini_array section in increasing order, and expects
linker executes entries in .fini_array in reverse order (according to ELF
specification). However, newlib executes entries in .fini_array in
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-15 23:43 ---
(In reply to comment #3)
Filed an issue in newlib mailing list.
http://sourceware.org/ml/newlib/2009/msg00466.html
newlib does have a bugzilla, located http://sourceware.org/bugzilla/, though
not many people use
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-04-16 01:05 ---
Where on your system is the ancient mpfr located? Is it in the /sw
directory?
(In reply to comment #0)
From fink, I have gmp 4.1 in /sw/{lib,include}, but mpfr is ancient. I put a
new mpfr in $HOME, and tried to
/gcc4.4_dejagnu/install --enable-multilib
--with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
Thread model: single
gcc version 4.4.0 20090415 (prerelease) (GCC)
--
Summary: Fail: g++.dg/cpp/_Pragma1.C, gcc.dg/cpp/_Pragma6.c
Product: gcc
Version: 4.4.0
--- Comment #53 from dannysmith at users dot sourceforge dot net
2009-04-16 02:59 ---
This thread is alos relevant.
http://gcc.gnu.org/ml/gcc/2009-04/msg00462.html
Adding Dave Korn to cc:
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #1 from hp at gcc dot gnu dot org 2009-04-16 03:08 ---
Is this a cond-optab regression or just an observation?
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
48 matches
Mail list logo
