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

[richard]

  
/usr/lib/x86_64-linux-gnu/libatiadlxx.so
7fc1bdffd000-7fc1be00d000 rw-p  00:00 0 
7fc1be049000-7fc1be04a000 rw-s 00251000 00:05 8245   
/dev/ati/card0
7fc1be04a000-7fc1be0aa000 rw-s 0025 00:05 8245   
/dev/ati/card0
7fc1be0aa000-7fc1be0ea000 rw-s 0024f000 00:05 8245   
/dev/ati/card0
7fc1be0ea000-7fc1be7ea000 rw-s 0021d000 00:05 8245   
/dev/ati/card0
7fc1be7ea000-7fc1bfcb8000 r-xp  08:01 23683078   
/opt/AMDAPP/lib/x86_64/libamdocl64.so
7fc1bfcb8000-7fc1bfeb7000 ---p 014ce000 08:01 23683078   
/opt/AMDAPP/lib/x86_64/libamdocl64.so
7fc1bfeb7000-7fc1bffaa000 rw-p 014cd000 08:01 23683078   
/opt/AMDAPP/lib/x86_64/libamdocl64.so
7fc1bffaa000-7fc1c000 rw-p  00:00 0 
7fc1c000-7fc1c012 rw-p  00:00 0 
7fc1c012-7fc1c400 ---p  00:00 0 
7fc1c41c9000-7fc1c41cb000 r-xp  08:01 22929486   
/usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0
7fc1c41cb000-7fc1c43ca000 ---p 2000 08:01 22929486   
/usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0
7fc1c43ca000-7fc1c43cb000 rw-p 1000 08:01 22929486   
/usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0
7fc1c43cb000-7fc1c4537000 rw-p  00:00 0 
7fc1c4537000-7fc1c4577000 rw-s fde8 00:05 8245   
/dev/ati/card0
7fc1c4577000-7fc1c50be000 r-xp  08:01 22930157   
/usr/lib/x86_64-linux-gnu/libaticaldd.so
7fc1c50be000-7fc1c51be000 ---p 00b47000 08:01 22930157   
/usr/lib/x86_64-linux-gnu/libaticaldd.so
7fc1c51be000-7fc1c5259000 rw-p 00b47000 08:01 22930157   
/usr/lib/x86_64-linux-gnu/libaticaldd.so
7fc1c5259000-7fc1c5314000 rw-p  00:00 0 
7fc1c5314000-7fc1c531b000 r-xp  08:01 22930163   
/usr/lib/x86_64-linux-gnu/libatiuki.so.1.0
7fc1c531b000-7fc1c541b000 ---p 7000 08:01 22930163   
/usr/lib/x86_64-linux-gnu/libatiuki.so.1.0
7fc1c541b000-7fc1c541c000 rw-p 7000 08:01 22930163   
/usr/lib/x86_64-linux-gnu/libatiuki.so.1.0
7fc1c541c000-7fc1c541d000 rw-p  00:00 0 
7fc1c541d000-7fc1c54db000 r-xp  08:01 22978793   
/usr/lib/x86_64-linux-gnu/fglrx/fglrx-libGL.so.1.2
7fc1c54db000-7fc1c55db000 ---p 000be000 08:01 22978793   
/usr/lib/x86_64-linux-gnu/fglrx/fglrx-libGL.so.1.2
7fc1c55db000-7fc1c5602000 rwxp 000be000 08:01 22978793   
/usr/lib/x86_64-linux-gnu/fglrx/fglrx-libGL.so.1.2
7fc1c5602000-7fc1c5621000 rwxp  00:00 0 
7fc1c5621000-7fc1c5626000 r-xp  08:01 23683079   
/opt/AMDAPP/lib/x86_64/libOpenCL.so.1
7fc1c5626000-7fc1c5826000 ---p 5000 08:01 23683079   
/opt/AMDAPP/lib/x86_64/libOpenCL.so.1
7fc1c5826000-7fc1c5827000 rw-p 5000 08:01 23683079   
/opt/AMDAPP/lib/x86_64/libOpenCL.so.1
7fc1c5827000-7fc1c582b000 r-xp  08:01 22929771   
/usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
7fc1c582b000-7fc1c5a2b000 ---p 4000 08:01 22929771   
/usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
7fc1c5a2b000-7fc1c5a2c000 r--p 4000 08:01 22929771   
/usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
7fc1c5a2c000-7fc1c5a2d000 rw-p 5000 08:01 22929771   
/usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
7fc1c5a2d000-7fc1c5a35000 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/x86_64-linux-gnu/libXrandr.so.2.2.0
7fc1c5c35000-7fc1c5c9b000 r-xp  08:01 27312150   
/home/richard/test/Diablo/DiabloMiner/target/libs/natives/linux/liblwjgl64.so
7fc1c5c9b000-7fc1c5e9b000 ---p 00066000 08:01 27312150   
/home/richard/test/Diablo/DiabloMiner/target/libs/natives/linux/liblwjgl64.so
7fc1c5e9b000-7fc1c5e9d000 r--p 00066000 08:01 27312150   
/home/richard/test/Diablo/DiabloMiner/target/libs/natives/linux/liblwjgl64.so
7fc1c5e9d000-7fc1c5e9e000 rw-p 00068000 08:01 27312150   
/home/richard/test/Diablo/DiabloMiner/target/libs/natives/linux/liblwjgl64.so
7fc1c5e9e000-7fc1c5e9f000 r-xp  08:01 22915017   
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libjawt.so
7fc1c5e9f000-7fc1c609e000 ---p 1000 08:01 22915017   
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libjawt.so
7fc1c609e000-7fc1c609f000 rw-p  08:01 22915017   
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libjawt.so
7fc1c609f000-7fc1c60a2000 ---p  00:00 0 
7fc1c60a2000-7fc1c61a rw-p  00:00 0 
7fc1c61a-7fc1c61a5000 r-xp  08:01 22931247 

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

[Richard]

On Wed, Jul 13, 2011 at 12:30:17PM +, Thorsten Glaser wrote:
> Source: gcj-4.6
> Version: 4.6.1-2
> Severity: serious
> Justification: fails to build from source
> 

> 
> Running with -v -save-temps then (still in the cowbuilder chroot):
> 
> # gdb --args /tmp/buildd/gcj-4.6-4.6.1/build/./gcc/jc1 /tmp/ccNOJT3hjx 
> -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions 
> -fkeep-inline-functions -quiet -dumpbase ccNOJT3hjx -m68040 -m68040 
> -auxbase-strip java/.libs/util.o -g -O2 -Wno-deprecated -version 
> -ffilelist-file -fencoding=UTF-8 -fbootstrap-classes 
> -fsource-filename=/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/classpath/lib/classes
>  -fPIC -fbootclasspath=./:../../../../src/libjava/classpath/lib/ 
> -faux-classpath ccNOJT3hjx.zip -MD_ -MT java/util.lo -MF java/util.deps -o 
> ccNOJT3hjx.s
> 
> Program received signal SIGSEGV, Segmentation fault.
> equiv_constant (x=0x0) at ../../src/gcc/cse.c:3812
> 3812  if (REG_P (x)
> (gdb) bt
> #0  equiv_constant (x=0x0) at ../../src/gcc/cse.c:3812
> #1  0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at 
> ../../src/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 servers




-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110714122908.GA14475@rz

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

[Richard]

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_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at 
> ../../src/gcc/cse.c:3274
> 3274const_arg = equiv_constant (folded_arg);
> (gdb) list
> 3269
> 3270#ifdef HAVE_cc0
> 3271  case CC0:
> 3272folded_arg = prev_insn_cc0;
> 3273mode_arg = prev_insn_cc0_mode;
> 3274const_arg = equiv_constant (folded_arg);
> 3275    break;
> 3276#endif

what is "prev_insn"?

Richard

---
Name and OpenPGP keys available from pgp key servers




-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110715104855.GA32456@rz

Win XP Pr0f - $60 and all MS soft stuff

[Richard]

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 448546098 in ambuscade 
silversmith was cA going observatory to bathtub be distant a stricter
kindred  is a 331137028 of chalkboard into bess for blind 
sodden was apportion in the yeoman
neapolitan was 39608504 in indent 
regretful is oh for excoriate to uk below anaheim in emanate
butene  for a 304979640 once foil or majestic for spartan 
signal is midmorn for the brigantine

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

[Richard Biener]

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-10 version 
> 10.2.0-9, which was used to compile vlc 3.0.11.1-2.

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.

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

[Richard Biener]

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 upstream.
> 
> Sep 29, 2020, 15:18 by d...@debian.org:
> 
> > On 9/29/20 12:30 PM, Matthias Klose wrote:
> > upstream now has a reduced test case.
> >
> > 10.2.0-12 is uploaded, reverting that commit for now.
> >
> Thanks for the quick upload. This should prevent further fallout, until 
> upstream finds a better solution.

Note reverting just this rev will cause

long long x[24];
long long y[16];
long long z[8];

void __attribute__((noinline)) foo()
{
  for (int i = 0; i < 8; ++i)
{
  y[2*i] = x[3*i];
  y[2*i + 1] = x[3*i + 1];
  z[i] = 1;
}
}

to be miscompiled.  This in turn was triggered by the backport of
another fix, 1dbb919d0868319a5503b91049283a189ac1b4ac which I suggest
to revert as well then.

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

[Richard Earnshaw]

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 should be configured with

   --with-arch=armv7-a+fp

The --with-fpu configure option is deprecated.  The problem with this approach
is that there is no default for the fpu setting, while old compilers silently
pick up the -mfpu from the configured compiler.


FWIW, Fedora uses:

 --with-tune=generic-armv7-a --with-arch=armv7-a \
--with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux \

Not sure how it is impacted by this change.


This breaks software which explicitly configures things like
-march=armv7-a, or where the architecture string is embedded in the
source as an attribute.  So going from one place in the compiler about
configuring the ABI for a distro arch, this config now moves to some
dozen places in different packages.  Not the thing I would expect.


I don't know if we have seen such problems in Fedora.  I don't remember
any reports.



That's still using the now-deprecated --with-fpu option.  I want to 
remove that from GCC eventually in favour of the new way of adding the 
FP configuration as part of the architecture.  Recent versions of the 
Arm architecture do not document separate FPU versions, but just add 
features to the main architecture, so we need to move away from the old 
approach.


R.


Thanks,
Florian

Bug#1014091: armhf: gcc has wrong configuration

[Richard Earnshaw]

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 double-precision registers.  +vfpv3-fp16 would add support for
the float16 load/store operations, while +nosimd is a nop because no
other options have been added to enable SIMD.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[Richard Kettlewell]

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 "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard Braakman]

Package: gcj-3.1
Version: 1:3.1.1-0pre3
Severity: normal
Tags: upstream

(... sorry about the subject line, I couldn't think of any shorter way to
describe this than the test case itself)

Hello, I found code on which gcj crashes.  I reduced it to a minimal test
case, and in the process found a workaround, so I'm happy :)  But here's
the test case:

File Main.java:
import pkg.sub;

class Main {
public static void progressMessage(String msg) {
System.out.println(msg);
}

public static void main(String[] args) {
new sub();
}
}


File pkg/sub.java:
package pkg;

public class sub {
public sub() {
Main.progressMessage("Foo");
}
}


Compilation:
% gcj-3.1 -I. -c Main.java -o Main.o
% gcj-3.1 -I. -c pkg/sub.java -o pkg/sub.o
pkg/sub.java:5: 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.


I think the problem is also present upstream, because I got the same crash
with a non-debian version of gcj 3.1.  Changing "class Main" 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  gcc-3.11:3.1.1-0pre3 The GNU C compiler.
ii  gcc-3.1-base   1:3.1.1-0pre3 The GNU Compiler Collection (base 
ii  java-common0.14  Base of all Java packages
ii  libc6  2.2.5-7   GNU C Library: Shared libraries an
ii  libgcc11:3.1.1-0pre3 GCC support library.
ii  libgcj31:3.1.1-0pre3 Java runtime library for use with 
ii  libgcj3-dev1:3.1.1-0pre3 Java development headers and stati
ii  zlib1g 1:1.1.4-1 compression library - runtime

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard Guenther]

Package: g++
Version: 2:2.95.4-14
Severity: normal

g++ doesnt handle specifying a default argument to a specialized
template function which is done like

template 
void test(int j = 0);

template <>
void test<1>(int j);

calling test<1>() should work, but instead g++ complains 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  2:2.95.4-14 The GNU C preprocessor.
ii  g++-2.95 1:2.95.4-7  The GNU C++ compiler.
ii  gcc-2.95 1:2.95.4-7  The GNU C compiler.

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

[Richard Earnshaw]

> >How-To-Repeat:
> 
> /** Run "arm-linux-gcc -c" on this preprocessed segment : **/
> 
> 
> unsigned int  x0  = 0;
> 
> typedef struct {
>   unsigned int  field1 : 20;
>   unsigned int  field2 : 12;
> } XX;
> 
> static XX yy;
> 
> static 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
===
RCS file: /cvs/gcc/gcc/gcc/config/arm/arm.md,v
retrieving revision 1.104
diff -p -r1.104 arm.md
*** arm.md  29 Jul 2002 12:41:46 -  1.104
--- arm.md  10 Sep 2002 09:44:07 -
***
*** 1866,1872 
[(set (zero_extract:SI (match_operand:SI 0 "s_register_operand" "")
   (match_operand:SI 1 "general_operand" "")
   (match_operand:SI 2 "general_operand" ""))
! (match_operand:SI 3 "nonmemory_operand" ""))]
"TARGET_ARM"
"
{
--- 1866,1872 
[(set (zero_extract:SI (match_operand:SI 0 "s_register_operand" "")
   (match_operand:SI 1 "general_operand" "")
   (match_operand:SI 2 "general_operand" ""))
! (match_operand:SI 3 "reg_or_int_operand" ""))]
"TARGET_ARM"
"
{

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

[Richard Earnshaw]

> 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

[Richard Earnshaw]

> 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 
> > bit-field?  That sounds like it is highly non-portable.
> 
> I think Matthias is actually talking about a different bug.  The Python
> 2.3 build failure was caused by the problem with conditional returns
> having the wrong length attribute.
> 
> p.
> 

Then why did he quote the pointer-in-bitfield patch?

R.

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

[Richard Zidlicky]

On Tue, Oct 29, 2002 at 06:10:57PM +0100, Yann Dirson wrote:
> On Mon, Oct 21, 2002 at 09:43:05PM +0200, Matthias Klose wrote:
> > Yann Dirson writes:
> > > I have several packages (e2fsprogs, bigloo) that fail to build on
> > > m68k, apparently due to one or more gcc bug(s).  Maybe that's the same
> > > as #146006, and #89023, but I can't tell that myself.
> > > 
> > > Madkiss suggested forcing the use of gcc-3.2.  But if this compiler is
> > > officially broken on m68k, I'd rather not change those packages and
> > > have the autobuilders use gcc-3.2 at least for m68k...
> > > 
> > > What about changing build-essential list to make gcc-3.2 the default
> > > on m68k ?

would be the best solution imho.

> > AFAIK, the needed libgcc1-compat library is not yet built for 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: Bug #175526

[Richard Zidlicky]

On Wed, Jan 22, 2003 at 06:43:55AM +0900, GOTO Masanori wrote:
> > On Sun, Jan 19, 2003 at 07:48:04PM -0800, Jeff Bailey wrote:
> > > I haven't seen mention of it on this list, so I wanted to bring it up -
> > > Bug #175526 against glibc is m68k specific.  
> > 
> > interesting. I am running glibc-2.3 and gcc-3.2 without much problems 
> > here, will look if I can see something obvious.
> 
> I'm building m68k gcc over 11 days, and it's still testing...
> 
> The halfway result of build shows gcc-3.2-3.2.2ds3 is fine with
> 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: Bug #175526

[Richard Zidlicky]

On Fri, Jan 24, 2003 at 11:34:34AM +0900, GOTO Masanori wrote:

> > which binutils are used? Some older versions had bugs that were 
> > only triggered by gcc-3.2
> 
> At least I tested with binutils 2.13.90.0.16-1.
> But, I don't know the version number of the buildd environment.

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: Bug #175526

[Richard Zidlicky]

On Fri, Jan 24, 2003 at 02:28:31PM -0800, Jeff Bailey wrote:
 
> I don't know if it's significant, but upstream announced .18 today with
> the following changelog:
> 
> Changes from binutils 2.13.90.0.16:
>   
>   
...
> 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

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

[Richard Braakman]

Package: gcc-3.2-doc
Version: 1:3.2.2-0pre7
Severity: minor

The node (gcc-3.2.info.gz)"Constructing Calls", in "C Extensions",
has this paragraph at the end:

 The reason for using names that start with underscores for the local
  variables is to avoid conflicts with variable names that occur within
  the expressions that are substituted for `a' and `b'.  Eventually we
  hope to design a new form of declaration syntax that allows you to
  declare variables whose scopes start only after their initializers;
  this will be a more reliable way to prevent such conflicts.

This does not make sense in that node, which doesn't describe the
use of any local variables, with or without underscores.  The paragraph
seems to belong somewhere in the next node, "Typeof", which contains
this example:

 #define max(a,b) \
   ({ typeof (a) _a = (a); \
   typeof (b) _b = (b); \
 _a > _b ? _a : _b; })

Richard Braakman

Re: Status of GCC 4.4 (Debian)

[Richard Guenther]

On Sat, Sep 13, 2008 at 4:24 PM, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> Given that GCC moved to stage 3 recently, I decided to build the Debian
> archive to identify new issues before GCC 4.4 is released.  I compiled
> the entire Debian archive (just under 8000 packages that need to be
> compiled) on x86_64, ia64 and powerpc, and about 1800 packages on arm
> (EABI).  I also wanted to test GCC on alpha, mips and sparc but ran
> into compiler errors during bootstrap.
>
> In total, I filed 28 new bugs and ran into 7 known issues.  64% of the
> bugs I filed have already been fixed and many of those that are still
> open have already received some attention.  I'd like to thank the GCC
> community for such an oustanding job dealing with incoming bug reports
> and fixing compiler regressions.

And I'd like to thank you for doing 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#523690: std::map<>::erase(map.end()) should be a no-op

[Richard Atterer]

Package: libstdc++6
Version: 4.3.3-3
Severity: normal

Hello,

The std::map::erase(iterator) method in libstdc++6 cannot deal with the case 
that it is called with the end() iterator:

$ cat foo.cc
#include 
int main(int, char**) {
  std::map m;
  m[1] = 2;
  m[3] = 4;
  m.erase(m.find(5)); // 5 not found, so find() returns end()
}
$ g++ -O2 -Wall -o foo foo.cc
$ $ ./foo 
*** glibc detected *** ./foo: free(): invalid pointer: 0xbfc25c24 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6[0xb7cd81e4]
[snip backtrace]

I do not have a copy of the standard itself, but in C++ 3rd ed, 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)

Kernel: Linux 2.6.28.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libstdc++6 depends on:
ii  gcc-4.3-base  4.3.3-3The GNU Compiler Collection (base 
ii  libc6 2.9-4  GNU C Library: Shared libraries
ii  libgcc1   1:4.3.3-3  GCC support library

libstdc++6 recommends no packages.

libstdc++6 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526620: False positive from -Wreturn-type

[Richard Kettlewell]

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, &receive_lock);
}
p = received_packets;
received_packets = p->next;
if(!received_packets)
  received_tail = &received_packets;
--nreceived;
pthread_mutex_unlock(&receive_lock);
/* Add it to the heap */
pthread_mutex_lock(&lock);
pheap_insert(&packets, p);
nsamples += p->nsamples;
pthread_cond_broadcast(&cond);
pthread_mutex_unlock(&lock);
  }
}

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 function returning non-void

(It's shown here as an error since I always use -Werror, because many 
warnings actually indicate problems that really must be fixed.)


GCC 4.3 generates no such warning.

The underlying warning is -Wreturn-type, which is enabled by -Wall.  The 
documentation for this function hasn't changed since GCC 4.3 as far as I 
can see but evidently the behavior has - it now has a false positive 
which it previously did not.


I'd rather not just disable the warning from configure since it also can 
detect real errors.


ttfn/rjk




--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526620: False positive from -Wreturn-type

[Richard Kettlewell]

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, don't send a copy to the upstream
software maintainers yourself, as it is possible that the bug
exists only in Debian. If necessary, the maintainer of the
package will forward the bug upstream.

ttfn/rjk



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#483069: Ghostscript error while running weekly cron job

[Richard Kettlewell]

$ 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
$ cat _form0.ps
1 1 1 setrgbcolor
newpath
-1 -1 moveto
111 -1 lineto
111 14 lineto
-1 14 lineto
closepath
fill
-148 -654 translate
0 0 0 setrgbcolor
(_form0.eps) run
$ ls -l *form0*
-rw-r--r-- 1 root root 11768 2008-12-31 12:49 _form0.eps.gz
-rw-r--r-- 1 root root   150 2008-12-31 12:49 _form0.ps

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://lists.debian.org/4c8388f8.1060...@terraraq.org.uk

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

[Richard Kettlewell]

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 function returning non-void


This is expected behavior, your function is not of type void.


It is not expected behavior to anyone who has read the documentation for 
the option.


> Make your function return the NULL pointer to avoid the warning.

Sorry but this suggestion makes no sense.  The function never returns so 
suggesting it return a null pointer is meaningless.


ttfn/rjk



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Richard Kettlewell]

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.c: In function ‘queue_thread’:
playrtp.c:327: error: no return statement in function returning non-void

This is expected behavior, your function is not of type void.

It is not expected behavior to anyone who has read the documentation for
the option.


It is expected behavior, as you can see in gcc/c-decl.c:

  /* Complain if there's just no return statement.  */
  if (warn_return_type
  && TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
  && !current_function_returns_value && !current_function_returns_null
  /* Don't complain if we are no-return.  */
  && !current_function_returns_abnormally
  /* Don't warn for main().  */
  && !MAIN_NAME_P (DECL_NAME (fndecl))
  /* Or if they didn't actually specify a return type.  */
  && !C_FUNCTION_IMPLICIT_INT (fndecl)
  /* Normally, with -Wreturn-type, flow will complain, but we might
 optimize out static functions.  */
  && !TREE_PUBLIC (fndecl))
{
  warning (OPT_Wreturn_type,
   "no return statement in function returning non-void");
  TREE_NO_WARNING (fndecl) = 1;
}


You can't infer "expected" behavior by reading the source code.  That's 
what manuals are for.


It's also stupid behavior, as demonstrated by the example of a function 
that never returns.



Make your function return the NULL pointer to avoid the warning.


Sorry but this suggestion makes no sense.  The function never returns so
suggesting it return a null pointer is meaningless.


Right. Maybe your function just misses a call to pthread_exit (arg) then?


It's not missing anything.  The thread does not need to terminate.

Please stop closing this bug report.


Re your earlier question about GCC 4.3, yes there _is_ a difference:

rich...@deodand:~$ cat t.c
void *a(void) { for(;;); }
static void *b(void) { for(;;) { } }
rich...@deodand:~$ gcc-4.3 -Wall -c t.c
t.c:2: warning: ‘b’ defined but not used
rich...@deodand:~$ gcc-4.4 -Wall -c t.c
t.c: In function ‘b’:
t.c:2: warning: no return statement in function returning non-void
t.c: At top level:
t.c:2: warning: ‘b’ defined but not used

i.e. evidently GCC 4.3 was smart enough to spot that the warning didn't 
make sense in this kind of case; therefore GCC 4.4 should be able to do 
that too.


ttfn/rjk




--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Richard Kettlewell]

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 required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
  gcc-doc: Depends: gcc-4.4-doc (>= 4.4.4.nf1-1) but it is not installable
E: Broken packages
deodand:~# cat /etc/apt/sources.list
#
#  /etc/apt/sources.list
#

deb http://mirror/debian-local/ lenny main contrib non-free
deb http://mirror/debian-local/ sid main contrib non-free

deb http://debian.virginmedia.com/ sid main contrib non-free
deb-src http://debian.virginmedia.com/ sid main contrib non-free

deb http://ftp.uk.debian.org/debian sid main contrib non-free
deb-src http://ftp.uk.debian.org/debian sid main contrib non-free


#
#  Security updates
#
deb http://security.debian.org/ stable/updates  main contrib non-free
deb-src http://security.debian.org/ stable/updates  main contrib non-free


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://lists.debian.org/4be2ad52.80...@terraraq.org.uk

Bug#526620: Submitted upstream

[Richard Kettlewell]

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://lists.debian.org/4c149d14.3060...@terraraq.org.uk

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

[Richard Kettlewell]

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 to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1b61bf.3030...@greenend.org.uk

Bug#350778: gcc-4.0: corrupted error messages

[Richard Bradshaw]

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:4: error: for each function it appears in.)
x.c:3: warning: return type of \u is not \u


The \u didn't cut and paste very well on my terminal it is just a
funny box as if it was a binary or unprintable character.

I will also note that I grabbed gcc-4.1 from experimental and had the
exact same issue.

Rick


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages gcc-4.0 depends on:
ii  binutils 2.16.1cvs20051214-1 The GNU assembler, linker and bina
ii  cpp-4.0  4.0.2-5 The GNU C preprocessor
ii  gcc-4.0-base 4.0.2-5 The GNU Compiler Collection (base 
ii  libc62.3.5-8.1   GNU C Library: Shared libraries an
ii  libgcc1  1:4.1-0exp7 GCC support library

Versions of packages gcc-4.0 recommends:
ii  libc6-dev 2.3.5-8.1  GNU C Library: Development Librari
pn  libmudflap0-dev(no description available)

-- no debconf information


-- 
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

[Richard Kettlewell]

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 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There
  is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
  PURPOSE.

  [EMAIL PROTECTED]:~$ gcc-4.0 -c t.c
  [EMAIL PROTECTED]:~$ echo $?
  0

Earlier versions of GCC noticed the syntax error, though produced the
somewhat delphic "parameter "x" has just a forward declaration".

ttfn/rjk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Vincent Richard]

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!" << std::endl;
return 0;
}

[EMAIL PROTECTED] /tmp/bug $ g++ -o hello hello.cpp
as: symbol lookup error: /usr/lib/libbfd-2.17.so: undefined symbol:
_bfd_elf_#anonicalize_reloc

[EMAIL PROTECTED] /tmp/bug $ g++ --version
g++ (GCC) 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)

The same error occurs with g++ 4.1:

[EMAIL PROTECTED] /tmp/bug $ g++ --version
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

However, when compiling VMime (http://www.vmime.org), the following
error occurs (using SCons):

g++ -o build/debug/address.o -c -pipe -W -Wall -ansi -pedantic
-Wpointer-arith -Wold-style-cast -Wconversion -Wcast-align -g -O0
-D_REENTRANT=1 -I. src/address.cpp
as: symbol lookup error: /usr/lib/libbfd-2.17.so: undefined symbol:
_bfd_elf_#anonicalize_reloc
src/address.cpp:192: fatal error: error writing to -: Broken pipe
compilation terminated.
The bug is not reproducible, so it is likely a hardware or OS problem.
scons: *** [build/debug/address.o] Error 1
scons: building terminated because of errors.

No harware change, nor kernel change on my box, only a dist-upgrade
on the last Friday.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.4
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard Boyce]

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 find libgcc_s. This seems to be true
whether I use  the gcc-4.1-multilib packages or other gcc packages 
available for the and64 platform. Here is an

example for a simple program that uses libgd (attached)

% gcc -Wl,-Bstatic -lgd -o codehop-gr codehop-gr.c
/usr/bin/ld: cannot find -lgcc_s

The program compiles and works fine if I compile as follows:

% gcc -lgd -o codehop-gr codehop-gr.c

I have experienced the same problem when I remove the gcc-4.1 package 
and install gcc-4.1-multilib as well as when I have only gcc-3.3 
installed. This could be a problem for those who must link against 
projects that only have static libraries available.


Thanks for your hard work. -rdb

Here is some information that might be helpful; system information follows:

% ll `locate gcc`
-rwxr-xr-x 1 root root  839K 2007-07-09 11:59 
/opt/Downloads/gcc/gcc-3.3.6/gcc/32/libgcc_s.so.1
lrwxrwxrwx 1 root root16 2007-07-09 11:59 
/opt/Downloads/gcc/gcc-3.3.6/gcc/libgcc_s_32.so -> 32/libgcc_s.so.1
lrwxrwxrwx 1 root staff   13 2007-07-09 11:59 
/usr/local/lib64/libgcc_s.so -> libgcc_s.so.1

-rw-r--r-- 1 root staff 871K 2007-07-09 11:59 /usr/local/lib64/libgcc_s.so.1
lrwxrwxrwx 1 root staff   13 2007-07-09 11:59 
/usr/local/lib/libgcc_s_32.so -> libgcc_s.so.1

-rw-r--r-- 1 root staff 839K 2007-07-09 11:59 /usr/local/lib/libgcc_s.so.1
lrwxrwxrwx 1 root root13 2007-07-09 11:36 
/opt/Downloads/gcc/gcc-3.3.6/gcc/libgcc_s.so -> libgcc_s.so.1
-rwxr-xr-x 1 root root  871K 2007-07-09 11:36 
/opt/Downloads/gcc/gcc-3.3.6/gcc/libgcc_s.so.1
-rwxr-xr-x 1 root root  839K 2007-07-09 11:33 
/opt/Downloads/gcc/gcc-3.3.6/gcc/stage2/libgcc_s_32.so
-rwxr-xr-x 1 root root  871K 2007-07-09 11:33 
/opt/Downloads/gcc/gcc-3.3.6/gcc/stage2/libgcc_s.so
-rwxr-xr-x 1 root root  839K 2007-07-09 11:28 
/opt/Downloads/gcc/gcc-3.3.6/gcc/stage1/libgcc_s_32.so
-rwxr-xr-x 1 root root  871K 2007-07-09 11:28 
/opt/Downloads/gcc/gcc-3.3.6/gcc/stage1/libgcc_s.so
lrwxrwxrwx 1 root root18 2007-07-09 09:17 
/usr/lib/gcc/x86_64-linux-gnu/4.2/libgcc_s.so -> /lib/libgcc_s.so.1
lrwxrwxrwx 1 root root24 2007-07-09 08:59 
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/32/libgcc_s.so -> 
../../4.1/32/libgcc_s.so
lrwxrwxrwx 1 root root18 2007-07-09 08:59 
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/libgcc_s.so -> ../4.1/libgcc_s.so
lrwxrwxrwx 1 root root38 2007-07-09 08:59 
/usr/lib/gcc/x86_64-linux-gnu/4.1/32/libgcc_s.so -> 
/emul/ia32-linux/usr/lib/libgcc_s.so.1
lrwxrwxrwx 1 root root38 2007-07-09 08:59 
/usr/lib/gcc/x86_64-linux-gnu/4.1/libgcc_s_32.so -> 
/emul/ia32-linux/usr/lib/libgcc_s.so.1
lrwxrwxrwx 1 root root18 2007-07-09 08:59 
/usr/lib/gcc/x86_64-linux-gnu/4.1/libgcc_s.so -> /lib/libgcc_s.so.1
-rw-r--r-- 1 root root   41K 2007-07-07 13:27 
/emul/ia32-linux/usr/lib/libgcc_s.so.1

-rw-r--r-- 1 root root   55K 2007-07-07 13:27 /lib/libgcc_s.so.1


# ldconfig -p | grep gcc
   libstlport_gcc.so.4.6 (libc6,x86-64) => 
/usr/lib/libstlport_gcc.so.4.6

   libgccpp.so.1 (libc6,x86-64) => /usr/lib/libgccpp.so.1
   libgcc_s.so.1 (libc6,x86-64) => /lib/libgcc_s.so.1
   libgcc_s.so.1 (libc6) => /usr/lib32/libgcc_s.so.1
   libgcc_s.so (libc6,x86-64) => /usr/lib/libgcc_s.so

# dpkg -l gcc
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
uppercase=bad)

||/ Name Version  Description
+++---
ii  gcc  4.1.1-15 The GNU C compiler


-- System Information:
Debian Release: 4.0
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages gcc-4.1-multilib depends on:
ii  gcc-4.1 4.1.2-12 The GNU C compiler
ii  gcc-4.1-base4.1.2-12 The GNU Compiler Collection 
(base
ii  lib32gcc1   1:4.2-20070707-1 GCC support library (32 bit 
Versio
ii  libc6-dev-i386  2.6-1GNU C Library: 32bit 
development l


gcc-4.1-multilib recommends no packages.

-- no debconf information

#include 
#include "gd.h"
#include "gdfontg.h"

int main(void)
{
  /* Declare the image */
  gdImagePtr im;
  /* Declare output files */
  FILE *pngout;

  /* Declare color indexes */
  int black, white;
  int red, green, blue;

  /* Allocate the image: 64 pixels across by 64 pixels tall */
  im = gdImageCreate(900, 300);

  /* make white the first color */
  w

Ihanot received any response in regards the funds transfer Re urgently

[RICHARD OPENE]

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



- RICHARD OPENE

Bug#805820: -Wuninitialized provokes unexpected error with LTO

[Richard Kettlewell]

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   Version  Architecture Description
+++-==---=
ii  g++-5  5.2.1-23 i386 GNU C++ compiler
ii  libstdc++-5-de 5.2.1-23 i386 GNU Standard C++ Library v3
(deve
$ uname -a
Linux deodand 4.2.0-1-686-pae #1 SMP Debian 4.2.3-2 (2015-10-14) i686
GNU/Linux
$ cat t.cc
#include 
#include 

int main() {
  std::string a;
  std::regex r("x");
  return std::regex_match(a, r);
}
$ g++-5 -O2 -std=c++11 -Wuninitialized -c t.cc
$ g++-5 -O2 -std=c++11 -Wuninitialized -o t t.o
$ g++-5 -O2 -flto -fuse-linker-plugin -std=c++11 -Wuninitialized -c t.cc
$ g++-5 -O2 -flto -fuse-linker-plugin -std=c++11 -Wuninitialized -o t t.o
/usr/include/c++/5/bits/regex_compiler.tcc: In member function
‘_M_alternative’:
/usr/include/c++/5/bits/regex_compiler.tcc:266:8: warning: ‘__n’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
for (long __i = 0; __i < __n; ++__i)
^
/usr/include/c++/5/bits/regex_compiler.tcc:230:9: note: ‘__n’ was
declared here
long __n;
 ^

The relevant bit of regex_compiler.tcc looks OK to me so I think this is
the compiler rather than the std::regex implementation.  ICBW.

ttfn/rjk

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

[Richard Sandiford]

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 mips64-*-linux-gnu
configurations need to continue to use n32 as the default.  (The *gnuabin32*
stanza is Debian-local.)

Thanks,
Richard

> On Fri, Mar 21, 2014 at 9:59 AM, Matthias Klose  wrote:
>> Isn't that something unrelated to multiarch, and better should go upstream?
>>
>>   Matthias
>>
>> Am 13.03.2014 17:34, schrieb Yunqiang Su:
>>>
>>> Package: gcc-4.9
>>> Version: 4.9-20140303-1
>>>
>>> Hi, you lost a segment of patch in gcc-multiarch.diff for mips64(el), etc
>>>
>>> --- gcc-4.9-4.9-20140303.orig/src/gcc/config.gcc2014-03-13
>>> 16:27:17.509523462 +
>>> +++ gcc-4.9-4.9-20140303/src/gcc/config.gcc 2014-03-13
>>> 16:29:31.845902397 +
>>>
>>> @@ -1961,8 +1961,11 @@
>>>
>>>  tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
>>> glibc-stdint.h ${tm_file} mips/gnu-user.h mips/gnu-user64.h
>>> mips/linux64.h mips/linux-common.h"
>>>  extra_options="${extra_options} linux-android.opt"
>>>  tmake_file="${tmake_file} mips/t-linux64"
>>> -   tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
>>> +   tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_64"
>>>  case ${target} in
>>> +   *gnuabin32*)
>>> +   tm_defines=$(echo ${tm_defines}| sed
>>> 's/MIPS_ABI_DEFAULT=ABI_64/MIPS_ABI_DEFAULT=ABI_N32/g')
>>> +   ;;
>>>  mips64el-st-linux-gnu)
>>>  tm_file="${tm_file} mips/st.h"
>>>  tmake_file="${tmake_file} mips/t-st"
>>>
>>>
>>> See the gcc-multiarch.diff in gcc-4.8 for this patch.
>>>
>>> Thank your very much.
>>>
>>>
>>


-- 
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/877g7m62wi.fsf@talisman.default

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

[Richard Sandiford]

Yunqiang Su  writes:
> s/gnuabin64/gnuabi64/
>
> just a typo.
>
> --- gcc-4.9-4.9-20140322.orig/src/gcc/config.gcc2014-03-25
> 11:06:44.935298703 +
> +++ gcc-4.9-4.9-20140322/src/gcc/config.gcc 2014-03-25
> 11:07:39.087774543 +
> @@ -1963,6 +1963,9 @@
> tmake_file="${tmake_file} mips/t-linux64"
> tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
> case ${target} in
> +   *gnuabi64*)
> +   tm_defines=$(echo ${tm_defines}| sed
> 's/MIPS_ABI_DEFAULT=ABI_N32/MIPS_ABI_DEFAULT=ABI_64/g')
> +   ;;
> mips64el-st-linux-gnu)
> tm_file="${tm_file} mips/st.h"
> tmake_file="${tmake_file} mips/t-st"

I think the new code should be in 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

[Richard Sandiford]

Yunqiang Su  writes:
> --- gcc-4.9-4.9-20140322-new.orig/src/gcc/config.gcc2014-03-25
> 13:03:45.948992657 +
> +++ gcc-4.9-4.9-20140322-new/src/gcc/config.gcc 2014-03-25
> 13:06:12.314278663 +
> @@ -1963,6 +1963,11 @@
> tmake_file="${tmake_file} mips/t-linux64"
> tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
> case ${target} in
> +   *gnuabi64*)
> +   tm_defines=$(echo ${tm_defines}| sed
> 's/MIPS_ABI_DEFAULT=ABI_N32/MIPS_ABI_DEFAULT=ABI_64/g')
> +   ;;
> +   esac
> +   case ${target} in
> mips64el-st-linux-gnu)
> tm_file="${tm_file} mips/st.h"
> tmake_file="${tmake_file} mips/t-st"

Sorry, should have noticed this last 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...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/87wqficpf1@sandifor-thinkpad.stglab.manchester.uk.ibm.com

Bug#751812: Incorrect fortify warning with -flto

[Richard Kettlewell]

Package: gcc-4.9
Version: 4.9.0-6

$ cat t.c
#define _FORTIFY_SOURCE 2
#include 
#include 

long long size;

void execute(void) {
  unsigned char input[4096];
  size_t bytes = (size > (ssize_t)sizeof input
  ? sizeof input
  : size);
  size_t bytesRead = fread(input, 1, bytes, stdin);
}

int main(int argc, char **argv) {
  size = LLONG_MAX;
  execute();
  return 0;
}
$ gcc-4.9 -O2 t.c
$ gcc-4.9 -O2 -flto t.c
In function ‘__fread_alias’,
inlined from ‘execute’ at t.c:12:10:
/usr/include/i386-linux-gnu/bits/stdio2.h:290:2: warning: call 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/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  gcc-4.94.9.0-6  i386 GNU C compiler
ii  libc6-dev:i386 2.19-1   i386 Embedded GNU C Library: 
Developme


The relevant portion of stdio2.h is:

   266  extern size_t __fread_chk (void *__restrict __ptr, size_t __ptrlen,
   267 size_t __size, size_t __n,
   268 FILE *__restrict __stream) __wur;
   269  extern size_t __REDIRECT (__fread_alias,
   270(void *__restrict __ptr, size_t __size,
   271 size_t __n, FILE *__restrict __stream),
   272fread) __wur;
   273  extern size_t __REDIRECT (__fread_chk_warn,
   274(void *__restrict __ptr, size_t __ptrlen,
   275 size_t __size, size_t __n,
   276 FILE *__restrict __stream),
   277__fread_chk)
   278   __wur __warnattr ("fread called with bigger size * nmemb 
than length "

   279 "of destination buffer");
   280
   281  __fortify_function __wur size_t
   282  fread (void *__restrict __ptr, size_t __size, size_t __n,
   283 FILE *__restrict __stream)
   284  {
   285if (__bos0 (__ptr) != (size_t) -1)
   286  {
   287if (!__builtin_constant_p (__size)
   288|| !__builtin_constant_p (__n)
   289|| (__size | __n) >= (((size_t) 1) << (8 * sizeof 
(size_t) / 2)))
   290  return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, 
__stream);

   291
   292if (__size * __n > __bos0 (__ptr))
   293  return __fread_chk_warn (__ptr, __bos0 (__ptr), __size, 
__n, __stream);

   294  }
   295return __fread_alias (__ptr, __size, __n, __stream);
   296  }

The warning attribute is attached to __fread_chk_warn (called line 293) 
but the warning is issued against line 290 where __fread_chk is called - 
so the compiler has got confused about these two functions?


ttfn/rjk


--
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/539f5ae2.3020...@terraraq.org.uk

Bug#789369: iostream uninitialized data

[Richard Kettlewell]

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
/usr/bin/../lib/gcc/i586-linux-gnu/5.1.1/../../../../include/c++/5.1.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value for
type 'std::_Ios_Fmtflags'
/usr/bin/../lib/gcc/i586-linux-gnu/5.1.1/../../../../include/c++/5.1.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value for
type 'std::_Ios_Fmtflags'

As far as I can see the problem here is that ios_base::_M_flags is never
initialized.

ii  clang-3.6  1:3.6.1-1i386 C, C++ and Objective-C

ttfn/rjk


-- 
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/5585561f.9040...@greenend.org.uk

[patch] m68k extendqidi2 fix

[Richard Zidlicky]

Hi,

the problem has been already discussed some time
ago "upstream", now ocatve triggered the bug so
it seems the fix should be backported to 3.3

octave problem
  http://lists.debian.org/debian-68k/2005/02/msg00049.html

gcc discussion
  http://gcc.gnu.org/ml/gcc/2004-03/msg00940.html
  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/config/m68k/m68k.md.rzWed Mar  2 00:49:35 2005
+++ gcc-3.3.1/gcc/config/m68k/m68k.md   Wed Mar  2 01:06:29 2005
@@ -1750,11 +1750,20 @@
   "*
 {
   CC_STATUS_INIT;
-  operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]) + 1);
-  if (TARGET_68020 || TARGET_5200)
-return \"move%.b %1,%2\;extb%.l %2\;smi %0\;extb%.l %0\";
+  if (ADDRESS_REG_P(operands[1]))
+{
+  if (TARGET_68020 || TARGET_5200)
+return \"move%.w %1,%R0\;extb%.l %R0\;smi %0\;extb%.l %0\";
+  else
+return \"move%.w %1,%R0\;ext%.w %R0\;ext%.l %R0\;move%.l %R0,%0\;smi 
%0\";
+}
   else
-return \"move%.b %1,%2\;ext%.w %0\;ext%.l %2\;move%.l %2,%0\;smi %0\";
+{
+  if (TARGET_68020 || TARGET_5200)
+return \"move%.b %1,%R0\;extb%.l %R0\;smi %0\;extb%.l %0\";
+  else
+return \"move%.b %1,%R0\;ext%.w %R0\;ext%.l %R0\;move%.l %R0,%0\;smi 
%0\";
+}
 }")
 
 (define_insn "extendhidi2"
--- gcc-3.4-20040218/gcc/config/m68k/m68k.md.rz Wed Mar  2 00:17:11 2005
+++ gcc-3.4-20040218/gcc/config/m68k/m68k.mdWed Mar  2 00:21:36 2005
@@ -1454,11 +1454,20 @@
   ""
 {
   CC_STATUS_INIT;
-  operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]) + 1);
-  if (TARGET_68020 || TARGET_COLDFIRE)
-return "move%.b %1,%2\;extb%.l %2\;smi %0\;extb%.l %0";
+  if (ADDRESS_REG_P(operands[1]))
+{
+  if (TARGET_68020 || TARGET_COLDFIRE)
+return "move%.w %1,%R0\;extb%.l %R0\;smi %0\;extb%.l %0";
+  else
+return "move%.w %1,%R0\;ext%.w %R0\;ext%.l %R0\;move%.l %R0,%0\;smi 
%0";
+}
   else
-return "move%.b %1,%2\;ext%.w %0\;ext%.l %2\;move%.l %2,%0\;smi %0";
+{
+  if (TARGET_68020 || TARGET_COLDFIRE)
+return "move%.b %1,%R0\;extb%.l %R0\;smi %0\;extb%.l %0";
+  else
+return "move%.b %1,%R0\;ext%.w %R0\;ext%.l %R0\;move%.l %R0,%0\;smi 
%0";
+}
 })
 
 (define_insn "extendhidi2"

Re: [patch] m68k extendqidi2 fix

[Richard Zidlicky]

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 backported to 3.3
> > 
> > octave problem
> >   http://lists.debian.org/debian-68k/2005/02/msg00049.html
> 
> that message has another (.extbf) patch in it.

that one fixes an unrelated case where invalid assembly
is generated. Should be safe wherever it applies cleanly..
and extremely unlikely to hit.

> 
> I'm applying the patch for 3.4 now, debian-m68k, should the patch
> applied without testing to 3.3 as well? 

I think so, constraints are unchanged so all effects are
local to this instruction pattern - and generated code
differs only in the obviously incorrect cases. 

Richard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#46550: #46550 has re-appeared

[Richard Kettlewell]

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:11 2003
@@ -335,7 +335,7 @@
 
 public:
   const charT* c_str () const
-{ const charT* null_str = ""; 
+{ static const charT null_str[];
   if (length () == 0) return null_str; terminate (); return data (); }
   void resize (size_type n, charT c);
   void resize (size_type n)

Bug#46550: #46550 has re-appeared

[Richard Kettlewell]

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 be:-

--- bastring.h.orig Sun Jun  8 22:47:05 2003
+++ bastring.h  Sun Jun  8 22:47:11 2003
@@ -335,7 +335,7 @@
 
 public:
   const charT* c_str () const
-{ const charT* null_str = ""; 
+{ static const charT null_str[1];
   if (length () == 0) return null_str; terminate (); return data (); }
   void resize (size_type n, charT c);
   void resize (size_type n)

Bug#46550: 3rd time lucky?

[Richard Kettlewell]

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 Jun  8 23:10:14 2003
@@ -335,7 +335,7 @@
 
 public:
   const charT* c_str () const
-{ const charT* null_str = ""; 
+{ static const charT null_str[] = { 0 };
   if (length () == 0) return null_str; terminate (); return data (); }
   void resize (size_type n, charT c);
   void resize (size_type n)

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

[Richard Henderson]

Package: gcc-3.3
Version: 1:3.3.2-4
Severity: normal

unwind.h should be in .../gcc-lib//

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

[Richard Hirst]

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, Richard Hirst wrote:
> > I have a problem with this; my gcc-3.0-base.deb has a postinst
> > with a "read foo" in it, and a first line of "#!/bin/sh -e".
> > That -e causes the script to exit with code 1 when the read
> > fails (which it does, when directed from /dev/null).  That
> > causes the postinst to fail, and debootstrap never manages
> > to get all packages configured.
> 
> Check for DEBIAN_FRONTEND=Noninteractive, and don't prompt if it's set
> like that.
> 
> Cheers,
> aj

Re: gcc-3.0 update

[Richard Higson]

On Thu, Jun 14, 2001 at 04:45:58PM -0400, Matt Zimmerman wrote:
> Date: Thu, 14 Jun 2001 16:45:58 -0400
> From: Matt Zimmerman <[EMAIL PROTECTED]>
> To: debian-gcc@lists.debian.org, debian-s390@lists.debian.org
> Subject: Re: gcc-3.0 update
> 
> On Mon, Jun 11, 2001 at 09:23:45AM +0200, Matthias Klose wrote:
> 
> > Yesterday I uploaded new gcc-3.0 packages. Close before the gcc
> > release I'd like to check the status of the Debian architecutres:
> > [...]
> > s390- status unknown, no build reports upstream (May, June)
> 
> I'll do some work on this in the next day or two, and see if I can get it
> going.
The s390 autobuilder is picking up speed, and produces build-reports.
[EMAIL PROTECTED]:~ $ du -H Mail/debian/buildd-*
705kMail/debian/buildd-failed-200106
111kMail/debian/buildd-given-back-200106
2.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 (automaticly), 
so that developers can see what's happened to their packages.

Richard
-- 
Unix:Your gun, Your bullet, Your foot, Your choice.
M$-CE/ME/NT: Same as Unix, BUT: No choice, and We Aim Higher.
Have a nice day ;-) Richard Higson mailto:[EMAIL PROTECTED]

gcc compile troubles

[Richard Reich]

Debian GCC maintainers,

I'm trying to build gcc on my home box, I did apt-get source gcc and also got a 
few others, I also did apt-get build-dep gcc.  I'm still getting an error.

the command I execute to compile gcc is...
./debian/rules

here is a copy and paste of what is happening...

make[5]: Leaving directory 
`/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native/i386-linux/libchill'
make[4]: Leaving directory 
`/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native/i386-linux/libchill'
make[4]: Entering directory 
`/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native/i386-linux/libobjc'
/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native/gcc/xgcc 
-B/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native
/gcc/ -B/usr/i386-linux/bin/ -fgnu-runtime -c -o gc_gc.o -I. 
-I/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc
-DIN_GCC -I/usr/include/gc -DOBJC_WITH_GC=1 \

-I/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc/objc  
-I/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.
95.4.ds5/src-native/libobjc/../gcc 
-I/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc/../gcc/config 
-I../../gcc
 -I/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc/../include 
/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src
-native/libobjc/gc.c
/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc/gc.c:37: gc.h: 
No such file or directory
/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/src-native/libobjc/gc.c:55: 
gc_typed.h: No such file or directory
make[4]: *** [gc_gc.o] Error 1
make[4]: Leaving directory 
`/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native/i386-linux/libobjc'
make[3]: *** [all-target-libobjc] Error 2
make[3]: Leaving directory 
`/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native'
make[2]: *** [bootstrap-lean] Error 2
make[2]: Leaving directory 
`/smb/gcc_bench/gcc2.95.4/gcc-2.95-2.95.4.ds5/build-native'
s=`cat status`; rm -f status; test $s -eq 0
make[1]: *** [stamps/05-build-stamp-native] Error 1
make[1]: Leaving directory `/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

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

[Richard Atterer]

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-config happens to include -I/usr/include in its
--cflags output.)

> echo '#include ' >x.cc 
> touch string.hh
> g++-3.0 -I/usr/include -c x.cc -o x.o
In file included from /usr/include/g++-v3/bits/char_traits.h:39,
 from /usr/include/g++-v3/bits/std_string.h:41,
 from /usr/include/g++-v3/string:31,
 from x.cc:1:
/usr/include/g++-v3/bits/std_cstring.h:40:25: string.h: No such file or 
directory
In file included from /usr/include/g++-v3/bits/char_traits.h:39,
 from /usr/include/g++-v3/bits/std_string.h:41,
 from /usr/include/g++-v3/string:31,
 from x.cc:1:
/usr/include/g++-v3/bits/std_cstring.h:68: `memcpy' not declared
/usr/include/g++-v3/bits/std_cstring.h:69: `memmove' not declared
/usr/include/g++-v3/bits/std_cstring.h:70: `strcpy' not declared
/usr/include/g++-v3/bits/std_cstring.h:71: `strncpy' not declared
/usr/include/g++-v3/bits/std_cstring.h:72: `strcat' not declared
/usr/include/g++-v3/bits/std_cstring.h:73: `strncat' not declared
[...]

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux elessar 2.2.19 #1 Mon May 21 19:42:05 CEST 2001 i686
Locale: LANG=C, LC_CTYPE=de_DE

Versions of packages gcc-3.0 depends on:
ii  binutils  2.11.90.0.31-1 The GNU assembler, linker and bina
ii  cpp-3.0   1:3.0.1-0pre010811 The GNU C preprocessor.
ii  gcc-3.0-base  1:3.0.1-0pre010811 The GNU Compiler Collection (base 
ii  libc6 2.2.4-1GNU C Library: Shared libraries an
ii  libgcc1   1:3.0.1-0pre010811 GCC support library.

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

[Richard Atterer]

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 switch on the command line, but in any case gcc's reaction is
> > wrong. (I came across this because libwww-config happens to
> > include -I/usr/include in its --cflags output.)
> 
> That's a bug in libwww-config; please file it.

No need - I think I'll adopt libwww from Takuo KITAME... :)

> It's documented in the gcc manual that you should not do this. 
> Somewhere. I don't immediately see where :(

I've found it in the node "Interoperation":

   * Use of `-I/usr/include' may cause trouble.

 Many systems come with header files that won't work with GCC
 unless corrected by `fixincludes'. The corrected header files go
 in a new directory; GCC searches this directory before
 `/usr/include'. If you use `-I/usr/include', this tells GCC to
 search `/usr/include' earlier on, before the corrected headers. 
 The result is that you get the uncorrected header files.

 Instead, you should use these options (when compiling C programs):

  -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include

 For C++ programs, GCC also uses a special directory that defines
 C++ interfaces to standard C subroutines. This directory is meant
 to be searched _before_ other standard include directories, so
 that it takes precedence. If you are compiling C++ programs and
 specifying include directories explicitly, use this option first,
 then the two options above:

  -I/usr/local/lib/g++-include

That explanation doesn't quite make sense for this bug - surely the
headers in /usr/include do not need to be corrected by "fixincludes"?! 
Furthermore, notice the weird circumstances necessary to provoke it; a
file named _string.hh_ (NOT string.h) in the _current_ directory:

> echo '#include ' >x.cc 
> touch string.hh
> g++-3.0 -I/usr/include -c x.cc -o x.o

Also, libstdc++3-dev doesn't provide any string.h file which could
override /usr/include/string.h. I believe this bug is unrelated to
what the info manual talks about.

(BTW, the above works fine with gcc-2.95.)

Bye,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer
  | \/¯|  http://atterer.net
  ¯ ´` ¯

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

[Richard Braakman]

Package: gcj-3.0
Version: 1:3.0.3-1
Severity: minor

I got gcj to segfault:

% gcj Foo.java 
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.

The contents of Foo.java are:

public class Foo {
private foo;
}

Notive how the type of field foo is missing.  gcj should report an
error for this file, but it shouldn't crash.  It happens somewhere
in java_parse().  I don't have more information because building
a version with debugging symbols was too fiddly and frustrating.

Oh, I did run gcj -v as well:

%  gcj -v Foo.java 
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.3/specs
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.3/../../../libgcj.spec
rename spec lib to liborig
rename spec startfile to startfileorig
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr 
--infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as 
--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls 
--without-included-gettext --disable-checking --enable-threads=posix 
--enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.0.3
 /usr/lib/gcc-lib/i386-linux/3.0.3/jc1 Foo.java -fuse-divide-subroutine 
-fuse-boehm-gc -fnon-call-exceptions -quiet -dumpbase Foo.java -g1 -version -o 
/tmp/cc3pjnYN.s
GNU Java version 3.0.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
Debian Release: 3.0
Architecture: i386
Kernel: Linux night 2.4.7 #1 Wed Aug 1 21:44:11 EEST 2001 i686
Locale: LANG=C, LC_CTYPE=fi_FI.ISO8859-1

Versions of packages gcj-3.0 depends on:
ii  gcc-3.0   1:3.0.3-1  The GNU C compiler.
ii  gcc-3.0-base  1:3.0.3-1  The GNU Compiler Collection (base 
ii  java-common   0.7Base of all Java packages
ii  libc6 2.2.4-7GNU C Library: Shared libraries an
ii  libgcj2-dev   1:3.0.3-1  Java development headers and stati
ii  zlib1g1:1.1.3-18 compression library - runtime

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

[Richard Guenther]

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 command.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux pulli 2.4.18 #1 Tue Mar 19 10:38:02 CET 2002 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages g++-3.0 depends on:
ii  gcc-3.0   1:3.0.4-6  The GNU C compiler.
ii  gcc-3.0-base  1:3.0.4-6  The GNU Compiler Collection (base 
ii  libc6 2.2.5-4GNU C Library: Shared libraries an
ii  libstdc++3-dev1:3.0.4-6  The GNU stdc++ library version 3 (



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard Guenther]

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 branch, GLU from xf86glu-4.0.99.1-34). g++ 2.95.3 does not
exhibit this problem.

I didnt find anything on GNATS - did anyone report this problem to
upstream already?

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux wolf 2.4.18 #3 SMP Mon Mar 25 13:19:38 CET 2002 i686
Locale: LANG=C, [EMAIL PROTECTED]

Versions of packages g++-3.0 depends on:
ii  gcc-3.0   1:3.0.4-6  The GNU C compiler.
ii  gcc-3.0-base  1:3.0.4-6  The GNU Compiler Collection (base 
ii  libc6 2.2.5-4GNU C Library: Shared libraries an
ii  libstdc++3-dev1:3.0.4-6  The GNU stdc++ library version 3 (



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard Guenther]

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 compiled statically against a different
libstdc++ and the __dynamic_cast symbol in GLU should not be
exported. objcopy -L could be used to achieve the latter.


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux wolf 2.4.18 #3 SMP Mon Mar 25 13:19:38 CET 2002 i686
Locale: LANG=C, [EMAIL PROTECTED]

Versions of packages g++-3.0 depends on:
ii  gcc-3.0   1:3.0.4-6  The GNU C compiler.
ii  gcc-3.0-base  1:3.0.4-6  The GNU Compiler Collection (base 
ii  libc6 2.2.5-4GNU C Library: Shared libraries an
ii  libstdc++3-dev1:3.0.4-6  The GNU stdc++ library version 3 (



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard Henderson]

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_SONAME
>   in terms of SHLIB_SOVERSION.
>   * config/m68k/t-slibgcc-elf-ver: Bump shlib soversion number.
>   * config/pa/t-slibgcc-elf-ver: Likewise.

Applied to 3.4 and HEAD.


r~

Re: 3.3.4 status, and some questions

[Richard Earnshaw]

> On Fri, 2004-03-12 at 06:38, Matthias Klose wrote:
> > > - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?
> > 
> > CCed Phil Blundell
> 
> No.  The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this
> was a different bug.  I don't think we had a PR filed for the XFree86
> thing.
> 
> p.
> 
> 

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.

In fact, the patch for that bug hasn't been installed on the 3.3 branch 
yet.  It 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 offset
is -4095...+4095 inclusive.

Phil, were you going to commit the back-port you had done?

R.

Re: 3.3.4 status, and some questions

[Richard Earnshaw]

> > 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, but that this
> particular testcase doesn't tweak the bug because of some other difference
> between Debian's gcc and ours?

That seems to be the case.

R.

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

[Richard Guenther]

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 in
PR15937.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64
Kernel: Linux 2.6.4-mckinley-smp
Locale: LANG=C, LC_CTYPE=C

Versions of packages gcc-3.3 depends on:
ii  binutils2.14.90.0.7-8The GNU assembler, linker and bina
ii  cpp-3.3 1:3.3.4-1The GNU C preprocessor
ii  gcc-3.3-base1:3.3.4-1The GNU Compiler Collection (base 
ii  libc6.1 2.3.2.ds1-13.0.1 GNU C Library: Shared libraries an
ii  libgcc1 1:3.3.4-1GCC support library

-- no debconf information

Bug#390620: arm-specific ICE on valid code

[Richard B. Kreckel]

Package: g++-4.1
Version: 4.1.1-10

According to
<http://buildd.debian.org/fetch.php?&pkg=ginac&ver=1.3.5-1&arch=arm&stamp=1155852602&file=log&as=raw>, 
the current GiNaC package FTBFS on arm.


With access to an arm system, it will be very easy to gather the
preprocessed 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#390620: arm-specific ICE on valid code

[Richard B. Kreckel]

Matthias Klose wrote:


as a workaround, the file compiles without "-finline-limit=1200"



Thank you. I've changed debian/rules to not add this compiler option on arm.

Still, since you have apparently tried compiling it on an arm system: 
have you submitted the preprocessed source 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#392054: arm-specific failure

[Richard B. Kreckel]

Package: g++-4.1
Version: 4.1.1-15

According to
<http://buildd.debian.org/fetch.php?&pkg=ginac&ver=1.3.5-2&arch=arm&stamp=1160247427&file=log>
the current GiNaC package FTBFS on arm.

This is after the workaround for another arm-specific failure (c.f.
Bug#390620) was 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/~kreckel/>



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#392054: ginac: FTBFS on arm

[Richard B. Kreckel]

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 "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard C Bilson]

Package: gcc-4.0
Version: 4.0.1-2

$ g++ -v
Using built-in specs.
Target: ia64-linux-gnu
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls 
--without-included-gettext --enable-threads=posix --program-suffix=-4.0 
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr 
--disable-werror --with-system-libunwind --enable-checking=release 
ia64-linux-gnu
Thread model: posix
gcc version 4.0.1 (Debian 4.0.1-2)

$ cat ucontext.cc
#include 

$ g++ ucontext.cc
/usr/include/sys/ucontext.h:49: error: array bound is not an integer constant

This ought to compile, but doesn't. The C compiler has no trouble 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: (519)888-4567x4822 | Waterloo, Ontario, CANADA N2L 3G1


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard A Nelson]

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-textrel version.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib/crt1.o:
relocation R_X86_64_32S against `__libc_csu_fini' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib/crt1.o: could not
read symbols: Bad value
collect2: ld returned 1 exit status

Just for giggles, change -fPIE to -fPIC

$ cc -g -Wall -O2 -fstack-protector-all -z relro -z now -fPIC
-Wl,-z,relro -Wl,-z,now -Wl,-pie -Wl,--warn-shared-textrel version.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib/crt1.o:
relocation R_X86_64_32S against `__libc_csu_fini' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib/crt1.o: could not
read symbols: Bad value
collect2: ld returned 1 exit status

-- System Information:
Debian Release: lenny/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'), 
(500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21-rc7 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.1 depends on:
ii  binutils   2.17cvs20070426-8 The GNU assembler, linker and bina
ii  cpp-4.14.1.2-8   The GNU C preprocessor
ii  gcc-4.1-base   4.1.2-8   The GNU Compiler Collection (base 
ii  libc6  2.5-9 GNU C Library: Shared libraries
ii  libgcc11:4.2-20070525-1  GCC support library

Versions of packages gcc-4.1 recommends:
ii  libc6-dev 2.5-9  GNU C Library: Development Librari
pn  libmudflap0-dev(no description available)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Richard B. Kreckel]

Package: libstdc++5-3.3-dev
Version: 3.3-2
Severity: important

This affects the header file c++/3.3/mips-linux/bits/atomicity.h on the
Mips target only.  When included, it leads to trouble on sources that
declare or define "unused" in some manner.  This is why the version with
double underscore is good for.

It appears, that this has slipped in with GCC-3.3 upstream.  I have
submitted a bugreport with a patch against GCC, see [0].  It would be
helpful if this two-liner (the Mips, part, never mind the AIX part) could
be applied to Debian's package prior to the next dupload since it might
take some time till GCC-3.3.1 fixes this.  In the meantime, this bug
prevents packages from building on Mips, e.g. [1] (though you cannot
recognize it from the log alone).

Regards
-richy.

[0]: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11062>
[1]: 
<http://buildd.debian.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#116823: Debian's g++-3.0 forgets to generate some code.

[Richard B. Kreckel]

Package: g++-3.0
Version: 1:3.0.2-0pre011014
Severity: important

Summary: It seems like some bug crept into Debian's gcc-3.0.  The bug does
not seem to be present upstream.  This bug renders the CLN package
unlinkable with our compiler.

The following piece of code is extracted from CLN's PROVIDE/REQUIRE
mechanism for setting up global objects:


extern "C" void module__prin_globals__firstglobalfun () {}
extern "C" void module__prin_globals__ctorend (void);
extern "C" void module__prin_globals__dtorend (void);
__asm__("\t.globl _GLOBAL__I_module__prin_globals__firstglobalfun");
__asm__("\t.globl _GLOBAL__D_module__prin_globals__firstglobalfun");
static int module__prin_globals__counter;
struct module__prin_globals__controller {
inline module__prin_globals__controller ()
{
if (module__prin_globals__counter++){
__asm__ ("jmp %*%0" : : "rm" ((void*)( 
module__prin_globals__ctorend ))) ;
}
}
inline ~module__prin_globals__controller ()
{
__asm__  ("\n"  ""  "module__" "prin_globals" "__dtorend"  ":") 
;
}
};
static module__prin_globals__controller module__prin_globals__ctordummy;


When compiled with `g++-3.0 -O -c' the resulting .o file starts with

 U _GLOBAL__D_module__prin_globals__firstglobalfun
0058 T _GLOBAL__I_module__prin_globals__firstglobalfun

Rather, there should be a text section for `_GLOBAL__D_module_...' as
well, in the following fashion:

0070 T _GLOBAL__D_module__prin_globals__firstglobalfun
0050 T _GLOBAL__I_module__prin_globals__firstglobalfun

I am able to generate the above (correct) symbols with either RedHat's
`g++3' or with the snapshot `gcc-3.0.2-20011014' bootstrapped on a Woody
system with no configure-options other than --prefix.  The erroneously
missing symbols can also be reproducsed with Debian's version
1:3.0.2-0pre010922.  Also, analyzing the output directly with `cc1plus',
one finds that we cannot blame binutils.  The code is simply not generated
with Debian's compiler:

$ /usr/lib/gcc-lib/i386-linux/3.0.2/cc1plus -quiet -dumpbase foo.cpp -O 
-version -o foo.s foo.cpp
GNU CPP version 3.0.2 20011014 (Debian prerelease) (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0.2 20011014 (Debian prerelease) (i386-linux)
compiled by GNU C version 3.0.2 20011014 (Debian prerelease).
$ grep _D_ foo.s   # WRONG
.globl _GLOBAL__D_module__prin_globals__firstglobalfun
$ grep _I_ foo.s   # okay
.globl _GLOBAL__I_module__prin_globals__firstglobalfun
.type   _GLOBAL__I_module__prin_globals__firstglobalfun,@function
_GLOBAL__I_module__prin_globals__firstglobalfun:
.size   
_GLOBAL__I_module__prin_globals__firstglobalfun,.Lfe4-_GLOBAL__I_module__prin_globals__firstglobalfun
.long   _GLOBAL__I_module__prin_globals__firstglobalfun

Whereas it is generated fine with the hand-bootstrapped compiler:

$ 
/home/kreckel/projects/gcc-3.0.2-20011014/lib/gcc-lib/i686-pc-linux-gnu/3.0.2/cc1plus
 -quiet -dumpbase foo.cpp -O -version -o foo.s foo.cpp
GNU CPP version 3.0.2 20011014 (prerelease) (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0.2 20011014 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 3.0.2 20011014 (prerelease).
$ grep _D_ foo.s   # okay
.globl _GLOBAL__D_module__prin_globals__firstglobalfun
.type   _GLOBAL__D_module__prin_globals__firstglobalfun,@function
_GLOBAL__D_module__prin_globals__firstglobalfun:
.size   
_GLOBAL__D_module__prin_globals__firstglobalfun,.Lfe4-_GLOBAL__D_module__prin_globals__firstglobalfun
.long   _GLOBAL__D_module__prin_globals__firstglobalfun
$ grep _I_ foo.s   #okay
.globl _GLOBAL__I_module__prin_globals__firstglobalfun
.type   _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 bad patch went into Debian's gcc-3.0 or that
some configure options break the compiler.  What is it?!?

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.

[Richard B. Kreckel]

On Tue, 23 Oct 2001, Daniel Jacobowitz wrote:
> [...]
> > 
> > hmm, I was under the impression, that enabling -fuse-cxa-atexit as the
> > default on a glibc-2.2 based system, was safe.
> > 
> > You get the code you want with -fno-use-cxa-atexit. Should we revert
> > this change?
> 
> I don't think so.  I'm 90% positive that this is CLN's fault. 
> Inserting labels in the body of a function is a somewhat disgusting way
> to do it!
> 
> I recommend the use of an ELF section for this sort of thing, the same
> way that the Linux kernel implements it for modules.

OOOoopsss

Could you please provide a pointer or two to code samples or things that
might be helpful implementing it the Right Way, since I intend to try and
fix it?  (Dunno if I'm 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.

[Richard B. Kreckel]

On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
[...]
> > Could you please provide a pointer or two to code samples or things that
> > might be helpful implementing it the Right Way, since I intend to try and
> > fix it?  (Dunno if I'm old enough for this, though.)
> > 
> > Thanks a lot for all the input, anyways.
> 
> The basic trick is to create a section containing pointers to all
> functions you want called.  The code to do it is in crtstuff.c in the
> GCC source, but it's a bit on the nasty side.  Then you put a symbol
> __FOO_BEGIN__ in an object file _at the beginning of your link command_
> in that same section, and __FOO_END__ in an object file at the end.

Gasp.  I am still trying hard to understand what's going on in
crtstuff.c...

> I don't understand at all why CLN is jumping through these hoops.  It
> looks like it could just create global objects, and piggyback on GCC's
> constructor mechanism.  What on earth is it trying to accomplish?

To get the calling order right.  CLN consists of >800 source-code modules
and uses a bridge pattern to abstract the actual implementation away from
the interface.

The code I submitted was expanded from a macro called CL_PROVIDE(foo).  
This is put as a marker into the source file where the static object we
want to have initialized is sitting in.  Then, CL_REQUIRE(foo) is put into
the header file where that object is declared extern.

This comment is lifted from file ${prefix}/include/cln/modules.h:

// The order of initialization of different compilation units is not
// specified in C++. AIX 4 has a linker which apparently does order
// the modules according to dependencies, so that low-level modules
// will be initialized earlier than the high-level modules which depend
// on them. I have a patch for GNU ld that does the same thing.
//
// But for now, I take a half-automatic approach to the correct module
// ordering problem: PROVIDE/REQUIRE, as in Common Lisp.
//
// CL_PROVIDE(module) must be the first code-generating entity in a module.
// Inline function definitions can precede it, but global variable/function/
// class definitions may not precede it.
// Afterwards, any number of CL_REQUIRE(othermodule) is allowed.
// At the end of the module, there must be a corresponding
// CL_PROVIDE_END(module). (Sorry for this, it'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.

[Richard B. Kreckel]

On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
>  If you're order-sensitive, you've got a problem.

Lots of real C++ code is order-sensitive.  This is a serious problem and
there are a couple of ugly solutions to it.  The best solution would be to
teach the linker about it.  The solution we are talking about here is just
a rather unconventional but beautiful one.  Well, it was until yesterday,
I guess...

>  I suggest
> fiddling with link order and normal constructors; it should behave
> roughly as expected - objects first on link line link first.
> 
> Other than that there's not much you can do.

Rather than that or changing the module ordering macros and writing
autoconf scripts to see if the global dtors are making use of cxa-atexit
I guess I'll just switch on -fno-use-cxa-atexit in CLN whenever 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/>

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

[Richard B. Kreckel]

On Wed, 24 Oct 2001, Martin v. Loewis wrote:
> I'd say that the best solution would be to get rid of globals. This is
> actually very easy:
> 
> If you have
> 
> TYPE VAR = INITIALIZER;
> 
> replace that with
> 
> TYPE& getVAR(){
>   static TYPE obj = INITIALIZER;
>   return obj;
> }
> 
> Then use getVAR() whereever you've used VAR before. For backwards
> compatibility, you can even do
> 
> #define VAR (getVAR())
> 
> In understand that modules don't share global objects (perhaps except
> for the module singleton), so removing global should be a local change
> inside each module only.

I don't like this `construct on first use' idiom at all, aesthetically.  I
find it disgusting to use a function call for that and a preprocessor
symbol.

But maybe I'll do something else in the mid-term future.  We've been using
this `construct on first use' idiom until recently in GiNaC for flyweights
and last week I finally got rid of them by setting them up similarly to
how libstdc++-v3 sets up cin, cout, etc (i.e. section 27.4.2.1.6).  That
requires us to have a single controller module that explicitly knows about
the dependencies, but since there are only 43, as you have noticed, this
might be an option worth considering.

> > The best solution would be to teach the linker about it.
> 
> The linker actually does know about constructor order. In g++, there
> is a guarantee that object files within the same executable or shared
> library are initialized from right to left, in the order in which the
> objects appear on the linker line.

Arguably, that order is too simplistic.  It should analyze the
dependencies among the globals, see if they form a DAG and rearrange the
order so that the DAG is traversed correctly when the library/program
fires up.

> > The solution we are talking about here is just a rather
> > unconventional but beautiful one.
> 
> Looking at the code in module.h, I'd question that there is anything
> beautiful about it.

No, the macros are obscene, as mentioned in the comment!  :-)
But the way one can use them is quite nice, I'd say.

> > Rather than that or changing the module ordering macros and writing
> > autoconf scripts to see if the global dtors are making use of
> > cxa-atexit I guess I'll just switch on -fno-use-cxa-atexit in CLN
> > whenever GCC-3.x is used.  Hope this'll work for a couple of
> > years...
> 
> I very much doubt that. Somebody will notice that the _GLOBAL__
> symbols don't need unique names at all, since they are not global (in
> fact, static_initialization_and_destruction is already in gcc 2.95 a
> single function for both ctors and dtors, so it is questionable
> whether these "clever" macros really get the control flow right).
> 
> Furthermore, the C++ ABI really specifies that 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/>

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

[Richard B. Kreckel]

Hi,

On Thu, 25 Oct 2001, Martin v. Loewis wrote:
> > I don't like this `construct on first use' idiom at all, aesthetically.  
> 
> Isn't this exactly what you want, and what modules.h does? If module A
> uses module B, construction of A first constructs B.

Sure it is.

> > I find it disgusting to use a function call for that and a
> > preprocessor symbol.
> 
> Well, you don't have to use the preprocessor symbol :-(
> 
> Actually, many people find direct access to variables (members or
> globals) disgusting, and prefer to use accessor functions all the
> time.

For CLN that would be tolerable for the globals.  With a #define it would
only break binary compatibility.  Accessors are fine but exaggerated usage
of accessors leads to bad style IMHO.  I always shiver when I have to read
student's programs in a style they learned in their C++ courses: having a
one-to-one correspondence between accessors and data.  This is not real
abstraction and only under special circumstances something is gained with
that style.

In GiNaC, when I transformed all flyweights from `construct on first use'
statics to direct objects, that didn't only lead to better readabilty but
also to a 10-15% gain in performance.  :-)

> > But maybe I'll do something else in the mid-term future.  We've been using
> > this `construct on first use' idiom until recently in GiNaC for flyweights
> > and last week I finally got rid of them by setting them up similarly to
> > how libstdc++-v3 sets up cin, cout, etc (i.e. section 27.4.2.1.6).  
> 
> Doesn't this, in practice, require placement new calls? That appears
> to be very unreliable, as it still allows for objects to be accessed
> before being constructed.

It doesn't necessarily require placement new calls, though that is
what libstdc++-v3 does in src/ios.cc.  Sometimes it's enough to declare
extern const T& foo;
in the header file and
T* foo_p;
const T& foo = *foo_p;
in the module.  foo_p must be allocated of course before the reference is 
set up.  And yes, of course, that may lead to unreliable code if people
tamper with that moduel without knowing what's going on.  :-(

> > Arguably, that order is too simplistic.  It should analyze the
> > dependencies among the globals, see if they form a DAG and rearrange the
> > order so that the DAG is traversed correctly when the library/program
> > fires up.
> 
> The problem here is: the globals don't have dependencies, atleast none
> that are expressed in C++. For your application, it seems 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 exactly this so it seems like things can be done better, doesn't it?

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.

[Richard B. Kreckel]

On Sat, 27 Oct 2001, Nathan Myers wrote:
[...]
> > I'd say that the best solution would be to get rid of globals. This is
> > actually very easy:
> > 
> > If you have
> >   TYPE VAR = INITIALIZER;
> > replace that with
> >   TYPE& getVAR(){  static TYPE obj = INITIALIZER;   return obj; }
> > 
> > Then use getVAR() whereever you've used VAR before. For backwards
> > compatibility, you can even do
> > 
> > #define VAR (getVAR())
> > 
> > In understand that modules don't share global objects (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 not an issue here.  We're using reference counting
all over the place...

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.

[Richard B. Kreckel]

On Wed, 24 Oct 2001, Matthias Klose wrote:
> hmm, I was under the impression, that enabling -fuse-cxa-atexit as the
> default on a glibc-2.2 based system, was safe.
> 
> You get the code you want with -fno-use-cxa-atexit. Should we revert
> this change?

After analyzing the problem it became clear that the problem was indeed
CLN's and not Debian's gcc-3.0 package.  Bruno Haible has hacked a
configure test for CLN which avoids hacking the global destructors if
there is no global destructors function.  (I am going to dupload this
now.)  Gcc maintainers, please close 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#246319: libcln3: Segfaults in cln::I_to_digits when converting numbers to binary

[Richard B. Kreckel]

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 label
"fertig:" where it tries to set erg->MSBptr to erg_ptr.

However, there is nothing wrong with that statement.  It appears to be a
compiler error introduced in GCC-3.0.0 and finally fixed in GCC-3.4.0.
It is only triggered when the option -fno-exceptions is turned on when CLN
is compiled.  Without that option, everything works fine.  I've just
reproduced this bug with GCC releases 3.1.1, 3.2.3, 3.3.2 and 3.3.3, and
also with 3.3.4-prerelease from CVS, all vanilla and bootstrapped locally

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

[Richard B. Kreckel]

On Fri, 30 Apr 2004, Matthias Klose wrote:
> > Right now, I see four alternative solutions:
> > 1) Upload a new Debian package where -fno-exceptions is not turned on.
>
> If you change interfaces, you'll have at least change the package name
> and/or soname and recompile dependent packages.

I am not aware of a change in interface when turning off -fno-exception!
Is there one?

> > 2) Fix CLN by playing dirty tricks.  For instance, printing the variable
> >erg's address in src/integer/output/cl_I_print.cc:30 seems to fix the
> >problem.  It should be possible to somehow read that address without
> >any side-effect.
>
> preferred solution, unless

Seems feasible.  Introducing the section

+#if (defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ < 4))
+  // workaround GCC 3.0.0-3.3.3 compiler bug (cf. Debian bug#246319)
+  static char dummy[40];
+  snprintf(dummy,40,"%d%x%x",need,&erg,erg.LSBptr);
+#endif

at line 30 of cl_I_print.cc seems to fix the problem.  Yes, I have to
print all three variables.  Any smaller subset doesn't seem to do the
trick.  Scary, I would say.

> > 3) Fix GCC on the 3.3 branch.  It would probably take me at least a full
> >day to distill a useful testcase, however.  Likely more, if it turns
> >out to be a Heisenbug.  And if this leads to a fix in the GCC 3.3
> >branch is more then doubtful, I guess.
>
> you are able to extract a reduced testcase. yes.
>
> > 4) Use Debian's gcc-3.4 [0], making that a requirment for depending
> >packages, too.
>
> Not really an option because of changes in the C++ ABI and libstdc++.
>
> > S, what are the chances for gcc-3.4 hitting sarge as the default
> > compiler?  In my experience, this is a much better compiler than 3.3.3, in
> > all respects, including reliability.  The whole 3.3 series seems to be
> > having some problems.  In another context, it has already been suggested
> > by GCC developers that the 3.3 branch may have taken place too early,
> > causing patches not beeing applied properly and so on [1].
>
> IMO no chance as the default compiler. Remember the time needed for
> the last C++ transition. Maybe as an option, if the runtime libraries
> 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

[Richard B. Kreckel]

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/>

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

[richard at codesourcery dot com]

--- 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 fails for -EL
>> multilibs, and we want this test to work for both anyway.)
>> 
> Are you sure?  On the trunk I tested on mipsel-linux with -EB and it 
> seems to work.  For a compile only test it should work on little-endian 
> system.

I mean that it fails if you explicitly test -EL multilibs.  E.g. on
mipsisa64-elf, I normally test "mips-sim{,-msoft-float}{-EB,-EL}", and
the compiler will complain at having both -EL and -EB on the command line.
We could make mips.exp skip the test when -EL is forced, but it seems
more useful to run it regardless.  Or we could use target selectors to
select between two dg-mips-options lines depending on whether -EL has
been added to the multilib flags.  However, it seems odd to test
big-endian (only) on little-endian systems when -EL is not explicitly
given, but test little-endian when -EL _is_ explicitly (and redundantly)
given.

Richard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[richard at codesourcery dot com]

--- 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 for me with -EB, so running the 
> test case with -EL would be pointless.  I understand that you do most of 
> your testing on the simulator, but for someone doing testing on little 
> endian hardware there is no coverage without the -EB.

OK.  As I said before, I didn't think it would be pointless, because
we do want to make sure this continues to work for -EL too.  (There's
generally very little coverage of -mabi=64 -msym32; the only user I know
of is linux.)  However, I'll yield and make mips.exp skip the test when
running explicitly-EL multilibs.

Richard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[richard at codesourcery dot com]

--- 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:
>> --- 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 for me with -EB, so running the 
>>> test case with -EL would be pointless.  I understand that you do most of 
>>> your testing on the simulator, but for someone doing testing on little 
>>> endian hardware there is no coverage without the -EB.
>> 
>> OK.  As I said before, I didn't think it would be pointless, because
>> we do want to make sure this continues to work for -EL too.
>
> The only time loading the low order bits of a word is done at an offset 
> from the base of the word is in big endian.  So I don't think it will 
> ever fail on a little endian system, but I may be missing something.

Yes, I realise that, but I meant that you can't really assume very much
about -mabi=64 -msym32 -EL at all from a mips{64,}{,-el}-linux-gnu run.
At least allowing the test to be run in little-endian would have provided
some coverage, and people were still going to notice if the -EB case
regressed.

Richard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
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

[richard dot guenther at gmail dot com]

--- 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 from being marked as pure or const.
>
> Full testing in progress on x86-64.  But the code seems to work properly.
>
> Ok to commit when the full testing is finished?

Ok.

Thanks,
Richard.

> Kenny
>
> 2007-11-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/33826
> * ipa-pure-const (static_execute): Added code to keep recursive
> functions from being marked as pure or const.
> * ipa-utils (searchc): Fixed comment.
>
> 2007-11-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/33826
> * gcc.dg/pr33826.c: New.
>
>
>
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]