On Fri, May 28, 2010 at 10:46:06AM +0200, Hendrik Tews wrote:
>
>The code simply contains ridiculously deeply nested expressions (about
>11000 opening braces), so the compiler runs out of stack. Use "ulimit
>-s unlimited" if you really want to compile this.
>
> OK, thanks for th
On Wed, May 05, 2010 at 04:35:53PM +0200, Hector Oron wrote:
> > I'd give it a try if I had a standalone executable C test case, i.e. a
> > "main()" that demonstrates the problem...
>
> I think Camm attached a preprocessed source ff.c in a previous mail
> (in this thread)
> http://bugs.debian.org/
On Wed, May 05, 2010 at 04:01:47PM +0200, Hector Oron wrote:
> 2010/1/22 Camm Maguire :
> > Greetings! Please install gcc-snapshot on sid chroot albeniz.
>
> Do you still need to debug that issue? I have installed gcc-snapshot
> at sid chroot on albeniz.
> Let me know if it is unneeded so I'll re
tags 564274 + moreinfo
thanks
On Fri, Jan 08, 2010 at 10:40:07PM +0100, S??awomir Domaga??a wrote:
> I can't make shorter source code, where is this error, thus I've got all
> source code from my programme, but I've written which lines is the error.
>
> Line from 156 to 161 in engine.cpp:
>
> S
tags 568398 + moreinfo
thanks
On Thu, Feb 04, 2010 at 10:10:00AM -0500, Camm Maguire wrote:
> dd.c:
> #include
> #include
>
> int main(int argc,char * argv[]) {
> double complex d=0;
> long l;
>
> sscanf(argv[1],"%ld",&l);
> d=l;
> printf("%d %d %d %d %f\n",(char)d,(short)d,(int)d,(l
tags 532871 + moreinfo
thanks
On Fri, Jun 12, 2009 at 01:20:54PM +0200, Sven Marnach wrote:
> The following program compiles cleanly using the given command line:
>
> #include
> using namespace std;
> int main()
> {
> unsigned int j = 5;
> double t;
> t =
On Thu, Feb 04, 2010 at 09:55:42AM -0500, Camm Maguire wrote:
> This test program will segfault at -O2 on the affected machines:
Can you please repost the attachment? It is not retrievable from the
BTS at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567695 ...
Falk
--
To UNSUBSCRIBE, em
On Sun, Mar 01, 2009 at 04:04:07PM +0200, Kalle Olavi Niemitalo wrote:
> Falk Hueffner writes:
>
> > I can't imagine any sensible code whatsoever that triggers this
> > warning but does not have logical errors. Can you show how it is used?
>
> Here are all the sou
On Sun, Mar 01, 2009 at 10:40:40AM +0200, Kalle Olavi Niemitalo wrote:
> Compiling this with gcc-4.3 -Wall -c
>
> int
> main (void)
> {
> return "hello" == "there";
> }
>
> results in a warning:
>
> hoh.c: In function ???main???:
> hoh.c:4: warning: comparison with string literal results in un
tags 513961 + moreinfo
thanks
On Mon, Feb 02, 2009 at 08:10:36PM +, neovento wrote:
> When building fifengine on openmoko neo freerunner a segmentation fault
> occurs:
> engine/swigwrappers/python/fife_wrap.cxx:69953: internal compiler error:
> Segmentation fault
Please send the complete co
Hi,
I'd be willing to take a look if there is a small testcase (i.e. a
single C file which when compiled and run will either succeed or
fail). Anybody willing to create such a testcase?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Co
"Phil Endecott" <[EMAIL PROTECTED]> writes:
>> I think I found a bug in gcc-4.2
>
>> int i, j;
>> printf("%d %d\n", j, (void *)(j));
>
> This looks like a strict-aliasing issue to me; you're casting from an
> int to a void*, which is undefined.
Casting from int to void* is not undefined, but impl
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> BTW do we still need this special case for Alpha:
>
> # edd 29 Sep 2005 alpha needs -mieee with gcc 4.0
> ifeq ($(arch),alpha)
> CFLAGS+= -mieee
> endif
No, -mieee is default on Alpha now. It's not default upstream though,
so you might wan
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
> -I. -I.. -I.. -I..-mieee -mfp-rounding-mode=d -Wall -pipe -fexceptions
> -D_REENTRANT -g -O3 -mieee -c -o minmax.lo minmax.c
> gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -mieee -mfp-
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> On Wed, Sep 12, 2007 at 08:04:22PM +0200, Matthias Klose wrote:
>> Dirk Eddelbuettel writes:
>> > Please submit a full bug report,
>> > with preprocessed source if appropriate.
>>
>> please do so, does it build with gcc-snapshot?
>
> Don't know as I
"Nemui Ailin" <[EMAIL PROTECTED]> writes:
> Compiling xmlrpc-c CVS from http://xmlrpc-c.sourceforge.net/>
> results in a broken xmlrpc library that fails to allocate memory for the
> structs.
>
> We have this call to realloc in src/method.c
>
> static __inline__ void
> reallocProduct(v
tags 429657 + upstream
forwarded 429657 http://gcc.gnu.org/PR33142
thanks
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Falk Hueffner <[EMAIL PROTECTED]> [2007-06-19 17:03]:
>> I can confirm this on i386, but not amd64 or alpha. A shorter test
>
> Falk, are you goi
forwarded 438791 http://gcc.gnu.org/PR6257
thanks
This is a well-known problem, and it might even turn out that gcc's
behavior is legalized in the next standard update.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTE
reassign 436491 nfs-utils
retitle 436491 uses FP math, yet turns with -mno-fp-regs on Alpha
thanks
static void
unpause(int sig)
{
double time_diff;
[...]
That just doesn't work with -mno-fp-regs. Admittedly, the error
message could be improved.
--
Falk
--
To UNSUBSCRIBE, email to [
retitle 430957 Exponential time usage in PRE at -O3
severity 430957 normal
tags 430957 + upstream
forwarded 430957 http://gcc.gnu.org/PR32540
thanks
Hi,
this is a problem with exponential time usage in PRE. I've filed a bug
report upstream.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL
"\"Török" Edvin" <[EMAIL PROTECTED]> writes:
> Package: gcc-snapshot
> Version: 20070613-1
> Severity: minor
>
> --- Please enter the report below this line. ---
>
> Using gcc-4.3 snapshot to compile with -O3:
> $ time /usr/lib/gcc-snapshot/bin/gcc -DHAVE_CONFIG_H -I.
> -I../../../clamd -I.. -I.
Jasen Betts <[EMAIL PROTECTED]> writes:
> Package: gcc-4.1
> Version: 4.1.1-21
> Severity: normal
>
>
> abuse-sdl-0.7.0 has a gun aiming problem due to a mis-optimisation.
> attached is a canned example.
>
> (compile with -01 and -02 and compare the differences)
I can confirm this on i386, but n
David Baron <[EMAIL PROTECTED]> writes:
> Package author posts:
>
>> Better compile using G++-4.0. 4.1 fails with an internal compiler
>> error compiling ToneStack.cc. I filed a bug for the debian G++-4.1
>> as instructed. G++-4.0 compiles fine.
>
> Just edit the makefile and swap "-O3" with "-O2
Gerrit Pape <[EMAIL PROTECTED]> writes:
> On a current Debian/powerpc sid system:
>
> $ cat >ttt.c < static const double d[] = { 1.0l/6/1/2, -1.0l/30/3/4 };
> int main() { return 0; }
> EOT
> $ gcc-4.1 ttt.c
> ttt.c:1: error: initializer element is not constant
> ttt.c:1: error: (near initi
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> close 381717 4.1.2-4
> thanks
>
> This bug has been fixed in SVN on Sun Apr 22 02:30:31 2007, which means
> it should be fixed in 4.1.2-4.
>
> Falk, can you a) confirm this and b) tell those packages with
> workarounds to remove them?
It's fixed, and
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Torsten Werner <[EMAIL PROTECTED]> [2007-04-20 13:31]:
>> * alpha:
>> Running the unit tests:
>> cd build/test/unit && obj/gcc/so/stl_unit_test
>> /bin/sh: line 1: 7948 Segmentation fault obj/gcc/so/stl_unit_test
>
> Maybe Falk can take a look
Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes:
> We would like to know which major upstream versions of gcc are
> expected to be released in the next 24 months and how much time you
> expect them to need to get stable enough for a Debian stable release.
gcc 4.2.0 will be released Real Soon No
Diego Russo <[EMAIL PROTECTED]> writes:
> Package: gcc-4.1
> Version: 4.1.1-21
> Severity: serious
> Justification: no longer builds from source
>
> Sorry I don't speak english, this is the error:
> [...]
> The bug is not reproducible, so it is likely a hardware or OS problem.
This means it is ac
Sergei Trofimovich <[EMAIL PROTECTED]> writes:
> Hello, debian GCC maintainers.
> I've recently discovered strange gcc behavior:
> Summary:
> string ' // comment \ ' in C code performs line wrap.
>
> Is it bug or feature?
It's a feature. You get a warning about this with -Wall.
--
Theodore Tso <[EMAIL PROTECTED]> writes:
> On Mon, Nov 13, 2006 at 09:49:21AM +0100, Falk Hueffner wrote:
>> Hi,
>>
>> this looks like an aliasing violation to me. bb->list, which is of
>> type __u32*, is accessed via an lvalue of type void*, which is not
>
Hi,
this looks like an aliasing violation to me. bb->list, which is of
type __u32*, is accessed via an lvalue of type void*, which is not
compatible. Does the problem go away with -fno-strict-aliasing?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscrib
Clint Adams <[EMAIL PROTECTED]> writes:
> severity 370248 serious
> tags 370248 + patch
> quit
>
> There is a patch listed at
> http://gcc.gnu.org/PR27891
Did you test it? I'm not convinced it can be easily backported without
breaking anything. I'll ask the author.
--
Falk
--
To UNSU
Jochen Voss <[EMAIL PROTECTED]> writes:
> one very useful feature of gcc is, that it warns you when you
> produce unterminated strings by using too long initialisers.
> Unfortunately the warning only kicks in, if the initialiser is at
> least two bytes longer than the string buffer.
This is delib
Matthias Klose <[EMAIL PROTECTED]> writes:
> see the attached patch, based on the one from the redhat 4.1
> branch. Thiemo, Falk, Phil, please could you review the patch?
OK with me (although I also don't quite see it's a bug).
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
Stephen R Marenka <[EMAIL PROTECTED]> writes:
> On Mon, Jul 17, 2006 at 09:08:42PM +0200, Falk Hueffner wrote:
>> Stephen R Marenka <[EMAIL PROTECTED]> writes:
>
> So you're saying the only way is to compile, link, and test each of the
> 55 source files? Yikes
tags 378599 + moreinfo
thanks
Stephen R Marenka <[EMAIL PROTECTED]> writes:
> We now have about sixteen packages that end up with a segfault or an
> illegal instruction. I haven't tried recompiling all these to verify that
> this is the same problem, but I will if it will help.
>
> The problem i
Patrick "=?UTF-8?Q?Matth=C3=A4i?=" <[EMAIL PROTECTED]> writes:
> internal compiler error: Speicherzugriffsfehler
> The bug is not reproducible, so it is likely a hardware or OS problem.
Well, there's not much we can do then... In case the message is wrong
and you can in fact reproduce this, pleas
reassign 375080 synfig
thanks
Paul Wise <[EMAIL PROTECTED]> writes:
> When synfig is compiled with g++-4.1 from sid, it no longer renders
> animation files correctly. I was able to get a user running etch to
> confirm that the g++-4.1 version in etch also miscompiles synfig.
That does not suffi
reassign 372557 binutils
thanks
> Compiling a binary file (which is not possible) cause ld to
> segmentation fault.
ld is binutils' domain.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Steve Langasek <[EMAIL PROTECTED]> writes:
> Hi Matthias,
>
>> works for me.
>
> Have you tried building it with prctl --unaligned=signal? This is not
> the default on hppa, but it's used on the autobuilders because it
> catches potentially costly programming errors.
FWIW, gij-4.1 also produces
Steve Langasek <[EMAIL PROTECTED]> writes:
> retitle 369642 g++-4.0/alpha: -fvisibility-inlines-hidden segfaults on
> reference to static method
> thanks
>
> Minimal test case attached, bug title updated accordingly. Build with g++
> -c -fvisibility-inlines-hidden on alpha to see the fun.
Maybe
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Falk Hueffner a écrit :
>> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>>
>>>On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
>> On Alpha the problem is:
>> {standard input}: Assembler
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
On Alpha the problem is:
{standard input}: Assembler messages:
{standard input}:341: Error: macro requires $at register while noat in effect
{standard input}:374: Error: macro requires $at
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Petr Salinger <[EMAIL PROTECTED]> [2006-04-14 13:05]:
>> Does help to compile it with "-fwrapv" ?
>
> No.
Are you sure? It does for me.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Con
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> Yeah, I had an old file around that delta used instead. Below is a
> new test case. Falk, do you see this segfault?
Nope...
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
Martin Michlmayr <[EMAIL PROTECTED]> writes:
>> ../src/basemath/trans2.c: In function 'mpbern':
>> ../src/basemath/trans2.c:862: internal compiler error: Segmentation fault
I cannot reproduce this with 4.2.0 20060407 on
alphaev68-unknown-linux-gnu. So either it's target specific, or
already fixed
Martin Michlmayr <[EMAIL PROTECTED]> writes:
>> mn-sylpheed-mailbox-backend.c:301: internal compiler error: verify_ssa failed
>
> It builds just fine with 4.1
Since verify_ssa isn't called in release versions, this doesn't mean a
lot...
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROT
reassign 360479 steghide
thanks
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> reassign 360479 g++
> thanks
>
> I have now looked over the code and can not possibly find out that
> this is a fault in the code.
Uhm, reassining bugs to gcc if you don't understand the issue is not
the way to go. Pleas
Jörg Sommer <[EMAIL PROTECTED]> writes:
> I find this really, really confusing. What can I do to catch this
> bug?
Make a stand-alone testcase.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tags 350778 + unreproducible
tags 350778 + moreinfo
thanks
Hi,
I cannot reproduce this. Can you still? Seems more likely to be some
kind of corruption of your system.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTEC
tags 322723 + moreinfo
tags 322723 + unreproducible
thanks
Hi,
is this still reproducible with current 4.0 or 4.1? If so, how?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tags 350989 + unreproducible
tags 350989 + moreinfo
thanks
So. Does the same happen with newer versions like 4.0 or 4.1? And how
can it be reproduced?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tags 342245 + moreinfo
thanks
Hi,
can you please test this with a current gcc like 4.0 or 4.1?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> reassign 358644 autoconf
> thanks
>
> * Martin Michlmayr <[EMAIL PROTECTED]> [2006-03-23 17:32]:
>> Can someone please comment whether this is a compiler bug (I think
>> so) or whether autoconf needs to be changed.
>
> I talked to Andrew Pinski of GCC
forwarded 356435 http://gcc.gnu.org/PR26755
thanks
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> Falk, even without a minimal test case, do you think you can forward
> this upstream.
It seems Matthias has already forwarded it as PR 26755.
> I can also produce pregenerated code for xbsql (the p
Michael Weitzel <[EMAIL PROTECTED]> writes:
> Package: g++-4.0
> Version: 4.0.3-1
> Severity: normal
>
> g++ compiles the following wrong C++ code without complaining:
>
>#include
>class A {
>public:
> A() {}
>};
>
>int main()
>{
> std::complex bla(bla);
>
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Falk Hueffner <[EMAIL PROTECTED]> [2006-03-20 00:20]:
>> I mean 4.2 mainline. I don't know yet whether 4.1 mainline is fixed.
>> I'm pretty sure if it isn't already, it will get fixed.
>
> FWIW, I&#x
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Falk Hueffner <[EMAIL PROTECTED]> [2006-03-19 22:44]:
>> I can reproduce this with gcc-snapshot, but not with 4.2.0 20060304,
>> so it's probably fixed already, at least on mainline.
>
> If you can not reproduc
Hi,
I can reproduce this with gcc-snapshot, but not with 4.2.0 20060304,
so it's probably fixed already, at least on mainline.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
clone 356548 -1
reassign -1 par2cmdline
tags 356548 + upstream
forwarded 356548 http://gcc.gnu.org/PR26670
thanks
Ben Hutchings <[EMAIL PROTECTED]> writes:
> Martin Michlmayr wrote:
>> I don't understand the problem. Ben (CCed) made a suggestion, but
>> afaik he hasn't been able yet to come up w
[EMAIL PROTECTED] (Debian Bug Tracking System) writes:
> Processing commands for [EMAIL PROTECTED]:
>
>> reassign 356548 g++-4.1
If you understand what the problem is here, it would be nice if you
could create a useful test case instead of a 3 lines .ii file that
doesn't even compile on all a
Chris Howie <[EMAIL PROTECTED]> writes:
> Falk Hueffner wrote:
>> the fact that your program crashes in glibc memory manangement makes
>> it quite unlikely that this is a compiler bug. Can you try valgrind?
>> Also, your test case is quite large, would it be possible
reopen 338501
reassign 338501 octave
thanks
Timo Juhani Lindfors <[EMAIL PROTECTED]> writes:
> I just did apt-get update && apt-get dist-upgrade and octave seems
> to still die with illegal instruction
>
> so shouldn't but 338501 be reopened and assigned back to octave?
Oh, right. Let's do it.
tags 323016 + moreinfo
thanks
Both tin and sharutils seem to build now on m68k. Is this fixed?
Otherwise, is there a test case?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
the standard says:
A translation unit that includes a header shall not contain any
macros that define names declared or defined in that header.
So it's not generally disallowed to #define min/max, but rather there
should be only exactly two places checking for this, namely
and . The err
tags 347697 + moreinfo
thanks
Hi,
the fact that your program crashes in glibc memory manangement makes
it quite unlikely that this is a compiler bug. Can you try valgrind?
Also, your test case is quite large, would it be possible to get
something smaller?
--
Falk
--
To UNSUBSCRIBE, e
tags 344041 + moreinfo
thanks
Hi Stephen,
in #344046, you mention upstream is working on this. Can you give more
details? Is there a PR? A fix?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
I don't think these options are meaningful or should be documented.
Why would you want to use them?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reassign 334339 mysql-client
thanks
The internal compiler error has been fixed long ago, so reassigning to
mysql-client.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tags 348723 + moreinfo
thanks
Hi,
gcc-3.3 isn't supported upstream anymore. Can you please test with gcc
3.4?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reassign 348117 ncurses
severity 348117 normal
retitle 348117 Buffer overflow in example code c++/demo.cc
thanks
Thomas Dickey <[EMAIL PROTECTED]> writes:
> On Sun, 15 Jan 2006, Falk Hueffner wrote:
>
>> Thomas Dickey <[EMAIL PROTECTED]> writes:
>>
>>>
Thomas Dickey <[EMAIL PROTECTED]> writes:
> char buf[5];
[...]
> The buf variable contains "Key01"
So 6 bytes. Does this still happen if you don't overrun buf? Also,
can you send a complete test case?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "uns
Cem Vedat ISIK <[EMAIL PROTECTED]> writes:
> Hi all,
> I'm not really sure if here's the right place for this post, but I
> have a problem compiling my CGI apps with gcc ( version 4.0.2 20050808
> (prerelease) (Ubuntu 4.0.1-4ubuntu9) ) on Ubuntu. I've been using gcc
> version 4.0.3 20051201 (prere
Jurij Smakov <[EMAIL PROTECTED]> writes:
> The latest upload of icon (9.4.2-2.4) has failed to build on arm with
> the current gcc-4.0 in sid (4.0.2-5). After some investigation I've
> found that this is gcc-4.0 fault, and the build failures start with
> the version 4.0.1-7 (4.0.1-6 builds the sam
>> reassign 342545 libgcc2 4.0.2-5
> Bug#342545: qt-x11-free build fails
> Warning: Unknown package '4.0.2-5'
> Bug reassigned from package `4.0.2-5' to `libgcc2'.
Could you maybe summarize what the actual bug is and why it's
libgcc2's fault? The BTS trail is pretty convoluted.
--
Falk
Bill Allombert <[EMAIL PROTECTED]> writes:
> Package: g++-3.4
> Version: 3.4.5-1
> Severity: normal
>
> Hello Debian GCC maintainers,
>
> g++-3.4 incorrectly compiles the attached file at -O1 and up by causing
> an infinite loop.
This reduces to:
__attribute__ ((pure)) inline long f(void) {
Mathieu Malaterre <[EMAIL PROTECTED]> writes:
> Thanks Falk, you can close the bug. Updating binutils from unstable
> did the trick
Well, it shouldn't really be closed, but gcc-snapshot should depend on
that version.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subjec
Mathieu Malaterre <[EMAIL PROTECTED]> writes:
> Package: gcc-snapshot
> Version: 20051124-1
> Severity: important
>
> /tmp/ccFywWsc.s:2650: Error: unknown pseudo-op: `.weakref'
Newer binutils is needed. 2.16.1cvs20051109-1 should do. Can you
please try that?
--
Falk
--
To UNSUBSCRIBE
Vagner Pedrotti <[EMAIL PROTECTED]> writes:
> When I compile the following simple code, gcc fails with:
> /tmp/ccySlj9q.s: Assembler messages:
> /tmp/ccySlj9q.s:56: Error: missing or invalid immediate expression `'
> taken as 0
> /tmp/ccySlj9q.s:56: Error: suffix or operands invalid for `call'
Th
Justin Pryzby <[EMAIL PROTECTED]> writes:
> Please consider also warning on things like:
>
> if (0==c && 1==c)
How would this be different from -Wunreachable-code?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECT
Christian Hammers <[EMAIL PROTECTED]> writes:
> sql_analyse.cc: In member function 'virtual void field_longlong::add()':
> sql_analyse.cc:506: internal compiler error: in invert_exp_1, at jump.c:1719
Please provide the preprocessed source (.ii), as obtained by adding
-save-temps to the compil
Paul Brossier <[EMAIL PROTECTED]> writes:
> right, as vorlon pointed me on irc, the trick is not to use -O0, but to
> not use -msse, which is the flag producing buggy code.
There is no CPU that has SSE but no CMOV; therefore, I am not
convinced it is a bug in gcc that -msse enables cmov.
--
Drew Parsons <[EMAIL PROTECTED]> writes:
> Current gcc is 4.0.2-1. Is the segfault in xprint -12 something you
> might expect to occur, and would a rebuilt with gcc 4.0.2 be likely to
> repair it?
Not very likely, but it should definitely be done before trying
anything else. Trying gcc-snapshot w
Hi,
Very likely, this is the same as PR 24514, which has a patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00103.html
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Josh Triplett <[EMAIL PROTECTED]> writes:
> The sentinel attribute tells GCC to ensure that the argument list of a
> variadic function always ends with a final NULL argument. It should be
> possible to use this attribute for a variadic function where the
> sentinel is some constant other than NUL
Andrew Lenharth <[EMAIL PROTECTED]> writes:
> When performing integer division, the following relocation is generated (to
> the libc divide function)
> jsr $23,($27),__divq!lituse_jsrdirect!79
> the assembler does not understand this :
> /tmp/ccFszcSs.s: Assembler messages:
> /tmp/ccF
Michael Meskes <[EMAIL PROTECTED]> writes:
> dcopinterface_skel.cpp:51: internal compiler error: in cp_expr_size, at
> cp/cp-objcp-common.c:101
> Please submit a full bug report,
Please send the preprocessed source, as obtained by adding -save-temps.
--
Falk
--
To UNSUBSCRIBE, email
reopen 322565
thanks
Ari Pollak <[EMAIL PROTECTED]> writes:
> Does gimp actually build fine on arm with gcc 4.0, or are you just
> assuming that it builds fine because the buildd log said so? If you
> look at the changelog for gimp, it is currently using gcc 3.3 to
> build.
Oh, I missed that. Let
close 322565 4.0.1-4
thanks
gimp builds fine on arm now, so closing.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
close 319553 4.0.1-9
thanks
This is fixed in 4.0 now.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tags 329836 + moreinfo
thanks
Justin Pryzby <[EMAIL PROTECTED]> writes:
> cc -W -Wall -Winline -O6 -g -std=gnu99 -DPATH_SEP=\'/\' -Wl,-O6
> usnoquery.c libastro.a -lm -L/usr/lib -lcurl -lidn -lssl -lcrypto -ldl
> -lssl -lcrypto -ldl -lz -o usnoquery
> usnoquery.c:514: warning: 'write_data'
tags 330826 + patch
thanks
Hi,
actually, it wasn't patch's fault, but the problem was rather that the
patch was generated with -u2, which is as good as "don't use any
context at all", since by default patch ignores up to 2 lines of
context, so the patch gets inserted at a random place. I've attac
Matthias Klose <[EMAIL PROTECTED]> writes:
>> > retitle -1 [alpha] insane default of -mno-ieee instead of -mieee breaks
>> > many apps
>> Bug#330826: inkscape does not start
>> Changed Bug title.
>
> gcc-4.0 doesn't bootstrap with the patch making -mieee the
> default. Falk, any news?
The patch
reassign 328396 glibc
tags 328396 + moreinfo
thanks
Paul Taylor <[EMAIL PROTECTED]> writes:
> Package: libstdc++6 glibc
> Version: Latest
> Severity: important
> Description: Even after all the calls (recursive) to
> unlock a mutex pthread_rwlock_(rd/wr/un)lock() to
> where the rwlock variable s
Max Vozeler <[EMAIL PROTECTED]>, [EMAIL PROTECTED] schrieb am 12.09.05 13:48:41:
> On Mon, Sep 12, 2005 at 01:29:38PM +0200, Max Vozeler wrote:
> > I've been able to find a reduced testcase that shows the problem.
> > can find below the results using gcc-3.4 and gcc-4.0 with -O1/-O2 each.
> > The
"Wesley W. Terpstra" <[EMAIL PROTECTED]> writes:
> Package: gcc-4.0
> Version: 4.0.1-6
> Severity: important
>
> When compiling the fesetround function (which controls the processor
> rounding mode), gcc-4.0 incorrectly optimizes away the code!!!
>
> Here's the C code in question:
> __asm__ ("fs
tags 321415 + moreinfo
thanks
Hi,
the gcc PR 23080 has been closed. Can you confirm the problem is gone
with a newer gcc snapshot?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tags 320038 + moreinfo
thanks
Hi,
the gcc PR 23078 has been closed. Can you confirm the problem is gone
with a newer gcc snapshot?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Frans Pop <[EMAIL PROTECTED]> writes:
> I've reassigned this bug from the kernel to gcc-4.0 as we feel that the
> solution chosen in the kernel packaging is not really a fix, but a
> workaround.
> As tests have shown that the problem does not exist when the same kernel
> is compiled with gcc-3.
tags 318865 + moreinfo
thanks
Hi,
can this problem be still reproduced with a newer gcc version such as
4.0? Is it possible to make a standalone test case?
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 250 matches
Mail list logo
