On Thu, 24 Sep 2015, Henrique de Moraes Holschuh wrote:
> 1. Bug exists in gcc Debian 4.6.4-7 (latest 4.6 in unstable)
> 2a. Bug exists in gcc Debian 4.7.2-5 (default gcc for oldstable)
> 2b. Bug exists in gcc Debian 4.7.4-3 (latest 4.7 in unstable)
> 3. Bug exists in gcc Debian 4.8
Matthias,
Given the new information I just sent to the bug report, and since all
current versions of gcc have this issue, it should not remain as "wishlist"
in gcc-4.7 only.
I have tagged it "upstream" for now, and removed the "moreinfo" tag.
Should I raise severity back to important, or to norm
On Thu, 24 Sep 2015, Henrique de Moraes Holschuh wrote:
> It still exists on gcc-4.9 in stable (gcc Debian 4.9.2-10). I am going to
> test on an unstable chroot and gcc-snapshot in a few moments.
I've tested it in unstable as well. Here's a proper summary:
1. Bug exists in gc
On Thu, 24 Sep 2015, Matthias Klose wrote:
> which is EOL upstream for more than a year, and which targets non-default
> flags. You don't even try to reproduce with current GCC versions in
-O3 is not exactly a "uncommon" flag. I just tracked it down to
-ftree-vectorize (enabled by -O3) to _help_
Package: gcc-4.7
Version: 4.7.2-5
Severity: important
On x86 and x86-64, the platform explicitly supports unaligned access,
and in fact such access has been heavily optimized on the latest Intel
and AMD processors.
A _lot_ of code takes advantage of this, as it is often extremely
painful (or slow
On Tue, 17 May 2011, Matthias Klose wrote:
> >Assuming we can't just do away with i486 support for now, did anyone track
> >down exactly what was causing breakages that forced the change from
> >march=486 to march=586?
>
> libgomp assumes 586; there were some GFortran/OMP issues on i386.
"assumes
On Mon, 16 May 2011, Ben Hutchings wrote:
> I think any claim that Debian supports 486-class processors is more of
> an aspiration. What maintainer has the time to test on such antiques
> regularly?
Well, nobody is running regular kernel regression testing on 486-class
hardware AFAIK, and that in
On Sun, 15 May 2011, Ben Hutchings wrote:
> On Sun, 2011-05-15 at 09:28 -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 May 2011, Mike Hommey wrote:
> > > I just found out that gcc is compiled with --with-arch-32=i586, which
> > > effectively means it builds
On Sun, 15 May 2011, Mike Hommey wrote:
> I just found out that gcc is compiled with --with-arch-32=i586, which
> effectively means it builds with -march=i586 by default (and that it
> still claims an i486-linux-gnu target).
>
> I'm wondering. Is the project at large aware that we're not building
On Thu, 29 Oct 2009, Kees Cook wrote:
> On Thu, Oct 29, 2009 at 10:01:08PM -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 27 Oct 2009, Kees Cook wrote:
> > > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > > > On Sun, Oct 25, 2009 at 11:
On Tue, 27 Oct 2009, Kees Cook wrote:
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they work? Do they als
On Thu, 29 Oct 2009, Christoph Anton Mitterer wrote:
> On Tue, 2009-10-27 at 22:19 -0200, Henrique de Moraes Holschuh wrote:
> > Well, the issue raised in LKML is that you absolutely should *not* enable
> > -fstack-protector-all unless you _really_ know what you're doing, an
On Tue, 27 Oct 2009, Kees Cook wrote:
> > > It seems the kernel will not be happy if the stack protector is switched
> > > on unconditionally:
> > >
> > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
> >
> > Indeed. The kernel build system needs to be able to command whether
> > stackp
On Mon, 26 Oct 2009, Gabor Gombas wrote:
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they work? Do they
Package: gcc-4.2
Version: 4.2.4-6
Severity: important
Tags: fixed-upstream
gcc 4.2.4-6 generates bad code when -f no-strict-overflow is used.
This causes kernel 2.6.27.27 and 2.6.30.2 to be miscompiled and hang. It
may be a cause of suble errors elsewhere in the kernel, too.
I don't know if the
On Sat, 28 Jun 2008, Debian Bug Tracking System wrote:
>[Matthias Klose]
>* Update to SVN 20080628 from the gcc-4_3-branch.
> - Fix PR target/36533, wrong-code with incorrectly assumed
> aligned_operand.
>Closes: #487115.
Other than the kernel, does this thing causes enough t
Package: gcc-4.3
Version: 4.3.1-2
Severity: important
gcc-4.3.1 miscompiles Linux ext3 code in some targets, causing OOPSes. It
could be causing other problems elsewhere in the kernel, too.
More information:
https://bugzilla.redhat.com/show_bug.cgi?id=451068
Bug caused by (extracted from RedHat
On Tue, 05 Nov 2002, Oliver M. Bolzer wrote:
> Nevertheless, it IS a real problem. As the cmov instruction is OPTIONAL
> for i686 but GCC uses it for 686, that is the cause of the problem. That
> the kernel compiles itself as 585 if a C3 is specified is simply a
> work-around. The correct solution
18 matches
Mail list logo
