--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=397
--- 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
Asserti
--- 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 bo
--- 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=17642&action=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
Status|UNCONFIR
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
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-1
--- 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
AssignedTo|
--- 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 complete
--- 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=gcc&view=rev&rev=146120
Log:
2009-04-15 Richard Guenther
PR tree-optimization/
--- 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
template
class Sum {
public:
enum { val = N };
template
class Inc : public Sum { };
};
int main() {
return(Sum<2>::Inc<3>::Inc<6>::Inc<4>::val);
}
//ENDS SUM.CPP
Now GCC produces:
$
--- 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=17643&action=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\CPP>gcc -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\CPP>gcc 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
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Non-aliased
decls are only used if passes as parameters or if
--- 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
get_symbol_co
--- 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
--- 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 returnin
--- 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=gcc&view=rev&rev=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=gcc&view=rev&rev=146134
Log:
2009-04-15 Janne Blomqvist
PR libfortran/38688
* io
--- 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
l
--with-mpfr=/usr/local/google/tmp/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)
--
jingyu at google dot com changed:
--- 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 ira
--- 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
Ass
% 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
int main(void) {
uint8_t
$ 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=17645&action=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 incr
--- 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 t
l
--with-mpfr=/usr/local/google/tmp/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
Pro
--- 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
-
--- Comment #9 from sebastian dot wenzler at hp dot com 2009-04-16 06:40
---
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.
Environment:
1) binutils/2.15 2) bison/1.875 3) automake/1.4-p5 4) gcc/4.2.4
LD_RUN_PATH=/local/scratch/xhpsewe/424-64bit/lib/sparc
48 matches
Mail list logo
