Bug#133574: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit
Synopsis: gcc doesn't diagnose, that the compiler exceeds a compiler limit State-Changed-From-To: open->closed State-Changed-By: rth State-Changed-When: Sun Jan 26 09:39:58 2003 State-Changed-Why: This isn't a compiler problem. There is no compiler limit that has been exceeded. Indeed, the executable generated looks fine. The kernel, however, is refusing to map the very large bss segment. Perhaps your ulimit is set too low? Perhaps you don't have enough VM to satisfy the request? In fact, if I enable a 2G swap file, and link the program statically, then it runs just fine. (If you don't link statically, then ld.so crashes. I suspect a different kernel bug, in that it's not adjusting where it maps ld.so based on the large bss segment.) http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9081
Bug#85468: target/9082: [alpha,ia64] memcpy makes unaligned access
Synopsis: [alpha,ia64] memcpy makes unaligned access State-Changed-From-To: open->closed State-Changed-By: rth State-Changed-When: Sun Jan 26 10:22:31 2003 State-Changed-Why: When submitting bugs to gcc, one must include the test case, not reference it in some package elsewhere. This reduces the possibility that the bug requires specific system headers to be reproduced. That said, it's obvious this is a duplicate of PR 9080, which is closed due to the input program being invalid. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9082
Bug#136659: target/9080: optimisation on sparc leads to unalligned access in memcpy
Synopsis: optimisation on sparc leads to unalligned access in memcpy
Responsible-Changed-From-To: unassigned->rth
Responsible-Changed-By: rth
Responsible-Changed-When: Sun Jan 26 10:13:38 2003
Responsible-Changed-Why:
.
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Sun Jan 26 10:13:38 2003
State-Changed-Why:
I'm fairly sure this has been discussed before, but I can't find
the reference right away. The problem is known, and I consider
the input program incorrect.
The problem is that alignof(struct iphdr) == 4, and yet the
given pointer to that structure is only 2 byte aligned. This
violates section 6.3.2.3/7, to wit:
If the resulting pointer is not correctly aligned for the
pointed-to type, the behavior is undefined.
GCC uses this clause to infer from the type of the pointer the
alignment that it *must* have.
There are two solutions for this piece of code.
One, use packed data structures, so that they are 1 byte aligned.
In this case something like
struct iphdr_u {
struct iphdr h __attribute__((packed));
};
followed by
&tmp_iphdr->h.saddr
Two, don't cast to struct iphdr at all. Instead use offsetof
to find the proper displacement into the buffer.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9080
Bug#169004: target/9082: [alpha,ia64] memcpy makes unaligned access
On Sun, Jan 26, 2003 at 10:22:31AM -, [EMAIL PROTECTED] wrote:
> Synopsis: [alpha,ia64] memcpy makes unaligned access
>
> State-Changed-From-To: open->closed
> State-Changed-By: rth
> State-Changed-When: Sun Jan 26 10:22:31 2003
> State-Changed-Why:
> When submitting bugs to gcc, one must include the test case,
> not reference it in some package elsewhere. This reduces the
> possibility that the bug requires specific system headers to
> be reproduced.
I'm sorry about that, I'll get the preprocessed program sent to you.
> That said, it's obvious this is a duplicate of PR 9080,
> which is closed due to the input program being invalid.
I'm afraid I don't see the connection between the two reports.
In my case, memcpy is correct programmatically but it's triggering
an alignment error as it's performing 8-byte loads when the source
argument is 4-byte aligned (the destination is 8-byte aligned though).
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#136659: target/9080: optimisation on sparc leads to unalligned access in memcpy
On Sun, Jan 26, 2003 at 10:13:38AM -, [EMAIL PROTECTED] wrote: > Synopsis: optimisation on sparc leads to unalligned access in memcpy > I'm fairly sure this has been discussed before, but I can't find > the reference right away. The problem is known, and I consider > the input program incorrect. I had the same problem with netstat and nettools on sparc and another platform. I noticed that using bcopy() instead of memcpy() would work. It happens very of for networking tools because setting up ip packet structures inside a memory buffer will often require unalligned access. My bug sometimes later vanished, I am sure this was caused by a new gcc version. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Bug#176112: broken alternative f77
On Sun, Jan 26, 2003 at 08:13:19PM +0100, Matthias Klose wrote: > > Right, but I don't have g77 installed on this system. That's why the > > alternative is broken. > ok, does this work for you (to be included in the gcc package). > > # remove f77 alternative left over from an old egcs version ... > f77=`update-alternatives --list f77 | fgrep /usr/bin/g77 || true` > if [ "$f77" = /usr/bin/g77 -a \( -e /usr/doc/g77 -o /usr/share/doc/g77 \) ] > then > update-alternatives --remove f77 /usr/bin/g77 > fi Hmm. No. There's no such alternative on the system. There's only an /etc/alternatives/f77 symlink which points nowhere. Nothing in /usr/bin or anything. Just checking for g77 not installed and the existance of this file, and if it does, remove it would be enough. Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/~jordi/
Bug#133574: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit
Hi! > Synopsis: gcc doesn't diagnose, that the compiler exceeds a compiler limit > > State-Changed-From-To: open->closed > State-Changed-By: rth > State-Changed-When: Sun Jan 26 09:39:58 2003 > State-Changed-Why: > This isn't a compiler problem. There is no compiler limit that > has been exceeded. Indeed, the executable generated looks fine. > The kernel, however, is refusing to map the very large bss > segment. Perhaps your ulimit is set too low? Perhaps you > don't have enough VM to satisfy the request? > > In fact, if I enable a 2G swap file, and link the program > statically, then it runs just fine. > > (If you don't link statically, then ld.so crashes. I suspect > a different kernel bug, in that it's not adjusting where it > maps ld.so based on the large bss segment.) > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9081 It indeed is a kernel problem, see fs/binfmt_elf.c, where set_brk does not do any error checking *at all* :-(. Pavel -- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic.
Processed: reassigning issue in kernel
Processing commands for [EMAIL PROTECTED]: > reassign 133574 kernel-source-2.4.20 Bug#133574: [PR other/9081] gcc doesn't diagnose, that the compiler exceeds a compiler limit Bug reassigned from package `gcc' to `kernel-source-2.4.20'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#178561: gcc-3.2-doc: stream::attach(int fd) porting entry out-of-date
Package: gcc-3.2-doc Version: 1:3.2.2ds5-0pre6 Severity: normal The stream::attach entry in porting-howto.html does not mention the stdio_filebuf as an alternative. -- System Information Debian Release: testing/unstable Kernel Version: Linux gondolin 2.4.20-686-smp #1 SMP Mon Jan 13 23:06:41 EST 2003 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Versions of the packages gcc-3.2-doc depends on: ii gcc-3.2-base 3.2.1-0pre3The GNU Compiler Collection (base package).
