[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

--- Comment #31 from pluto at agmk dot net  2007-06-03 07:21 ---
r125227 | dberlin | 2007-05-31 11:37:38 -0400 (Thu, 31 May 2007) | 11 lines

2007-05-27  Daniel Berlin <[EMAIL PROTECTED]>

Fix PR/30052
Backport PTA solver from mainline

* pointer-set.c: Copy from mainline
* pointer-set.h: Ditto.
* tree-ssa-structalias.c: Copy solver portions from mainline.
* Makefile.in (tree-ssa-structalias.o): Update dependencies


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

--- 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#427278: marked as done (gcc-4.2-base: should it better be arch: all?)

[Debian Bug Tracking System]

Your message dated Sun, 3 Jun 2007 10:59:45 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#427278: gcc-4.2-base: should it better be arch: all?
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---


Package: gcc-4.2-base
Version: 4.2-20070528-1
Severity: normal

When I look at the content of gcc-4.2-base I wonder if it should 
better be arch: all instead of arch: any. Are there reasons for arch: 
any? I'm porting to a new architecture and for me it would be useful 
to have it arch: all, because gcc-4.2-source depends on it and is also 
arch: all.


Martin

--- End Message ---
--- Begin Message ---
Martin Koeppe writes:
> 
> Package: gcc-4.2-base
> Version: 4.2-20070528-1
> Severity: normal
> 
> When I look at the content of gcc-4.2-base I wonder if it should 
> better be arch: all instead of arch: any. Are there reasons for arch: 
> any? I'm porting to a new architecture and for me it would be useful 
> to have it arch: all, because gcc-4.2-source depends on it and is also 
> arch: all.

no, dependency handling is easier; an uninstallable arch all gcc-base
package hurts on archs where the current package is not yet built. see
xulrunner and texlive for bad examples.
--- End Message ---

[bts-link] source package gnat-4.1

[bts-link-upstream]

#
# bts-link upstream status pull for source package gnat-4.1
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user [EMAIL PROTECTED]

# remote status report for #427107
#  * http://gcc.gnu.org/PR32164
#  * remote status changed: (?) -> NEW
usertags 427107 + status-NEW

# remote status report for #427108
#  * http://gcc.gnu.org/PR32181
#  * remote status changed: (?) -> UNCONFIRMED
usertags 427108 + status-UNCONFIRMED

thanks

[bts-link] source package gcc-4.2

[bts-link-upstream]

#
# bts-link upstream status pull for source package gcc-4.2
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user [EMAIL PROTECTED]

# remote status report for #427124
#  * http://gcc.gnu.org/PR32182
#  * remote status changed: (?) -> NEW
usertags 427124 + status-NEW

thanks

Processed: Re: Bug#427185: zlib - FTBFS: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file or directory

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 427185 zlib
Bug#427185: Warning output when linking 64 bit objects on i386
Bug reassigned from package `gcc-4.1' to `zlib'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#427185: zlib - FTBFS: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file or directory

[Matthias Klose]

reassign 427185 zlib
thanks

unreproducible; works for me in a current unstable environment.

Mark Brown writes:
> reassign 427185 gcc-4.1
> found 427185 4.1.2-11
> notfound 427185 1:1.2.3-15
> retitle 427185 Warning output when linking 64 bit objects on i386
> thanks
> 
> The enclosed FTBFS in the 64 bit zlib on i386 appears to be a toolchain
> issue, though I may have assigned it to the wrong package.
> 
> The issue is that linking a 64 bit ELF object (at least via GCC) appears
> to produce this warning unconditionally:
> 
> >  > /usr/bin/ld: error in 
> > /usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr 
> > table will be created.
> 
> (it says it is an error but the return code appears to be unaffected)
> which causes the zlib configure script to think that shared libraries
> cannot be built, causing a FTBFS.
> 
> A full copy of the original report is enclosed:
> 
> On Sat, Jun 02, 2007 at 01:34:05PM +0200, Michael Ablassmeier wrote:
> 
> > Package: zlib
> > Version: 1:1.2.3-15
> > Severity: serious
> > User: [EMAIL PROTECTED]
> > Usertags: qa-ftbfs
> > 
> > hi,
> > 
> > while doing an archive wide package rebuild your package failed to build 
> > from
> > source for the following reason:
> > 
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o compress.o compress.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o crc32.o crc32.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o gzio.o gzio.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o uncompr.o uncompr.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o deflate.o deflate.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o trees.o trees.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o zutil.o zutil.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o inflate.o inflate.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o infback.o infback.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o inftrees.o inftrees.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o inffast.o inffast.c
> >  > ar rc libz.a adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o 
> > trees.o zutil.o inflate.o infback.o inftrees.o inffast.o 
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf -o example example.o -L. libz.a
> >  > /usr/bin/ld: error in 
> > /usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr 
> > table will be created.
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf   -c -o minigzip.o minigzip.c
> >  > gcc -m64 -O3 -g -D_REENTRANT -fPIC -DNO_vsnprintf -DUSE_MMAP 
> > -DHAS_snprintf -DHAS_vsnprintf -o minigzip minigzip.o -L. libz.a
> >  > /usr/bin/ld: error in 
> > /usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr 
> > table will be created.
> >  > make[1]: `libz.a' is up to date.
> >  > make[1]: Leaving directory `/build/user/zlib-1.2.3/build-tree/zlib-1.2.3'
> >  > touch debian/stampdir/build-64
> >  > install -m 644 -s build-tree/zlib-1.2.3/libz.so.1.2.3 
> > /build/user/zlib-1.2.3/debian/lib64z1/usr/lib64/libz.so.1.2.3
> >  > install: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file 
> > or directory
> >  > make: *** [middle-binary-lib64z1] Error 1
> > 
> > The Full Build log is available and can be viewed at:
> > 
> >  http://people.debian.org/~lucas/logs/2007/06/01/
> >  
> > bye,
> > - michael
> > 
> > 
> 
> -- 
> "You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: Bug#427185: zlib - FTBFS: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file or directory

[Mark Brown]

reassign 427185 gcc-4.1
thanks

On Sun, Jun 03, 2007 at 03:39:25PM +0200, Matthias Klose wrote:

> unreproducible; works for me in a current unstable environment.

I've just updated again to current unstable (only portmap and findutils
changed) and can still reproduce the problem:

| [EMAIL PROTECTED]:/tmp$ cat foo.c
| int main(void)
| {
| return 0;
| }
| [EMAIL PROTECTED]:/tmp$ gcc -m64 -o foo foo.c
| /usr/bin/ld: error in 
/usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr 
table will be created.
| [EMAIL PROTECTED]:/tmp$ echo $?
| 0

and similarly if I compile to an object and link that.  Reassigning back
to gcc-4.1 since it can be reproduced outside of the zlib build
environment - whatever is going on here doesn't appear to be related to
that package.

Perhaps we have somehow managed to get different versions of some
toolchain packages?  I have:

ii  binutils   2.17cvs2007042 The GNU assembler, linker and binary utiliti
ii  binutils-multi 2.17cvs2007042 Binary utilities that support multi-arch tar

(these are both at 2.17cvs20070426-8.)

ii  gcc-4.14.1.2-11   The GNU C compiler
ii  gcc-4.1-multil 4.1.2-11   The GNU C compiler (multilib files)
ii  gcc-multilib   4:4.1.2-2  The GNU C compiler (multilib files)
ii  libc6-dev  2.5-9+b1   GNU C Library: Development Libraries and Hea
ii  libc6-dev-amd6 2.5-9+b1   GNU C Library: 64bit Development Libraries f
ii  libc6-i686 2.5-9+b1   GNU C Library: Shared libraries [i686 optimi

and apt currently claims that none of the packages on that system are
out of date.  I don't know what the buildd that was used for the
original report had.  Removing binutils-multiarch appears to have no
effect on the problem.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Processed: Re: Bug#427185: zlib - FTBFS: cannot stat `build-tree/zlib-1.2.3/libz.so.1.2.3': No such file or directory

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 427185 gcc-4.1
Bug#427185: Warning output when linking 64 bit objects on i386
Bug reassigned from package `zlib' to `gcc-4.1'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Welcome to Al-Manahel Newsletter List

[munir]

The subscription of the email address: 

[EMAIL PROTECTED]

To the mailing list: 

Al-Manahel Newsletter List

is all set. Thanks for subscribing! 

Date of this subscription: Sun Jun  3 09:08:26 2007

Please save this email message for future reference. 

---

You may automatically unsubscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 



- 


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

Al-Manahel Newsletter List Unsubscription

[munir]

The removal of the email address:

[EMAIL PROTECTED]

>From the mailing list: 

Al-Manahel Newsletter List 

is all set.

Date of this removal: Sun Jun  3 14:47:41 2007

Please save this email message for future reference.

---

You may automatically subscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 



- 



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

Bug#427442: /usr/share/doc/libgcj-common/changelog.Debian.gz overwrites gcj-4.1-base/changelog.Debian.gz

[Karl Chen]

Package: libgcj-common
Version: 1:4.1.1-21
Severity: normal


Hello,

/usr/share/doc/libgcj-common is a symlink to gcj-4.1-base (or I guess
gcj-4.2-base in unstable).

The files 
/usr/share/doc/libgcj-common/changelog.Debian.gz
/usr/share/doc/libgcj-common/copyright 

overwrite
/usr/share/doc/gcj-4.1-base/changelog.Debian.gz
/usr/share/doc/gcj-4.1-base/copyright 

Or gcj-4.1-base overwrites libgcj-common's files, depending
on which one is installed later.

I found out from debsums.


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