reopen 707118
tags 707118 + upstream
forwarded 707118 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57230
thanks
The incorrect optimization is not that the comparison was optimized
away. It's that the program prints 0 instead of 12. This simplified
testcase shows the same problem:
int main(
Package: libstdc++6-4.6-dbg
Version: 4.6.2-15
Severity: normal
gdb wants Python extensions installed under /usr/share/gdb/python, but
libstdc++6-4.6-dbg is putting them under /usr/share/gcc-4.6/python instead.
Thus, you get an obnoxious error message every time you debug a C++ program:
from l
Package: libstdc++6
Severity: normal
It sounds like this bug is the cause of a FTBFS in one of my packages. In
case it's helpful, here is a small self-contained test program that currently
crashes when run on the hppa buildd:
#include
#include
int
main(void)
{
std::ofstream ofs("_conftest.da
The new monotone package (0.43-1) has built successfully on ia64
including execution of the code that was crashing before, so I suspect
this was fixed, probably by a compiler upgrade. I'll close these bugs
if the next upload succeeds too (wanting to make sure it's not a
fluke).
zw
--
To UNSUB
Package: g++-4.3
Version: 4.3.0-5
Severity: normal
A package of mine (monotone) failed to build on one of the ia64 build
daemons due to an "impossible" failure in its testsuite. The unit tests
for this package, in several places, deliberately break data structure
invariants and check that std::lo
On Tue, Jun 3, 2008 at 4:58 AM, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 01, 2008 at 11:33:54AM -0400, Zack Weinberg wrote:
>> I maintain a package (monotone) that fails to build from source on
>> alpha, arm, and ia64 with symptoms that suggest compiler bugs
I maintain a package (monotone) that fails to build from source on
alpha, arm, and ia64 with symptoms that suggest compiler bugs to me.
On arm it's clear-cut: cc1plus segfaults. On ia64, there are
testsuite failures because exceptions that should have been caught
(and are caught on other architect
sorry, i misread the version number.
zw
Package: gcc-3.3
Version: 1:3.3.3-0pre0.1
Severity: normal
Followup-For: Bug #224593
reopen 224593
thanks
I still see this problem having upgraded to the latest unstable gcc.
$ cat test.c
#include
$ gcc -msse -c test.c ; echo $?
n file included from test.c:1:
/usr/lib/gcc-lib/i486-linux/3.3.3/i
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, Sep 15, 2003 at 02:59:28PM +0100, Joseph S. Myers wrote:
>> On Sun, 14 Sep 2003, Daniel Jacobowitz wrote:
>>
>> > On sid, I recommend installing flex-old.
>>
>> I observed previously that for other reasons the old version is also
>> required
FYI, the reason those manpages exist in the first place, is that the
GCC Texinfo manual is under the GFDL, and the manpages cpp.1/gcc.1 are
automatically generated from it. The FSF advised us (the GCC
maintainers) that creating and distributing separate manpages for each
of the Invariant Sections
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>
> | Benjamin Kosnik <[EMAIL PROTECTED]> writes:
> | >
> | > I've versioned the runtimes assuming that 3.3 will not break the 3.2
> | > ABI, and that 3.4 w
Segher Boessenkool <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>>
>> I'm very much in favor of making -Wconversion more useful, but is
>> there any reason not to shift the argument-type-conversion warnings
>> entirely over to -Wtraditional? Particu
Segher Boessenkool <[EMAIL PROTECTED]> writes:
> Matthias Klose wrote:
>> It'd be nice if these two behaviors were two controlled via two
>> separate flags. The second behavior would have caught a bug I've been
>> hunting for hours, while the first behavior is very undesirable to me
>> (and useles
This is a quote from the Debian package changelog for gcc 3.2:
* FTBS: With the switch to bison-1.50 (and 1.75), gcc-3.2 fails to build from
source on Debian unstable systems. This is fixed in gcc HEAD, but not on
the current release branch.
HELP NEEDED:
- check what is missing
On Mon, Oct 14, 2002 at 11:26:17PM -0700, Mark Mitchell wrote:
>
> >I'll leave it to our release manager to decide if this issue warrants
> >backporting the relevant patches or not.
>
> I think that your point that we will include the generated files on the
> branch is a good one; let's not backp
Martin v. Loewis writes:
>
> To find out what is defined, compile an empty C file with -v -E.
Compiling an empty C file with -E -dM would work better.
I get this from a ->i686-netbsdelf cross compiler:
#define __VERSION__ "3.3 20020913 (experimental)"
#define __ELF__ 1
#define __NetBSD__ 1
#defi
This was reported to the Debian bug-tracking system:
$ cat foo.c
_Pragma("foo"); int y;
#define FOO _Pragma("foo"); int x;
FOO
[EMAIL PROTECTED]:~$ cpp-3.2 foo.c
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"
# 1 "foo.c"
#pragma foo
# 1 "foo.c"
; int y;
# 3 "foo.c"
#pragma ; int x;foo
>
On Fri, Jun 21, 2002 at 12:49:25PM +0200, [EMAIL PROTECTED] wrote:
> - with my default locale, fr_FR.ISO8859-1, GCC says:
> tmp.cc: Dans function « int main() »:
> tmp.cc:511: no match pour l'opérateur «
> erreur interne de compilateur: erreur pour rapporter une routine ré-entée
This would be a bu
On Sun, Jun 02, 2002 at 12:34:20AM +0200, Matthias Klose wrote:
>
> merry$ gcc -Wall -Werror -Wmissing-prototypes -g -O2 -I. -DSTDC_HEADERS=1
> -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 Test.c -o Test
> cc1: /tmp/ccb04872: I/O error
>
> This happened repeatedly when /tmp filled up during compilation (T
Package: gcc
Version: 2:2.95.4-6
Severity: normal
When one invokes the compiler driver on a language (e.g. Ada) for which
there is no front end installed, it exits successfully, which causes Make
to think that the compilation succeeded. Observe:
$ touch ada.ads
$ gcc -c -v ada.ads ; echo $?
Read
On Sun, May 20, 2001 at 08:44:32PM +0200, Markus F.X.J. Oberhumer wrote:
> $ gcc-3.0 -c -Werror bug02.c
> bug02.c:13:23: pasting ""_"" and ""foo"" does not give a valid preprocessing
> token
...
> #define ASM_NAME(x) __asm__("_" ## #x)
This is not valid C. As it says, pasting together the s
22 matches
Mail list logo
