Link time optimizations are an optimization that helps with a single digit
percent number optimizing both for smaller size, and better speed. These
optimizations are available for some time now in GCC. Link time optimizations
are also at least turned on in other distros like Fedora, OpenSuse
On 12/1/20 5:02 AM, YunQiang Su wrote:
> I am sorry for the later response.
>Hi,
>
> I am an active porter for the following architectures and I intend
> to continue this for the lifetime of the Bullseye release (est. end
> of 2024):
>
> For mipsel and mips64el, I
> - test most
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream
branch, and binutils based on a binutils package taken from the 2.35 branch.
I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available
(upstream targets mid July). binutils will be updated before
On 2/3/20 2:27 PM, Anatoly Pugachev wrote:
> Package: libgcc1
> Version: 1:10-20200202-1
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> apt update && apt upgrade -y
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
GCC 9 was released earlier this year, it is now available in Debian
testing/unstable. I am planning to do the defaults change in mid August, around
the time of the expected first GCC 9 point release (9.2.0).
There are only soname changes for rather unused shared libraries (libgo)
involved, and
The recent gcc-8 and gcc-9 uploads to unstable are now built using pgo and lto
optimization. Not on all architectures, see debian/rules.defs. On the plus
side the compilers are 7-10% faster, however the build time of the compiler is
much longer, adding 10-20 hours. If people feel that this
On 26.05.19 21:13, Matthias Klose wrote:
> The openjdk-8 packages which were unfortunately removed from unstable
> (although
> the issue #915620 only asked for the removal of some binaries), are now again
> in
> NEW, targeting unstable. One of the FTP assistants is objectin
On 13.04.19 17:01, Joerg Jaspert wrote:
> On 15371 March 1977, Aurelien Jarno wrote:
>
>>> How is the move to debian-ports supposed to happen? I won't have the
>>> time to do anything about it within the 2 weeks.
>
>> The process to inject all packages to debian-ports is to get all the
>> deb,
On 07.07.18 17:24, YunQiang Su wrote:
> Niels Thykier 于2018年6月28日周四 上午4:06写道：
>> List of concerns for architectures
>> ==
>>
>> The following is a summary from the current architecture qualification
>> table.
>>
>> * Concern for ppc64el and s390x: we are dependent
GCC 8 is available in testing/unstable, and upstream is approaching the first
point release. I am planning to make GCC 8 the default at the end of the week
(gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC
are already used in the version built from GCC 8, so I don't
According to [1], binutils 2.31 (currently in experimental) will branch in about
a week, and I'll plan to upload the branch version to unstable. Test results
are reported to [2], these look reasonable, except for the various mips targets,
however as seen in the past, it doesn't make a
On 24.11.2016 19:10, Jose E. Marchesi wrote:
>
> I'm pretty confident that --with-cpu=ultrasparc won't do any harm in
> 64-bit mode, but Jose (CC'ed as gcc upstream) will hopefully correct
> me here if I'm wrong.
>
> The cpu selected in --with-cpu impacts both -m64 and -m32 in a
Control: tags -1 - patch
On 23.11.2016 18:58, John Paul Adrian Glaubitz wrote:
> Hi Matthias!
>
> On 11/23/2016 06:09 PM, Matthias Klose wrote:
>> why do you set this for the 64bit multilib as well?
>
> I was actually hoping you would comment on this :). I wasn't sure whet
if you want to include the libgo port into the
gcc-6 Debian packages.
Matthias
proposed patches, please really check
On 16.10.2016 19:40, James Clarke wrote:
> Control: tags -1 - help + patch
>
> Hi Matthias,
> On Thu, Oct 13, 2016 at 01:50:43PM +0200, Matthias Klose wrote:
>>
[CCing porters, please also leave feedback in #835148 for non-release
architectures]
On 29.09.2016 21:39, Niels Thykier wrote:
> Hi,
>
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
> * It is a substantial
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
>
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
No, you are not
On 15.09.2016 22:43, Helge Deller wrote:
> Hi Matthias,
>
> On 10.09.2016 00:48, Matthias Klose wrote:
>> While the Debian Release team has some citation about the quality of the
>> toolchain on their status page, it is not one of the release criteria
>> documented
&
On 10.09.2016 09:59, Paul Gevers wrote:
> Hi,
>
> On 10-09-16 00:48, Matthias Klose wrote:
>> - fpc not available on powerpc anymore (may have changed recently)
>
> For whatever it is worth, this was finally fixed this week. It is
> missing on mips*, ppc64el and s390
While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team. I'd like to document the status how I do understand it for
some of the toolchains available in Debian.
I appreciate that
On 06/18/2015 10:54 PM, John Paul Adrian Glaubitz wrote:
On 06/17/2015 11:47 PM, John Paul Adrian Glaubitz wrote:
Send a patch if you feel it is worth it.
Currently working on that. Will throw in a patch once I got a working
build which I will be uploading to unreleased.
Attached patch
On 02/05/2015 10:05 PM, Helmut Grohne wrote:
Source: gcc-4.9
Version: 4.9.1-17
User: helm...@debian.org
Usertags: rebootstrap
gcc-4.9 currently FTBFS on sparc64 due to symbol errors. While the last
two builds on sompek failed due to -ENOSPC the build of 4.9.1-17 shows
proper symbol diffs:
of where to begin.
I have a box with gcc-4.9, plenty of disk space, and electricity to burn.
Where do I start?
Patrick
On Thu, May 8, 2014 at 10:25 AM, Matthias Klose d...@debian.org wrote:
With gcc-4.9 now available in testing, it is time to prepare for the change
of
the default to 4.9
With gcc-4.9 now available in testing, it is time to prepare for the change of
the default to 4.9, for a subset of architectures or for all (release)
architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already
point to 4.9 and are used on all architectures. Issue #746805
Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar:
For mips/mipsel, I - fix toolchain issues together with other developers at
ImgTec
It is nice to see such a commitment, however in the past I didn't see any such
contributions.
Matthias
--
To UNSUBSCRIBE, email to
Am 16.12.2013 11:34, schrieb Matthias Klose:
Package: java-common
Version: 0.50
Severity: serious
Tags: jessie, sid
openjdk-7 currently ftbfs on sparc, sparc64, s390, kfreebsd-any. So please
either remove the default-* packages on these archs, or fall back to gcj.
- the hotspot port
gcc-4.9 is uploaded to experimental, asking the porters to watch for build
failures and corresponding patches. See
https://buildd.debian.org/status/package.php?p=gcc-4.9suite=experimental
These are already fixed in the vcs.
- fixed the gospec.c ftbfs on archs without ld.gold
- fixed the g++
please see http://bugs.debian.org/732282
Is there anybody who wants to maintain openjdk for these architectures? If not,
I'll go ahead and make gcj-jdk the default again on those architectures and
request removal of the kfreebsd and sparc binaries.
Matthias
--
To UNSUBSCRIBE, email to
Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto:
Hi,
I don't know whether it is appropriate that I remark,
I have no objection to moving to gcc-4.8 on ppc64, too.
this is not a question about any objections, but about a call to the ppc64
porters if they are able to maintain such a port in
Am 23.11.2013 14:01, schrieb Aurelien Jarno:
The patch I sent for MIPS also mentions SPARC as it has the same
alignment constraints. That said the patch fixes zero, while SPARC is
using hotspot by default instead. Maybe using zero on SPARC is a
possibility, though it will decrease
Am 29.10.2013 17:48, schrieb Ian Jackson:
(Mind you, I have my doubts about a process which counts people
promising to do work - it sets up some rather unfortunate incentives.
I guess it's easier to judge and more prospective than a process which
attempts to gauge whether the work has been
Am 15.06.2013 03:22, schrieb Stephan Schreiber:
GCC-4.8 should become the default on ia64 soon; some other changes are
desirable:
- The transition of gcc-4.8/libgcc1 to libunwind8.
- A removal of the libunwind7 dependency of around 4600 packages on ia64 -
when
they are updated next time
Am 13.06.2013 21:47, schrieb Thorsten Glaser:
Matthias Klose dixit:
The Java and D frontends now default to 4.8 on all architectures, the Go
frontend stays at 4.7 until 4.8 get the complete Go 1.1 support.
I’d like to have gcj at 4.6 in gcc-defaults for m68k please,
until the 4.8 one
Am 13.06.2013 16:46, schrieb Steven Chamberlain:
Hi,
On 13/06/13 13:51, Matthias Klose wrote:
GCC 4.8 is now the default on all x86 architectures, and on all ARM
architectures (the latter confirmed by the Debian ARM porters). I did not
get
any feedback from other port maintainers, so
Am 07.05.2013 15:25, schrieb Matthias Klose:
The decision when to make GCC 4.8 the default for other architectures is
left to the Debian port maintainers.
[...]
Information on porting to GCC 4.8 from previous versions of GCC can be
found in the porting guide http://gcc.gnu.org/gcc-4.8
It's time to change the Java default to java7, and to drop java support on
architectures with non-working java7.
Patches for the transition to Java7 should be available in the BTS, mostly
submitted by James Page. Some may be still lurking around as diffs in Ubuntu
packages, apologies for that.
Am 31.01.2013 10:11, schrieb Roberto Bagnara:
On 01/31/13 00:01, Matthias Klose wrote:
Am 30.01.2013 01:17, schrieb Matthias Klose:
[CCing the debian s390 porters]
Am 29.01.2013 09:32, schrieb Roberto Bagnara:
I just hit the wrong button on the administrative interface
of the ppl-devel
Am 30.01.2013 01:17, schrieb Matthias Klose:
[CCing the debian s390 porters]
Am 29.01.2013 09:32, schrieb Roberto Bagnara:
I just hit the wrong button on the administrative interface
of the ppl-devel mailing list. So the message has gone
forever before I could read it.
Please resend
GCC 4.7 is now the default for x86 architectures for all frontends except the D
frontends, including KFreeBSD and the Hurd.
There are still some build failures which need to be addressed. Out of the ~350
bugs filed, more than the half are fixed, another quarter has patches available,
and the
On 07.05.2012 19:35, Thorsten Glaser wrote:
Matthias Klose dixit:
GCC 4.7 is now the default for x86 architectures for all frontends except
the D
frontends, including KFreeBSD and the Hurd.
How are the plans for other architectures?
I don't have plans to change any other architectures
GCC-4.7 packages are now available in testing and unstable; thanks to Lucas'
test rebuild, bug reports are now filed for these ~330 packages which fail to
build with the new version [1]. Hints how to address the vast majority of these
issues can be found at [2].
I'm planning to work on these
Please have a look at the gcc-4.7 package in experimental, update patches (hurd,
kfreebsd, ARM is fixed in svn), and investigate the build failures (currently
ia64, but more will appear).
Matthias
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of
Package: openjdk-7
Version: 7~b136-2.0~pre1-2
Severity: important
fails to build hotspot in stage1
g++-4.6 -DLINUX -D_GNU_SOURCE -DSPARC -DPRODUCT -I.
-I/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/share/vm/prims
On 04/17/2011 09:33 PM, Adam D. Barratt wrote:
On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote:
I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start. GCC-4.5 is already used as the default
compiler for almost any other
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote:
On 26 April 2011 18:03, Matthias Klosed...@debian.org wrote:
I'll make GCC 4.6 the default after the release of
GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
powerpc.
Could you include armhf in the list as well?
On 04/26/2011 09:28 PM, Kurt Roeckx wrote:
On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote:
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote:
I'll make GCC 4.6 the
default after the release of GCC 4.5.3, expected later this week, at
least on amd64, armel, i386
On 02.03.2011 07:36, Konstantinos Margaritis wrote:
On 2 March 2011 03:34, Matthias Klose d...@debian.org wrote:
I'll make gcc-4.5 the default for (at least some) architectures within the
next
two weeks before more transitions start. GCC-4.5 is already used as the
default
compiler
On 02.03.2011 17:54, Martin Guy wrote:
On 2 March 2011 02:34, Matthias Klose d...@debian.org wrote:
armel (although optimized for a different processor)
Hi
For which processor (/architecture) is it optimized, and do you mean
optimized-for, or only-runs-on?
I ask in case this would mean
I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start. GCC-4.5 is already used as the default
compiler for almost any other distribution, so there shouldn't be many surprises
on at least the common architectures. About 50% of the
On 16.11.2010 10:42, Roger Leigh wrote:
On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote:
On 14.11.2010 13:19, Julien Cristau wrote:
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
For wheezy I'm planning to change the linking behaviour for DSOs
(turning
On 15.11.2010 07:16, Roland McGrath wrote:
mattst88 airlied_, does Fedora use --as-needed by default? Fedora 14 too?
airlied_ mattst88: yes
The naming of the options makes people easily confused.
--no-add-needed is the only option Fedora's gcc passes.
yes, OpenSuse is using --as-needed,
On 14.11.2010 16:06, Roger Leigh wrote:
While I understand the rationale for --no-copy-dt-needed-entries for
preventing encapsulation violations via indirect linking, I don't agree
with the use of --as-needed *at all*. If a library has been explicitly
linked in, it shouldn't be removed. This
On 14.11.2010 13:19, Julien Cristau wrote:
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
For wheezy I'm planning to change the linking behaviour for DSOs
(turning on --as-needed and --no-copy-dt-needed-entries. The
rationale is summarized in
http://wiki.debian.org/ToolChain
On 16.11.2010 01:24, Roger Leigh wrote:
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote:
On 14.11.2010 16:06, Roger Leigh wrote:
While I understand the rationale for --no-copy-dt-needed-entries for
preventing encapsulation violations via indirect linking, I don't agree
For wheezy I'm planning to change the linking behaviour for DSOs (turning on
--as-needed and --no-copy-dt-needed-entries. The rationale is summarized in
http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues
with these changes on some of the Debian ports, and if we need
tag 566242 + wontfix
tag 566242 + upstream
tag 566242 + fixed-upstream
fixed in 4.5. won't fix in 4.4. Use -mcpu=v9 as a workaround for gcc-4.4.
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Besides the open license issue, are there any objections from port maintainers
to make GCC-4.4 the default?
As a first step that would be a change of the default for C, C++, ObjC, ObjC++
and Fortran.
I'm not sure about Java, which show some regressions compared to 4.3. Otoh it's
not amymore
On 06.09.2009 16:49, Jurij Smakov wrote:
On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote:
On 19.08.2009 16:33, Bastian Blank wrote:
On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote:
On 19.08.2009 13:42, Bastian Blank wrote:
On Wed, Aug 19, 2009 at 01:16:36PM
On 20.08.2009 16:52, Aurelien Jarno wrote:
Bastian Blank a écrit :
On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
I did speak with Martin Zobel at Debconf on how to get there, having two
proposals:
- define a new sparc64 port, and bootstrap this one using the 32bit port
On 19.08.2009 16:33, Bastian Blank wrote:
On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote:
On 19.08.2009 13:42, Bastian Blank wrote:
On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
I did speak with Martin Zobel at Debconf on how to get there, having two
On 18.08.2009 22:43, Jurij Smakov wrote:
Hello,
I would like to point out that sparc release requalification is currently
placing it in at risk position for squeeze release. The most serious
problems with the port are lack of developer involvement (there is currently
one active porter/developer
On 19.08.2009 13:42, Bastian Blank wrote:
On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
I did speak with Martin Zobel at Debconf on how to get there, having two
proposals:
- define a new sparc64 port, and bootstrap this one using the 32bit port.
This is rather easy. I
Mike Hommey schrieb:
On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
Luk Claes schrieb:
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern
Luk Claes schrieb:
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
http://lists.debian.org/debian-release/2009/04/msg00303.html
Note
Hi,
openjdk-6 in unstable is updated to the 6b14 code drop, built from a recent
IcedTea snapshot. There are a few regressions in the ports which don't use the
hotspot VM, but the Zero VM. Help from porters would be appreciated.
There are two new binary packages offering additional JVMs:
-
tag 479185 + moreinfo
severity 479185 important
thanks
this fails with 4.1, 4.2 and 4.3. At least 4.1 wasn't changed at all,
so I assume the main reason is not GCC, but something else. The
configury of this package uses the running kernel, which is
64bit. Does this lead to some wrong
Besides m68k hopelessly being behind we do have serious problems on
alpha, arm and hppa.
- on arm, the bytecode compiler (ecj) doesn't produce correct code.
there is currently a workaround to build the package on arm using
byte-compiled code built on another architecture. Aurelian has
The plans for the GCC 4.2 transition were described in
http://lists.debian.org/debian-devel-announce/2007/06/msg8.html
Does any port still need to stick with GCC 4.1 for a while? Feedback
from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show
objections against the transition.
While having built and uploaded things correctly for experimental, I
didn't do the same for unstable, which now needs some manual
intervention building gnat-4.1 and gcj-4.1.
gnat-4.1 (mips mipsel s390 sparc):
- work in a sid chroot
- install gnat-4.1-base libgnat-4.1 libgnatprj4.1
This is reported as http://gcc.gnu.org/PR17180 . Please could somebody
on the list try to identify the patch mentioned in the followups which
triggers these failures?
Thanks, Matthias
Martin Habets writes:
Package: gcc-3.3
Version: 1:3.3.4-1
Severity: normal
Am building linux kernel 2.6.6 with CONFIG_CC_OPTIMIZE_FOR_SIZE=y set in
.config.
This results in -Os parameter to gcc.
Resulting kernel does not boot and causes an oops (see below). This comes from
this code
on debian-sparc to take care of that or fix
the multilib build?
Matthias
Martin v. Loewis writes:
Matthias Klose [EMAIL PROTECTED] writes:
ok, I'm forwarding this to Martin and Phil, two upstream developers
(hopefully still ;-) listening on debian-gcc.
I would suggest
Roy Bixler writes:
I am running Sid and have recently been compiling many kernels in an
effort to get the 'ncpfs' filesystem to work on the Ultrasparc. Using
the egcs64 package works for kernel 2.4.19 but it chokes on
2.4.20-pre5 with an internal compilation error. I then tried to
compile
I'm unable to test this on sparc (Ben?). Anyway:
- which packages and versions are installed before? (gcc-3.0,
gcc-3.0-sparc64, gcc-3.0-base)
- does removing the old packages (gcc-3.0, gcc-3.0-sparc64) work
around the problem?
[EMAIL PROTECTED] writes:
Package: gcc-3.0-sparc64
Version:
Please could someone look at #103568 and see if the proposed fix let's
gcc-3.0 bootstrap on sparc?
Richard Braakman writes:
Package: bash (main).
Maintainer: Matthias Klose [EMAIL PROTECTED]
[STRATEGY] Matthias Klose has bash 2.03 almost ready.
51188 bash: fails miserably on sparc
Please could someone verify this with bash-2.03-1 ?
I saw a bug filed against libreadline2 (libc5), that this package
should not be built anymore for sparc. Is altgcc still needed for
sparc (and the patch from report #29585) ?
severity 50048 normal
thanks
this package will be removed soon ...
Ben Collins writes:
On Sat, Nov 13, 1999 at 11:02:32AM +0100, Matthias Klose wrote:
There is a bug against ftp.debian.org to remove egcs (and
libg++2.8.2-dev) from potato. The current libg++, which works with
gcc-2.95
There is a bug against ftp.debian.org to remove egcs (and
libg++2.8.2-dev) from potato. The current libg++, which works with
gcc-2.95 ist libg++2.8.1.3. Are there problems, that gcc-2.95 does not
correctly work on sparc?
Is this really a grave bug for sparc?
Madarasz Gergely writes:
Package:
[CC to some Debian places; anybody who has time to backport it?]
Tom Tromey writes:
Matthias == Matthias Klose [EMAIL PROTECTED] writes:
Matthias Now that libgc5 is merged in the HEAD brnach of libgcj, it
Matthias should build. But: Debian potato will ship with
Matthias gcc-2.95.2
You can find a new egcs snapshot on master in
http://master.debian.org/~doko/
(soon to be moved to project/experimental). What's new?
- rewritten sparc backend (includes ultrasparc support).
- major (?) performance increase at least for dhrystone on ppro (9%)
(see
80 matches
Mail list logo
