> Note that this issue is in theory pretty serious as in principle
_any_
> binary package in the archive could be affected.
Since the abs() is optimized away on miscompilations, searching for
binaries that have the abs() symbol won't find the buggy ones.
The only reliable way to find out what pac
Package: gcc-4.2
Version: 4.2.3-2
--- Please enter the report below this line. ---
I have manually reduced the previous testcase (it is 4K now, vs 32K).
The same testcase can be used for both x86_64 and x86(-32).
When I compile with -O3, or -O2 -finline-functions incorrect code is
generated.
$
Package: libffi-dev
Version: 3.0.7-1
Severity: normal
man ffi_call
synposis says , but example uses .
Manpage should be consistent and use only , if that is correct for
Debian.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'),
Package: g++-4.5
Version: 4.5.1-1
Severity: normal
Tags: upstream
FYI I reported a gcc-4.5 bug here with full details here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
It was initially reported against ClamAV here:
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2190
GCC gives an internal
Package: gcc-4.4
Version: 4.4.4-14
Severity: normal
Tags: upstream
Forwarded: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
I just reported this bug in gcc bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
It happens when using gcc version 4.4.5 20100909 (prerelease) (Debian 4.4.4-
Hi,
Attached is a simple testcase from VLC.
At -O0 everything is fine:
$ gcc-4.6 -S -O0 x.i
$ grep memmove x.s
call__memmove_chk
At -O1 it incorrectly it is incorrectly changed to memcpy:
$ gcc-4.6 -S -O1 x.i
$ grep memcpy x.s
callmemcpy
If I change the provided x.i, and
Marc Glisse wrote:
> Hello,
>
> in the prototype of memmove (taken from glibc bits/string3.h), you will
> notice __restrict in front of the arguments. This is not present in more
> recent glibc versions and is a likely cause of your trouble.
>
Indeed if I remove __restrict the bug is gone, and
Package: lib32mudflap0
Version: 4.4.1-1
Severity: normal
I got this today after running aptitude dist-upgrade (after returning from a 2
week holiday):
Writing extended state information... Done
E: Couldn't configure pre-depend libc6-i386 for lib32mudflap0, probably a
dependency cycle.
A package
Package: gcc-4.5
Version: 4.5-20100227-1
Severity: wishlist
GCC-4.5 has a gold linker plugin to do LTO, see
http://gcc.gnu.org/wiki/whopr/driver
It should already be built during a normal gcc-4.5 build,
the plugin should be called liblto-plugin.so.
I can't find that in the Debian experimental p
Package: gcc-4.5
Version: 4.5-20100227-1
Severity: normal
Tags: experimental
gcc-4.5 with -flto doesn't work with -fPIC properly.
Simple testcase:
int entry(int a)
{
return bar(a)+1;
}
int bar(int a)
{
return a+4;
}
$ gcc-4.5 foo1.c -flto -fPIC -DPIC -c
$ gcc-4.5 foo2.c -flto -fPIC -DPI
On 2010-03-26 01:27, Matthias Klose wrote:
> On 25.03.2010 22:19, Török Edwin wrote:
>> Package: gcc-4.5
>> Version: 4.5-20100227-1
>> Severity: wishlist
>>
>> GCC-4.5 has a gold linker plugin to do LTO, see
>> http://gcc.gnu.org/wiki/whopr/driver
>>
On 2010-03-26 13:40, Török Edwin wrote:
> I found the LTO plugin here (it was not installed by the package)
> ./debian/tmp/usr/lib/gcc/x86_64-linux-gnu/4.5/liblto_plugin.so
>
> So I copied it to /usr/lib/gcc/x86_64-linux-gnu/4.5/liblto_plugin.so
> manally, and -fuse-linker-plu
Package: gcc-4.4-plugin-dev
Version: 4.4.3-7
Severity: normal
According to the GCC plugin documentation plugins should declare a symbol
plugin_is_GPL_compatible.
However the gcc-4.4 in Debian loads the plugin regardless.
To reproduce:
$ cat >testcase.c <
int plugin_init(struct plugin_name_args *p
Package: gcc-doc
Version: 5:2
Severity: normal
The gcc manpage says "with the Invariant Sections being "GNU General Public
License" and "Funding Free Software"", however
neither "GNU General Public License", nor "Funding Free Software" appears in
the manpage itself, hence the manpage can be
con
Package: libasan0
Version: 4.8-20130315-1
Severity: normal
--- Please enter the report below this line. ---
GCC-4.8's(from experimental) -fsanitize=address flag is not working:
$ gcc-4.8 -fsanitize=address test.c
/usr/bin/ld.bfd.real: cannot find libasan_preinit.o: No such file or directory
coll
Package: gcc-4.8
Version: 4.8-20130315-1
Severity: normal
--- Please enter the report below this line. ---
GCC says that -pie or -shared is needed to use -fsanitize=thread, but that is
not enough on amd64:
$ /usr/bin/gcc-4.8 -fsanitize=thread test.c -pie
/usr/bin/ld.bfd.real: /tmp/ccBEgPXP.o: rel
On 03/19/2013 12:07 AM, Matthias Klose wrote:
> Am 17.03.2013 04:03, schrieb Török Edwin:
>> GCC says that -pie or -shared is needed to use -fsanitize=thread
>
> where?
>
>
In the error message when you use just -fsanitize=thread:
$ gcc-4.8 -fsanitize=thread x.c
gcc-4.8.re
forwarded 703230 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56682
thanks
--
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/514b3d46.6030...@etorok.net
18 matches
Mail list logo
