Package: gcc-3.2
Version: 1:3.2.1-0pre2
Severity: minor
Hi,
the s?addl and s?subl patterns don't work, as illustrated by these programs:
[EMAIL PROTECTED]:/tmp% cat test.c
int f(int x, int y) { return 4 * x + y; }
int g(int x) { return 3 * x; }
[EMAIL PROTECTED]:/tmp% gcc-3.2 -O3 -c test.c
[EMAI
Package: gcc-2.95
Version: 1:2.95.4-12
Severity: normal
"bool" from stdbool.h doesn't have proper semantics with 2.95:
[EMAIL PROTECTED]:/tmp% cat test.c
#include
#include
int main() {
bool b =3D 23;
if (b =3D=3D true)
puts("good");
else
puts("bad");
return 0;
Package: gcc-2.95
Version: 1:2.95.4-15
Severity: normal
[EMAIL PROTECTED]:/tmp% cat real4.c
void real_from_integer(void *s) {
__builtin_memset(s, 0, -1);
}
[EMAIL PROTECTED]:/tmp% gcc-2.95 -c real4.c
real
Matthias Klose <[EMAIL PROTECTED]> writes:
> tags 170994 + wontfix
> tags 170994 + fixed
> retitle 170994 [fixed in 3.x] ICE on __builtin_memset(s, 0, -1) (2.95 only)
> thanks
>
> marking this report as all other 2.95 reports. Is there a reason you
> cannot use gcc-3.2 for boostraps?
No, not rea
Package: gcc-3.2
Version: 1:3.2.2-0pre5
Severity: normal
The declaration
int x[2, 3];
is not legal in C99, since "2, 3" is not an assignment-expression.
However gcc accepts it without even a warning:
[EMAIL PROTECTED]:/tmp% cat test.c
int f() {
int x[2, 3];
}
[EMAIL
Hi,
here's a patch:
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02027.html
Falk
Hi,
looking at the preprocessed source clearly reveals that this is not a
gcc bug:
union {
struct id_ts {
n_time its_otime;
n_time its_rtime;
n_time its_ttime;
} id_ts;
struct id_ip {
struct ip idi_ip;
} id_ip;
u_long id_mask;
char id_data[1
[EMAIL PROTECTED] (Debian Bug Tracking System) writes:
> Processing commands for [EMAIL PROTECTED]:
>
> > retitle 186937 [fixed in 3.3] [hppa, PR target/10271] Floating point args
> > don't get reloaded across function calls at -O2
This is fixed in 3.2.3 too, I say we just close it.
--
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
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
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
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 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
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 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 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 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
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 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
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
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]
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 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 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
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]
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
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
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:
> 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:
> * 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
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
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
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
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
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]
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
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
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
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
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
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
retitle 320947 [PR 20624] invalid 'control reaches end of non-void function'
tags 320947 + upstream
forwarded 320947 http://gcc.gnu.org/PR20624
thanks
This is PR 20624.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTE
Blars Blarson <[EMAIL PROTECTED]> writes:
> Package: g++-4.0
> Version: 4.0.1-2
> Severity: important
>
> mysql-dfsg-4.1 fails to build on sparc due to a g++ interinal compiler
> error:
Please attach the preprocessed source as obtained by adding
-save-temps.
--
Falk
--
To UNSUBSCRIBE
Max Vozeler <[EMAIL PROTECTED]> writes:
> I can reproduce the problem in paer's sid chroot (hppa) and have put
> gcc-3.4 and gcc-4.0 builds with -save-temps on [1]. If there is
> other information that could be useful to you, please let me know.
It would be nice to know how to reproduce the probl
Steve Langasek <[EMAIL PROTECTED]>, [EMAIL PROTECTED] schrieb am 30.08.05
09:49:30:
> When passing pointers to 4-byte types to memcpy(), gcc-4.0 generates
> wrong code which assumes that these pointers are aligned at 4-byte
> boundaries for purposes of optimization, ignoring the implicit cast t
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]
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 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]
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]
"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
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
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
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
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
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'
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]
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]
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
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
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
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
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]
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
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.
--
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
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
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
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
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
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) {
>> 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
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
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
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
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:
>>
>>>
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 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]
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]
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]
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
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 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]
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.
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
[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
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
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]
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
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
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);
>
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
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
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
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
>
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.
--
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
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
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
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
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
1 - 100 of 250 matches
Mail list logo
