Bug#1014091: armhf: gcc has wrong configuration

I think the problem is valgrind's Makefiles are passing -mcpu=cortex-a8 to the compiler. Cortex-a8 has Neon and the compiler now makes use of that. On the subject of the configuration of GCC --with-arch=armv7-a+fp *is* the correct configuration for the baseline GCC; it adds a vfpv3 with 16 dou

Re: ARM32 configury changes, with no FPU as a default

On 17/09/2021 11:23, Florian Weimer via Gcc wrote: * Matthias Klose: Starting with GCC 8, the configury allows to encode extra features into the architecture string. Debian and Ubuntu's armhf (hard float) architecture is configured with --with-arch=armv7-a --with-fpu=vfpv3-d16 and now s

Bug#971027: gcc-10: regression in 10.2.0-9 causes segmentation fault in vlc

On Wed, 30 Sep 2020, Ahzo wrote: > > Sep 29, 2020, 07:14 by rguent...@suse.de: > > > I've filed > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236 > > > > Someone needs to create a testcase or provide instructions how to > > reproduce the bug. > > > > Thanks for taking care of this issue upst

Bug#971027: gcc-10: regression in 10.2.0-9 causes segmentation fault in vlc

On Mon, 28 Sep 2020, Ahzo wrote: > Control: reassign -1 gcc-10 10.2.0-9 > Control: retitle -1 gcc-10: regression in 10.2.0-9 causes segmentation fault > in vlc > Control: affects -1 vlc > Control: severity -1 serious > > Hi, > > the vlc crash is caused by a compiler regression introduced in gcc

Bug#805820: -Wuninitialized provokes unexpected error with LTO

Package: g++-5 Version: 5.2.1-23 $ type g++-5 g++-5 is /usr/bin/g++-5 $ dpkg -l g++-5 libstdc++-5-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name

Bug#789369: iostream uninitialized data

Package: libstdc++6 Version: 5.1.1-11 richard@deodand:~/junk$ cat t.cc #include int main() { std::cout << std::hex; return 0; } richard@deodand:~/junk$ clang++-3.6 -fsanitize=undefined -O0 -fno-optimize-sibling-calls -fno-omit-frame-pointer -g -o t t.cc richard@deodand:~/junk$ ./t /u

Bug#751812: Incorrect fortify warning with -flto

to ‘__fread_chk_warn’ declared with attribute warning: fread called with bigger size * nmemb than length of destination buffer return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, __stream); ^ richard@deodand:~/src/vbig$ dpkg -l libc6-dev gcc-4.9 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/I

Bug#741543: When build for mips64el, the default target is mipsn32el

t time, but for compatibility reasons we need to use `...` rather than $(...). No need to repost the patch with that change -- I'll just make it locally before committing -- but please give an idea how it's been tested. Thanks, Richard -- To UNSUBSCRIBE, email to debian-gcc-requ...

Bug#741543: When build for mips64el, the default target is mipsn32el

a separate case statement, since it's orthogonal to the mips64octeon/mipsisa64r2 choice. With that change it looks good though. Thanks, Richard -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761n2eab2@sandifor-thinkpad.stglab.manchester.uk.ibm.com

Bug#741543: When build for mips64el, the default target is mipsn32el

Yunqiang Su writes: > I think so. > > Richard is the guy for upstream ? Hmm, this still looks multiarch-related to me. It looks like it's changing the default ABI for mips64-linux-gnu from n32 to n64. That might be right for a Debian multiarch environment but all upstream mips

Bug#686770: libstdc++.so.6: SegFault with mining app interfacing Radeon 7970 GPU to AMD's software

fc1c5a35000 r-xp 08:01 22931264 /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0 7fc1c5a35000-7fc1c5c34000 ---p 8000 08:01 22931264 /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0 7fc1c5c34000-7fc1c5c35000 rw-p 7000 08:01 22931264 /usr/lib/

Bug#633754: gcj-4.6: FTBFS on m68k with segfault

On Thu, Jul 14, 2011 at 06:47:28PM +, Thorsten Glaser wrote: > Richard dixit: > > >equiv_constant is called with NULL pointer, I would think this is > >illegal and the problem happened one level up : > > Probably. > > (gdb) frame 1 > #1 0x804b0542 in fold_r

Bug#633754: gcj-4.6: FTBFS on m68k with segfault

c/gcc/cse.c:3274 equiv_constant is called with NULL pointer, I would think this is illegal and the problem happened one level up : > #2 0x804b05fe in fold_rtx (x=0xc83c4f30, insn=0xc83cc1c0) at > ../../src/gcc/cse.c:3279 Richard --- Name and OpenPGP keys available from pgp key se

Bug#483069: Ghostscript error while running weekly cron job

$ pstotext /usr/share/doc/libstdc++6-4.3-doc/libstdc++/html/_form0.ps GPL Ghostscript 8.62: Unrecoverable error, exit code 1 ...specifically it is failing to open _form0.eps, which does not exist. However, _form0.eps.gz does exist. $ pwd /usr/share/doc/libstdc++6-4.3-doc/libstdc++/html $ ca

Bug#580496: Apparently depends on nonexistent gcc-4.4-doc

Vincent Lefevre wrote: I have no problems with: [..] This bug should probably be closed (or reassigned, if the problem is with some sources). Evidently someone has uploaded gcc-4.4-doc since I reported the bug l-) I agree that the bug can be closed. ttfn/rjk -- To UNSUBSCRIBE, email t

Bug#526620: Submitted upstream

I've submitted this upstream (having found that it exists in GCC 4.5.0 too). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511 ttfn/rjk -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http:/

Bug#580496: Apparently depends on nonexistent gcc-4.4-doc

Package: gcc-doc deodand:~# apt-get install gcc-doc Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some

Bug#526620: closed by Arthur Loiret (reply to aloi...@debian.org) (Re: Bug#526620: False positive from -Wreturn-type)

reopen 526620 quit Arthur Loiret wrote: 2009/12/24, Richard Kettlewell : This function's return type is required to be 'void *' because it is passed to pthread_create(); but it never actually returns. However, gcc-4.4 -Wall generates the following warning for it: playrtp

Bug#526620: closed by Arthur Loiret (reply to aloi...@debian.org) (Re: Bug#526620: False positive from -Wreturn-type)

reopen 526620 quit This function's return type is required to be 'void *' because it is passed to pthread_create(); but it never actually returns. However, gcc-4.4 -Wall generates the following warning for it: playrtp.c: In function ‘queue_thread’: playrtp.c:327: error: no return statement in

Bug#526620: False positive from -Wreturn-type

Hello, Matthias Klose wrote: please could you forward this upstream, and add the upstream link to the report? I was slightly surprised to receive this reply as the bug reporting instructions explicitly said I shouldn't do that: Don't file bugs upstream If you file a bug in Debian,

Bug#526620: False positive from -Wreturn-type

Package: gcc-4.4 Version: 4.4.0-1 I have the following code: static void *queue_thread(void attribute((unused)) *arg) { struct packet *p; for(;;) { /* Get the next packet */ pthread_mutex_lock(&receive_lock); while(!received_packets) { pthread_cond_wait(&receive_cond, &rec

Bug#523690: std::map<>::erase(map.end()) should be a no-op

, section 17.4.1.7, page 489, Stroustrup says simply "Erasing end() is harmless", which I interpret as "it has no effect". Cheers, Richard -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686)

Re: Status of GCC 4.4 (Debian)

this enormous amount of work, including filing high-quality bug-reports! Thanks, Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions

--- Comment #12 from richard dot guenther at gmail dot com 2007-11-08 09:08 --- Subject: Re: [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions On 11/7/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > This patch keeps recursive functions f

Ihanot received any response in regards the funds transfer Re urgently

¡Tengo nueva dirección de correo!Ahora puedes escribirme a: [EMAIL PROTECTED] - RICHARD OPENE

[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579

--- Comment #18 from richard at codesourcery dot com 2007-09-05 21:44 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 "ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes: > richard at codesourcery dot com wrote: >

[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579

--- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 "ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes: > My concern was that the bug only occurs

[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579

--- Comment #14 from richard at codesourcery dot com 2007-09-05 21:08 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 "ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes: >> I've not forced -EB because that

Bug#432460: gcc-4.1 (and gcc-4.1 multilib) *on amd64*: ld cannot find -lgcc_s when linking static libraries

Package: gcc-4.1 Version: 4.1.2-12 Severity: serious I am not a package maintainer but think that this might be of interest to you. There appears to be a problem when trying to link static libraries using gcc on Debian amd64. The linker tries to link gcc (statically?) and claims that it cannot fi

Bug#426587: gcc-4.1 compiled code links on x86, but not x86-64

Package: gcc-4.1 Version: 4.1.2-8 Severity: important Code that compiles/links fine on an x86 platform, using PIE fails to link on amd64 - looks like crt1.o wasn't built -fPIC on amd $ cc -g -Wall -O2 -fstack-protector-all -z relro -z now -fPIE -Wl,-z,relro -Wl,-z,now -Wl,-pie -Wl,--warn-shared-t

Bug#409752: g++: Fails to compile a very simple file

Subject: g++: Fails to compile a very simple file Package: g++ Version: 4.0.3-7 Severity: important Since an upgrade on Friday 02/02 (IIRC), I can't manage to compile a very simple program with g++: [EMAIL PROTECTED] /tmp/bug $ cat hello.cpp #include int main() { std::cout << "Hello world!"

Bug#392054: ginac: FTBFS on arm

Setting CXXFLAGS to -O instead of -O2 at least makde the package compile. (I don't suppose that g++-4.1_4.1.1-16 made a difference.) See -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsub

Bug#392054: arm-specific failure

put in the source package. Apparently, that was not the only failure. Note, that this time, a module compiled with -fPIC -DPIC, but not without it. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kr

Bug#390620: arm-specific ICE on valid code

rce as a gcc PR? If so, which number is it? -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390620: arm-specific ICE on valid code

ocessed source file and submit it upstream. I recommend doing that. -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#354700: gcc 4 does not notice C syntax error

Package: gcc Version: 4.0.2-5 This is what happens if you accidentally put a stray semicolon in a parameter-type-list: [EMAIL PROTECTED]:~$ cat > t.c int foo(int x;) { } [EMAIL PROTECTED]:~$ gcc-4.0 --version gcc-4.0 (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) Copyright (C) 2005

Bug#350778: gcc-4.0: corrupted error messages

Package: gcc-4.0 Version: 4.0.2-5 Severity: important gcc gives corrupted(?) error messages: % cat x.c void main() { x = 1; } % gcc x.c x.c: In function \u: x.c:4: error: \u undeclared (first use in this function) x.c:4: error: (Each undeclared identifier is reported only once x.c:

Bug#320240: g++ 4.0 doesn't compile ucontext.h on ia64

with it. If I compile my own version of 4.0.1 I have no such problem. - Richard -- Richard C. Bilson, Research Assistant | School of Computer Science [EMAIL PROTECTED] | University of Waterloo http://plg.uwaterloo.ca/~rcbilson | 200 University Avenue West Office: DC 3548F Ph:

Re: [patch] m68k extendqidi2 fix

On Wed, Mar 02, 2005 at 10:42:54AM +0100, Matthias Klose wrote: > Richard Zidlicky writes: > > Hi, > > > > the problem has been already discussed some time > > ago "upstream", now ocatve triggered the bug so > > it seems the fix should be backporte

[patch] m68k extendqidi2 fix

tml http://gcc.gnu.org/ml/gcc/2004-03/msg01007.html http://gcc.gnu.org/ml/gcc/2004-03/msg01011.html Attached patches, one per 3.3 and 3.4. I am leaving tomorrow so the patches are essentially untested although I have used very similar patch for 3.4 since almost a year. Richard --- gcc-3.3.1/gcc/c

Win XP Pr0f - $60 and all MS soft stuff

skater is RGK in katharine of beach to k's with reeve. carbonate am juneau going monogamous to 63159525 be rudy the butte you can now have Softw @ re out of your p0cket m0ney: http://hotmail.com.captive.mnlenekn.info/?nCpsVEn85ruMFTTpermute H!t the ab0ve l!ink now allotropic is

Bug#254831: gcc-3.3: [PR middle-end/15937] cannot bootstrap current mainline

Package: gcc-3.3 Version: 1:3.3.4-1 Severity: normal gcc-3.3.4-1 cannot bootstrap current mainline, it miscompiles gengtype. Upstream cannot reproduce the problem, so it may be debian patches to the 3.3.4 compiler that cause this problem. More detailled information in the gcc bugzilla database i

Re: Bug#246319: libcln3: Segfaults in cln::I_to_digits when converting numbers to binary

On Fri, 30 Apr 2004, I wrote: > I am not aware of a change in interface when turning off -fno-exception! > Is there one? Just for the record, let me answer my own question: No, there doesn't seem to be any change in interface. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

Re: Bug#246319: libcln3: Segfaults in cln::I_to_digits when converting numbers to binary

es > built by 3.3 and 3.4 are compatible. Okay, thanks for this assessment. The runtime libraries aren't compatible, as far as I know. This is even manifest from the bump in the library's soname: It's libstdc++.so.6 in GCC 3.4 vs. libstdc++.so.5 in GCC 3.[23]. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

Re: Bug#246319: libcln3: Segfaults in cln::I_to_digits when converting numbers to binary

On Wed, 28 Apr 2004, Steffen Röcker wrote: > libcln segfaulted in cln::I_to_digits when I tried to convert numbers to > binary, all other conversions worked. Thanks for your bugreport. This turns out to be a tricky one: libcln segfaults in src/integer/conv/cl_I_to_digits.cc:409, right after the

Re: 3.3.4 status, and some questions

> > I don't think there is a PR for it since the code in question does not > > provoke the bug on a vanilla FSF build. > > Now I'm confused. If the bug is not present in 3.3.3, then what is there > to backport? The bug is present, by inspection. > Or are you saying that the bug is present, bu

Re: 3.3.4 status, and some questions

needs a back-port of this change. However, it's not completely trivial since the code in question was a macro in arm.h for 3.3 whereas it's now a function in arm.c. 2004-02-25 Richard Earnshaw <[EMAIL PROTECTED]> * arm.c (arm_legitimate_index_p): For QImode the range of an

Re: [3.4/3.5 patch] libgcc_s.so compatibility between 3.3 and 3.4 (sjlj/dwarf2 exceptions)

On Mon, Feb 16, 2004 at 01:48:37AM +0100, Matthias Klose wrote: > * config.gcc: m68k-linux, parisc-linux: when not configured to > use sjlj exceptions, include t-make fragments to bump the libgcc > soversion number. > * config/t-slibgcc-elf-ver: Define SHLIB_NAME and SHLIB_S

Bug#227119: gcc-3.3: unwind.h not installed

Package: gcc-3.3 Version: 1:3.3.2-4 Severity: normal unwind.h should be in .../gcc-lib//

Bug#46550: 3rd time lucky?

Maybe I've send the right patch this time; it does at last actually correspond to the version that lets my code build. Apologies for faffing. Under the circumstances you'd better review the patch carefuly though l-) ttfn/rjk --- bastring.h.orig Sun Jun 8 22:47:05 2003 +++ bastring.h Sun J

Bug#46550: #46550 has re-appeared

Richard Kettlewell writes: > This bug has reappeared at some point in the intervening years (in > libstdc++2.10-dev 2.95.4-11woody now). > > Here's a patch to /usr/include/g++-3/std/bastring.h to put it back > right again. > > ttfn/rjk Sorry, stupid me, it should

Bug#46550: #46550 has re-appeared

reopen 46550 stop This bug has reappeared at some point in the intervening years (in libstdc++2.10-dev 2.95.4-11woody now). Here's a patch to /usr/include/g++-3/std/bastring.h to put it back right again. ttfn/rjk --- bastring.h.orig Sun Jun 8 22:47:05 2003 +++ bastring.h Sun Jun 8 22:47:

Bug#195796: libstdc++-v3 uses __attribute__((unknown)) again, instead of __attribute__((__unknown__))

n.org/fetch.php?&pkg=cln&ver=1.1.5-2&arch=mips&stamp=1054072270&file=log&as=raw> -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/>

Bug#179363: gcc-3.2-doc: misplaced paragraph in Constructing Calls node

(a) _a = (a); \ typeof (b) _b = (b); \ _a > _b ? _a : _b; }) Richard Braakman

Re: Bug#175526: Bug #175526

> ... > 5. Fix an ELF/m68k bug. important but probably not the solution for this problem. I will try bootstrapping an unpatched 3.2 release in my environment. Richard

Re: Bug #175526

ironment. seems to be the version used during the build as well. Haven't tested this version but the problems I mentioned were much older.. lets see what the new build does. Richard

Re: Bug #175526

h > glibc-2.3.1-9. I need to build gcc-3.2-3.2.2ds3 in the 1st stage > using with gcc-2.95, because debian gcc-3.2 cannot build itself! which binutils are used? Some older versions had bugs that were only triggered by gcc-3.2 Richard

Re: gcc-2.95 bugs on m68k: what to do ?

m68k > > (CCing the glibc people) > > Anything new here ? I hope you have fixed your mailer, last time I found no way to send you a reply. Richard

Re: c/7873: arm-linux-gcc fails when assigning address to a bit field

> On Wed, 2002-09-25 at 10:05, Richard Earnshaw wrote: > > > python2.3 now builds fine on arm-linux with this patch. It's not yet > > > checked into the 3.2 branch. > > > > Why on earth would a real application want to put part of a pointer into a > &g

Re: c/7873: arm-linux-gcc fails when assigning address to a bit field

> python2.3 now builds fine on arm-linux with this patch. It's not yet > checked into the 3.2 branch. Why on earth would a real application want to put part of a pointer into a bit-field? That sounds like it is highly non-portable. R.

Re: c/7873: arm-linux-gcc fails when assigning address to a bit field

c void foo (void) > { > yy.field1 = (unsigned int ) (&x0); > } Please try the following patch: 2002-09-10 Richard Earnshaw <[EMAIL PROTECTED]> * arm.md (insv): Use reg_or_int_operand for operand[3]. Index: arm.md

Bug#157292: g++: template function default arguments are not handled

plains there is no matching template function. Handled correctly by gcc-3.0. Richard. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux mickey 2.4.19 #1 Sat Aug 3 13:55:48 CEST 2002 i686 Locale: [EMAIL PROTECTED], LC_CTYPE= Versions of packages g++ depends on: ii cpp

Bug#152501: gcj-3.1: segfault with test case

; to "public class Main" will make the crash go away. Richard Braakman -- System Information: Debian Release: 3.0 Architecture: i386 Kernel: Linux night 2.4.7 #1 Thu Jun 27 13:02:24 EEST 2002 i686 Locale: LANG=C, LC_CTYPE=fi_FI.ISO8859-1 Versions of packages gcj-3.1 depends on: ii gc

Bug#149037: broken URLs in /usr/share/doc/gcc-3.0-base/C++/README.C++

Package: g++-3.0 Version: 3.0.4-7 Severity: wishlist /usr/share/doc/gcc-3.0-base/C++/README.C++ mentions a couple of non-working URLs: http://www.maths.warwick.ac.uk/cpp/pub/ http://www.sgi.com/Technology/STL/ ttfn/rjk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscri

Bug#134262: g++-3.0: Problem analyzed

Package: g++-3.0 Version: 1:3.0.4-6 The problem is both libGLU.so and libstdc++ contain the symbol __dynamic_cast which is used by gcc to apply the cast. Anytime the GLU one takes over, the SIGSEGVs occour (can be checked by LD_PRELOADing libGLU to any dynamic_cast using program!). So libGLU is c

Bug#134262: g++-3.0: Confirm removing -lGLU fixes this for additional SW package

Package: g++-3.0 Version: 1:3.0.4-6 I can confirm removing -lGLU from the link command line solves the same problem with the QGLViewer package (using Qt and GL - linking with GLU is from the tmake configuration). Note that this happens on a SuSE 7.2 system, too (g++ from HEAD of the gcc-3_0 branc

Bug#134262: g++-3.0: Confirmation of removing -lGLU fixes the problem

Package: g++-3.0 Version: 1:3.0.4-6 I can confirm the problem exists for the QGLViewer package (uses qt, pthreads, GL) - SIGSEGV at the first dynamic_cast. gcc 2.95.x do not have this problem. gcc-3_0 branch HEAD has the same problem. The SIGSEGVs vanish, if I remove -lGLU from the final link com

Bug#129613: gcj-3.0: segmentation fault on incorrect input

3 (i386-linux) compiled by GNU C version 3.0.3. Foo.java:2: Internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. Thanks, Richard Braakman -- System Information Deb

Bug#116823: Debian's g++-3.0 forgets to generate some code.

this bugreport. Thanks a lot to everyone who contributed insight! Cheers -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/>

Re: Bug#116823: Debian's g++-3.0 forgets to generate some code.

s (perhaps except > > for the module singleton), so removing global should be a local change > > inside each module only. > > Beware, use of nontrivial static local initialization is inherently > thread-unsafe without direct compiler support. Sure, but threads are

Re: Bug#116823: Debian's g++-3.0 forgets to generate some code.

eems to be > sufficient: the module.h logic also orders constructors with > translation-unit granularity, instead of object granularity. Hmm, I have observed the AIX linker doing rearrangements of modules of this kind and Bruno Haible claims he has / had a patch for GNU ld that does exac

Re: Bug#116823: Debian's g++-3.0 forgets to generate some code.

at the .init and .fini > sections shouldn't be used for constructors and destructors. For > constructors, .initarray should be used, to allow portable integration > of constructors across different compilers. Destructor sections should > not be used, instead, cxa_atexit won't be an option at some time in > the future. Aha. Thanks for that input! Regards -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/>

Bug#116823: Debian's g++-3.0 forgets to generate some code.

henever GCC-3.x is used. Hope this'll work for a couple of years... Thanx and cheers -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/>

Bug#116823: Debian's g++-3.0 forgets to generate some code.

's really needed.) // // These macros work only with g++, and only in optimizing mode. But who // wants to use CLN with other C++ compilers anyway... Regards -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/>

Bug#116823: Debian's g++-3.0 forgets to generate some code.

old enough for this, though.) Thanks a lot for all the input, anyways. Regards -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `-<http://www.ginac.de/~kreckel/>

Bug#116823: Debian's g++-3.0 forgets to generate some code.

_GLOBAL__I_module__prin_globals__firstglobalfun,@function _GLOBAL__I_module__prin_globals__firstglobalfun: .size _GLOBAL__I_module__prin_globals__firstglobalfun,.Lfe3-_GLOBAL__I_module__prin_globals__firstglobalfun .long _GLOBAL__I_module__prin_globals__firstglobalfun All this suggests that some ba

Bug#114795: gcc-3.0: Weird behaviour with -I/usr/include

On Sun, Oct 07, 2001 at 07:05:04PM -0400, Daniel Jacobowitz wrote: > On Sun, Oct 07, 2001 at 08:57:22PM +0200, Richard Atterer wrote: > > I encountered some very strange behaviour when using > > -I/usr/include. Obviously, it doesn't make much sense to supply > > this

Bug#114795: gcc-3.0: Weird behaviour with -I/usr/include

Package: gcc-3.0 Version: 1:3.0.1-0pre010811 Severity: normal Hello, I encountered some very strange behaviour when using -I/usr/include. Obviously, it doesn't make much sense to supply this switch on the command line, but in any case gcc's reaction is wrong. (I came across this because libwww-c

gcc compile troubles

ctory `/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5' make: *** [stamps/05-build-stamp-native] Error 2 is there something that I'm doing wrong? is there something that I need to install? any help would be greatly appreciated. Thanks Richard Reich

Re: gcc-3.0 update

.6MMail/debian/buildd-successful-200106 Unfortunately they're not getting back to the developers at the moment. Gerhard said that he had asked for appropriate lists at lists.debian.org, but I haven't seen them yet. I hope to have a chance this weekend to put them on the web (autom

Bug#100110: interactive postinst on gcc-3.0-base

Package: gcc-3.0-base Version: 3.0-0pre010526 postinst does a 'read', which causes problems for the installer when it feeds debootstrap stdin from /dev/null. Fix is apparently to not prompt if DEBIAN_FRONTEND=Noninteractive. Richard > On Tue, Jun 05, 2001 at 03:03:30PM +0100,