The toolchain is built with newlib C.
*** EXIT code 4242
FAIL: gcc.dg/initpri1.c execution test
The constructors are performed in the correct order, from lowest to highest.
However the destructors are performed in a wrong order.
...
void d1() __attribute__((destructor (500)));
void d2() __attribu
--- Comment #10 from hjl dot tools at gmail dot com 2009-04-14 04:42
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #30 from jason at gcc dot gnu dot org 2009-04-14 03:31 ---
Fixed for 4.3, 4.4 and 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from jason at gcc dot gnu dot org 2009-04-14 03:30 ---
Subject: Bug 39480
Author: jason
Date: Tue Apr 14 03:30:12 2009
New Revision: 146020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146020
Log:
PR c++/39480
* call.c (build_over_call): Don't c
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-14 03:00 ---
-O3 has extra inlining.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Co
gcc version:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/u
--- Comment #4 from monaka at monami-software dot com 2009-04-14 02:49
---
This issue is about 3.4.x. It's reasonable to close as wontfix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19255
--- Comment #4 from john dot engelhart at gmail dot com 2009-04-14 01:15
---
Another point to consider is whether or not C99's 'restrict' is a legitimate
type qualifier for pointers to Objective-C objects. This is really more of an
observation that pragmatically, very little can be sai
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-14
00:10 ---
Subject: Re: [4.5 Regression] Fail pr34513.c and
pr34513.C at -O1 and above
> The "if (shrd != thrs)" is optimized away. Attached .s files with -O0
> and -O2.
The last pass with the comparison at
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-13
23:10 ---
Subject: Re: New: [4.5 Regression] Fail pr34513.c and
pr34513.C at -O1 and above
The "if (shrd != thrs)" is optimized away. Attached .s files with -O0
and -O2.
Dave
--- Comment #2 from dav
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-13 22:00 ---
(In reply to comment #2)
> Is this really "broken" when the Apple compiler has the same behavior
> (assuming
> we all accept that the Apple Objective-C semantics are the de facto standard)?
Apple's compiler does no
--- Comment #2 from steven at gcc dot gnu dot org 2009-04-13 21:59 ---
Is this really "broken" when the Apple compiler has the same behavior (assuming
we all accept that the Apple Objective-C semantics are the de facto standard)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-13 21:26 ---
It is caused by revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #28 from jason at gcc dot gnu dot org 2009-04-13 20:56 ---
Subject: Bug 39480
Author: jason
Date: Mon Apr 13 20:56:45 2009
New Revision: 146013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146013
Log:
PR c++/39480
* call.c (build_over_call): Don't c
--- Comment #27 from jason at gcc dot gnu dot org 2009-04-13 20:53 ---
Subject: Bug 39480
Author: jason
Date: Mon Apr 13 20:53:34 2009
New Revision: 146011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146011
Log:
PR c++/39480
* call.c (build_over_call): Don't c
splitting /test/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/c9/c9a011b.ada
into
:
c9a011b.adb
BUILD c9a011b.adb
gnatmake --GCC="/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/"
-gnat
ws -O2 -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support c9a011b.adb
-largs
--GCC="/test/gnu/gcc
--- Comment #26 from jason at gcc dot gnu dot org 2009-04-13 20:08 ---
I think this actually only comes up at -O0; without optimization we don't try
to expand a call to __builtin_memcpy as a block move because we need TER to
tell us what the real alignment of the operands is. With optim
In one case the C compiler can optimize away an inline memcpy() on a
MIPS target. The problem was duplicated with GCC 3.2.1 and 3.3.3.
The problem does not affect x86 targets or GCC 4.x (tested on 4.2.4).
The MIPS cross-compiler runs under RHEL. Tested MIPS cross-compilers
under Cygwin and Mingw
--- Comment #9 from hjl at gcc dot gnu dot org 2009-04-13 19:42 ---
Subject: Bug 39733
Author: hjl
Date: Mon Apr 13 19:42:26 2009
New Revision: 146009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146009
Log:
2009-04-13 H.J. Lu
PR testsuite/39733
* gcc.misc-
--- Comment #3 from jason at gcc dot gnu dot org 2009-04-13 19:27 ---
Subject: Bug 39750
Author: jason
Date: Mon Apr 13 19:27:20 2009
New Revision: 146008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146008
Log:
PR c++/39750
* pt.c (uses_template_parms): Handle
-accessed-elt-2-of-tree_vec.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_4-branch/configure
--prefix=/opt/software/gcc-x86_64/gcc-4.4.x --program-suffix=-4.4.x
--enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.4.0 20090413 (prere
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-04-13 19:25 ---
(In reply to comment #10)
> I try to build gcc with latest CRT from svn (revision 764) - build is OK. It
> seems, snapshot from sourceforge download page(November 15, 2008) not
> compatible with gcc 4.4.
>
Well, th
--- Comment #4 from jason at gcc dot gnu dot org 2009-04-13 19:27 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jason at gcc dot gnu dot org 2009-04-13 18:54 ---
Subject: Bug 39750
Author: jason
Date: Mon Apr 13 18:54:40 2009
New Revision: 146006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146006
Log:
PR c++/39750
* pt.c (uses_template_parms): Handle
--- Comment #10 from css20 at mail dot ru 2009-04-13 18:06 ---
I try to build gcc with latest CRT from svn (revision 764) - build is OK. It
seems, snapshot from sourceforge download page(November 15, 2008) not
compatible with gcc 4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-13 17:51 ---
Confirmed, the aliasing rules were also in ISO C90 (aka ANSI C89). This has
been broken since 3.0 when strict aliasing was enabled by default.
--
pinskia at gcc dot gnu dot org changed:
What|Remo
Please keep in mind that I'm not a GCC internals expert, and this really
requires some analysis from an ObjC maintainer (and expert) along with someone
who is familiar with the details of how -fstrict-aliasing works.
See also: http://gcc.gnu.org/ml/gcc/2009-04/msg00290.html
The short version is t
--- Comment #1 from peter dot kovar at gmail dot com 2009-04-13 17:40
---
Created an attachment (id=17625)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17625&action=view)
Rename getline () to get_line () in test-demangle.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39752
libiberty/testsuite/test-demangle.c
After configuration with the following
../../configure --program-suffix=-4.5.0 --enable-languages=c,c++,objc,obj-c++
I've started
make check
which failed on Fedora 10+ x86 as well as x86-64
../../../../libiberty/testsuite/test-demangle.c:49: error: conflict
--- Comment #8 from dominiq at lps dot ens dot fr 2009-04-13 17:21 ---
The patch in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00852.html
fixes PR39749.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
--- Comment #7 from dominiq at lps dot ens dot fr 2009-04-13 17:19 ---
I finally used
make -k check-gcc RUNTESTFLAGS="help.exp=* --target_board=unix/-m64"
and got with the patch in
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00852.html
=== gcc Summary ===
# of expect
--- Comment #12 from jb at gcc dot gnu dot org 2009-04-13 16:55 ---
Fixed as of r145875
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #6 from dominiq at lps dot ens dot fr 2009-04-13 16:02 ---
> I will bet they are the same bug. One easy way to verify it is to
> apply my patch for PR 39733 to see if those failures disappear.
What magic incantation should I use to test it. I tried
make -k check-gcc RUNTEST
--- Comment #9 from css20 at mail dot ru 2009-04-13 15:48 ---
> Do you use for native toolchain an fresh initialized directory?
> Which version of toolchain you are using (especially header-set)?
> Do you use --prefix and --with-sysroot options?
I use directory with mingw-64 runtime ins
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-13 15:12 ---
*** Bug 39749 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-13 15:12 ---
Since this happens "on i686-apple-darwin9 with -m64", it seems like
multilib configuration. It is very likely a dup for PR 39733. Please
reopen it if my fix for PR 39733 doesn't fix it.
*** This bug has been marked
--- Comment #5 from paolo dot carlini at oracle dot com 2009-04-13 15:12
---
HJ, you are wrong, make sure to pass --enable-checking explicitly in
4_4-branch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-13 15:10
---
Indeed, I just checked and 4.4.0 also ICEs when checking is enabled, thus
behaves exactly like 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-13 15:06 ---
This is caused by revision 137361:
http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00065.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gmail dot com 2009-04-13 15:06 ---
Subject: Re: New: ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
Sent from my iPhone
On Apr 13, 2009, at 7:43 AM, "gcc at abeckmann dot de"
wrote:
> This is a 4.5.0 regression on invalid code:
>
> == 8
Sent from my iPhone
On Apr 13, 2009, at 7:43 AM, "gcc at abeckmann dot de" > wrote:
This is a 4.5.0 regression on invalid code:
== 8< ==
template < typename >
struct A
{
A < struct
{
f () :
== >8 ==
-- 4.5.0 --
$ x86_64-linux-gnu-g++-trunk -v
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-13 15:04 ---
(In reply to comment #1)
> Are you *sure* this is a regression? Did you compare to 4.5.0 a 4.4.0 built
> with checking *enabled*?
>
FWIW, gcc 4.4.0 doesn't ICE when checking isn't disabled. But this testcase
has be
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-13 14:47
---
Are you *sure* this is a regression? Did you compare to 4.5.0 a 4.4.0 built
with checking *enabled*?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
This is a 4.5.0 regression on invalid code:
== 8< ==
template < typename >
struct A
{
A < struct
{
f () :
== >8 ==
-- 4.5.0 --
$ x86_64-linux-gnu-g++-trunk -v -c ice-cp_parser_c-342.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configur
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-13 14:22 ---
(In reply to comment #3)
> Reopening this bug, it is not a duplicate of 39733:
>
> bug #39733 is about an extra -v added to the argument list of subprocesses,
> and is due to gcc.misc-tests/options.exp and lib/optio
--- Comment #2 from danglin at gcc dot gnu dot org 2009-04-13 14:07 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from rwild at gcc dot gnu dot org 2009-04-13 13:54 ---
Reopening this bug, it is not a duplicate of 39733:
bug #39733 is about an extra -v added to the argument list of subprocesses,
and is due to gcc.misc-tests/options.exp and lib/options.exp defining the same
functions,
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-13 13:30 ---
(In reply to comment #5)
> HJ, can you please show verbose log output from the failed tests that proves
> that this bug and the other one are indeed duplicates? I don't see why on
> GNU/Linux, as should fail when pa
--- Comment #15 from hjl dot tools at gmail dot com 2009-04-13 13:18
---
Fixed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rwild at gcc dot gnu dot org 2009-04-13 13:17 ---
HJ, can you please show verbose log output from the failed tests that proves
that this bug and the other one are indeed duplicates? I don't see why on
GNU/Linux, as should fail when passed --help
--
http://gcc.gn
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-13 13:11 ---
*** This bug has been marked as a duplicate of 39733 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-13 13:11 ---
*** Bug 39749 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from sezeroz at gmail dot com 2009-04-13 11:55 ---
(In reply to comment #4)
> The fix may have broken cross compiling:
>
> http://gcc.gnu.org/ml/gcc/2009-03/msg00525.html
>
PR39503 has already been closed for some fime, so this one should be closed,
too.
--
sezeroz
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-04-13 10:51 ---
Applied to gcc's 4.5 (trunk at revision 146001) and binutils/gdb's head.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-13 10:46 ---
Subject: Bug 39397
Author: ktietz
Date: Mon Apr 13 10:45:58 2009
New Revision: 146001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146001
Log:
2009-04-13 Ozkan Sezer
PR target/39397
* pe
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-13 10:38 ---
Applied to 4.5 at revision 146000.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-13 10:37 ---
Subject: Bug 39062
Author: ktietz
Date: Mon Apr 13 10:37:17 2009
New Revision: 146000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146000
Log:
2009-04-13 Ozkan Sezer
PR target/39062
* ss
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-13 10:12 ---
Committed to 4.5 as revision 145999.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
This looks like a ice-on-invalid-code regression in g++ 4.4/4.5:
==
template < unsigned >
struct A ;
template < typename >
struct B ;
template < typename T , A < B < T >
{ }
==
-- 4.4.0 --
$ x86_64-linux-gnu-gcc-4.4.x -v -std=c++0x -c
ice-uses_template_parms-cp_pt.
--- Comment #1 from rwild at gcc dot gnu dot org 2009-04-13 09:44 ---
This looks like a genuine bug in the GCC driver or as to me: gcc shouldn't
pass on flags to subprocesses if they don't understand them. The testsuite
addition just exposed them. How can this as be made to output help
On i686-apple-darwin9 with -m64 I have the following failures:
FAIL: compiler driver --help option(s) (linker options)
FAIL: compiler driver -v --help option(s) (assembler options)
FAIL: compiler driver -v --help option(s) (linker options)
FAIL: compiler driver -v --help option(s) (assembler optio
--- Comment #1 from dcb314 at hotmail dot com 2009-04-13 09:23 ---
Created an attachment (id=17624)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17624&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39748
I just tried to compile the popular bzip2 package
with the GNU gcc version 4.5 snapshot 20090409.
The compiler said
bzlib.c: In function 'bzopen_or_bzdopen':
bzlib.c:1443: warning: offset '2' outside bounds of constant string
bzlib.c:1443: warning: offset '3' outside bounds of constant string
Th
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-04-13 09:22
---
Closing as WONTFIX, see the thread starting at
http://gcc.gnu.org/ml/fortran/2009-03/msg00205.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-04-13 08:34 ---
(In reply to comment #7)
> > Please make sure, that you have in your gcc source root directory the
> > symbolic
> > link "winsup" pointing to your prefix directory. Secondly, make sure you
> > have
> > the symbolic
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-04-13 08:19
---
*** Bug 39736 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-13 08:19 ---
*** This bug has been marked as a duplicate of 35634 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-13 08:17 ---
It is? Anyway, you should build static gmp with -fPIC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
--- Comment #7 from css20 at mail dot ru 2009-04-13 08:11 ---
> Please make sure, that you have in your gcc source root directory the symbolic
> link "winsup" pointing to your prefix directory. Secondly, make sure you have
> the symbolic link "mingw" in your prefix directory, which has t
--- Comment #6 from schwab at linux-m68k dot org 2009-04-13 07:53 ---
(In reply to comment #4)
> But your test program does cause signed overflow
No, it doesn't. There is a conversion (from int to short) where the value is
not representable by the target type, but that is _not_ undefin
72 matches
Mail list logo
