--- Comment #5 from edwintorok at gmail dot com 2009-04-13 06:56 ---
(In reply to comment #4)
(In reply to comment #3)
But converting from short to int for the argument to printf should behave
as if
a short value was converted to int, i.e. the int value should be in range
--- 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_
--- 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 to
--- 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 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 #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 #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 link mingw
--- 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
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
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
--- 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
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
--- 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=17624action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39748
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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:
--- 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=17625action=view)
Rename getline () to get_line () in test-demangle.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39752
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
--- 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
--- 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.
--
--- 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=gccview=revrev=146006
Log:
PR c++/39750
* pt.c (uses_template_parms): Handle
--- 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=gccview=revrev=146008
Log:
PR c++/39750
* pt.c (uses_template_parms): Handle
--- 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=gccview=revrev=146009
Log:
2009-04-13 H.J. Lu hongjiu...@intel.com
PR testsuite/39733
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 #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
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 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic'
/opt/software/gcc
--- 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, this
--- 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
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
--- 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=gccview=revrev=146011
Log:
PR c++/39480
* call.c (build_over_call): Don't
--- 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=gccview=revrev=146013
Log:
PR c++/39480
* call.c (build_over_call): Don't
--- 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 #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 #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 not
--
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 #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 dave
--- 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 #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
--- 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
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
--- 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
--- 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=gccview=revrev=146020
Log:
PR c++/39480
* call.c (build_over_call): Don't
--- 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 #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
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()
50 matches
Mail list logo
