On Mon, May 02, 2011 at 11:28:45AM +0200, Matthias Klose wrote:
> On 05/02/2011 10:35 AM, Pierre Habouzit wrote:
> >Package: gcc-4.6
> >Version: 4.6.0-6
> >Severity: important
> >
> >
> >The bug is fixed upstream please backport it, it's r172963 in the
Package: gcc-4.6
Version: 4.6.0-6
Severity: important
gcc-4.6 has a regression wrt flattening (__attribute__((flatten))) that
makes it disregard the fact that some functions aren't inlineable.
This causes build failures if you call functions with va_args (this is
PR#48731 upstream).
It also mea
Package: gcc-4.5
Version: 4.5.1-2
Severity: important
Forwarded: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44802
This is upstream http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44802
In other words, as soon as you use visibility and commodity archives,
you can't use LTO. Which makes it worthless f
On Mon, Aug 23, 2010 at 02:05:25PM +0200, Matthias Klose wrote:
> On 23.08.2010 13:30, Pierre Habouzit wrote:
> >On Mon, Aug 23, 2010 at 01:21:04PM +0200, Pierre Habouzit wrote:
> >>On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote:
> >>>On 21.08.20
Package: gcc-4.5
Version: 4.5.1-2
Severity: normal
$ cat a.c
#pragma GCC optimize("-O3")
int main(void)
{
return 0;
}
$ gcc-4.5 -o /dev/null -c -O2 -flto a.c
a.c:6:1: sorry, unimplemented: gimple bytecode streams do not support the
optimization attribute
--
To UNSUBSCRIBE, email to debi
On Mon, Aug 23, 2010 at 02:05:25PM +0200, Matthias Klose wrote:
> On 23.08.2010 13:30, Pierre Habouzit wrote:
> >On Mon, Aug 23, 2010 at 01:21:04PM +0200, Pierre Habouzit wrote:
> >>On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote:
> >>>On 21.08.20
On Mon, Aug 23, 2010 at 02:02:35PM +0200, Matthias Klose wrote:
> On 23.08.2010 13:21, Pierre Habouzit wrote:
> >On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote:
> >>On 21.08.2010 14:56, Julien Cristau wrote:
> >>>On Fri, Aug 20, 2010 at 19:33
issues such as #593876 where the
> stricter linking breaks existing code. I'm not sure about the
> rationale for this extra strictness, but it does cause
> unwanted breakage by breaking existing assumptions about
> indirect linking.
Well, I think you can revert to the old behaviou
On Mon, Aug 23, 2010 at 01:21:04PM +0200, Pierre Habouzit wrote:
> On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote:
> > On 21.08.2010 14:56, Julien Cristau wrote:
> > >On Fri, Aug 20, 2010 at 19:33:12 +0200, Arthur Loiret wrote:
> > >
> > >>N
> >I've tried it or anything.
>
> I don't share your understanding. I tried it for some builds.
I've tried it on the work repository, and lto ICEs the compiler. Plus I
get 2 other independant ICEs that I've not had time to reduce (hence the
lack of bug report yet).
T
ther issue that pops up at the -O0 level that never shows up with any
other gcc release. And I deeply trust the mentioned code to be correct.
The code in question uses a lot of gcc __builtin_* functions if that
helps (ctz, clz, bswap among other).
On Thu, Apr 01, 2010 at 01:38:20AM +0200, Pierre Habo
Package: gcc-4.4
Version: 4.4.3-4
Severity: grave
Since gcc-4.4 version 4.4.3-4 (and yes -5 is still affected), gcc miscompiles
__builtin_expect when no optimization is set (at least).
Test case:
int foo(int t) {
if (__builtin_expect(t & 0x100, 0))
return 0;
retur
On Tue, Mar 25, 2008 at 08:39:01AM +, Bastian Blank wrote:
> On Tue, Mar 25, 2008 at 09:26:51AM +0100, Pierre Habouzit wrote:
> > Problem is that memcpy/memmove/memset probably generate rep stos; in
> > the end, I believe memset/memcpy/memmove to be async signal safe, an
with gcc-4.2 on i386/amd64 to
avoid any problems as the toolchain freeze is RSN, and that we can't
afford a broken toolchain right now.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpao6lJq8rmi.pgp
Description: PGP signature
g e.g. is really nice). And the g++ strictness wrt
headers is important to have, else code developed on Debian would need
porting to work on other distributions. I believe Debian to be an
excellent development platform, and we should not lag behind wrt stable
development tools.
[1] http://gcc.
On Sun, Mar 23, 2008 at 07:41:59PM +, Pierre Habouzit wrote:
> On Sun, Mar 23, 2008 at 04:54:29PM +, Matthias Klose wrote:
> > > On Sun, Mar 23, 2008 at 07:15:11AM +, Mike Hommey wrote:
> > > > Isn't it risky for partial upgrades from etch ? Shouldn
a signal handler. I
happened to do that on software at work, those are not open source, but
I would fail to see why we should not support them properly.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpJD6aYxSmrE.pgp
Description: PGP signature
On Sun, Mar 23, 2008 at 07:23:10PM +, Florian Weimer wrote:
> * Pierre Habouzit:
>
> >> Isn't it risky for partial upgrades from etch ? Shouldn't we wait for
> >> lenny+1 to revert this ?
> >
> > I second that, please don't revert the patch
rt the patch until lenny+1. FWIW I
believe the release team as a whole wanted the patch to be kept as well,
but I'll let the other members correct me if I'm wrong.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgppVczXzW84q.pgp
Description: PGP signature
uts 2, "-c" on the stack, which confuses the C.
I believe that D should do the implicit cast in that case, as it'll
break a _lot_ of programs using C APIs and variadic arguments in very
subtle ways.
--
·O· Pierre Habouzit
··O
Package: gdc-4.1
Version: 0.25-4.1.2-17
Severity: grave
Justification: renders package unusable
The following code triggers the issue:
--
import std.c.process;
int main(char args[][]) {
execl("/bin/sh", "sh", "-c", "ls", null);
printf("%m\n"
Package: gdc-4.1
Version: 0.24-4.1.2-16
Severity: grave
Justification: renders package unusable
$ cat test.d
import std.c.stdio;
int main()
{
FILE *files[1] = [stdin];
return 0;
}
$ gdc -o /dev/null test.d
/tmp/cc2CdHzH.o:(.data._D29TypeInfo_S3std1c5stdio6_iobuf6__initZ[_D29TypeInfo_S3st
On Wed, May 16, 2007 at 03:33:50PM +0200, Martin Michlmayr wrote:
> * Pierre Habouzit <[EMAIL PROTECTED]> [2007-05-11 17:51]:
> > btree.c: In function 'fbtree_fetch':
> > btree.c:988: internal compiler error: in expand_builtin_expect, at
> > builtins.c:508
On Fri, May 11, 2007 at 04:46:28PM +0200, Martin Michlmayr wrote:
> * Pierre Habouzit <[EMAIL PROTECTED]> [2007-05-11 16:34]:
> > does not work:
> > /usr/lib/gcc-snapshot/bin/gcc -O2 -o a.o a.c
> > a.c: In function 'main':
> > a.c:12: warning: pass
Package: gcc-snapshot
Version: 20070422-1
Severity: important
sample code:
=
#include
#include
#include
static int bar(void *p)
{
return (int)(intptr_t)p;
}
static int foo(const void *p)
{
return bar((void *)p);
}
int main(void)
{
printf("%d\n
*
> drwxr-xr-x 4 root root 4096 Apr 1 20:35 /usr/lib/gcc/i486-linux-gnu/4.0.3
>
> Somehow, this needs to be redesigned, else we'll have broken links every
> other week or so. This results in build failures like #364959.
--
·O· Pierre Habouzit
··O
gh
merges, and still permit users to go in one click to the right remote
bug report. That achieves IMHO the best compromise.
Don't hesitate to contact [EMAIL PROTECTED] to ask for
improvements !
Cheers,
[1] http://lists.debian.org/debian-devel/2006/05/msg00144.html
--
·O·
cussions from now on,
on how to make bts-link better suits your needs.
There is no problems, only solutions.
best regards,
[1] http://lists.debian.org/debian-devel/2006/05/msg00078.html
and the rest of the thread.
--
·O· Pierre Habouzit
··O[E
Le Jeu 4 Mai 2006 09:01, Dererk a écrit :
> I wonder if that means the bug was set as resolved/fixed...
>
> I'm afraid I still having the same bug...
>
> Waiting for news...
it means that the bug is *maybe* fixed upstream. meaning in the next
version.
--
·O·
>Submitter-Id: net
>Originator:MadCoder
>Organization:
>Confidential: no
>Synopsis: Error of compilation of GCJ-3.0 (debian gcj-3.0.4-5
>Severity: critical
>Priority: medium
>Category: java
>Class: wrong-code
>Release: 3.0.4 (Debian testing/unstable)
>Envi
30 matches
Mail list logo
