trunk configured on i486 (on x86_64 hardware) with
--enable-targets=all i486-linux-gnu
fails to configure the first 64bit library (libiberty), not finding
the correct libgcc.
/scratch/packages/gcc/snap/gcc-snapshot-20070110/build/i486-linux-gnu/64/libiberty$
/scratch/packages/gcc/snap/gcc-sna
Mike Stump schrieb:
It appears that one of these:
+ '[' -s .bad_compare ']'
+ exit 1
I have a feeling sed -i isn't our friend.
fixed.
Matthias
2007-03-06 Matthias Klose <[EMAIL PROTECTED]>
* doc/Makefile.am(gkeytool.pod): Don't use sed -i.
Florian Weimer writes:
> Is there a convenient switch to make GCC bootstrap on Debian/amd64
> without patching the build infrastructure? Apparently, GCC tries to
> build 32-bit variants of all libraries (using -m32), but the new
> compiler uses the 64-bit libc instead of the 32-bit libc, hence
> b
FX Coudert writes:
> Hi all,
>
> My nightly bootstrap of mainline on i386-linux failed tonight, on
> revision 123192, with:
>
> /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/
> decLibrary.c: In function ?isinfd64?:
> /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdec
Laurent GUERBY writes:
> Hi, fromm gcc-testresults here is where we stand on 4.0/Ada after
> the tree-sra Ada patch. I'm looking for results for platforms where I
> believe Ada could work:
>
> powerpc-linux
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01875.html
Paolo Carlini writes:
> Eric Botcazou wrote:
>
> >>hmm, I get a few libstdc++ testsuite failuers
> >>
> >>http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00304.html
> >>
> >>other than that, looks pretty fine.
> >>
> >>
> >Did you get them with 4.0.0 too? If no, the libstdc++ folks will
currently the C++ include directories for biarch builds
(i.e. i486-linux-gnu, x86_64-linux-gnu) are not set properly for the
non-default target. At least the c++config.h header differs. On
i486-linux-gnu a x86_64-linux dir is installed, but is not used, for
powerpc-linux-gnu, no powerpc64-linux-gnu
Mark Mitchell writes:
> Daniel Jacobowitz wrote:
>
> >>My inclination is to do nothing (other than correct the target
> >>milestones on these bugs in bugzilla) and move on. The Solaris problem
> >>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
> >>a crisis meriting anoth
On 5/7/20 9:02 AM, Jonathan Wakely wrote:
> On Thu, 7 May 2020 at 07:28, Uros Bizjak via Gcc wrote:
>>
>> On Thu, May 7, 2020 at 8:16 AM Richard Biener
>> wrote:
>>>
>>> On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc
>>> wrote:
Hello!
I wonder, if the build process rea
[not subscribed to the libc-alpha list]
GCC and glibc need to agree on the install location for math-vector-fortran.h.
Currently it is installed into
/usr/include/finclude/math-vector-fortran.h
However the file is architecture specific, currently only having variants for
x86_64-*-gnu, x86_64-*
On 6/8/20 1:03 PM, Florian Weimer via Gcc wrote:
> * Matthias Klose:
>
>> [not subscribed to the libc-alpha list]
>>
>> GCC and glibc need to agree on the install location for
>> math-vector-fortran.h.
>> Currently it is installed into
>>
>&g
https://gcc.gnu.org/gcc-8/criteria.html lists the little endian platform first
as a primary target, however it's not mentioned for GCC 9 and GCC 10. Just an
omission?
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-07/msg00854.html suggests that
the little endian platform should be mentioned, and m
On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote:
> On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose wrote:
>>
>> https://gcc.gnu.org/gcc-8/criteria.html lists the little endian platform
>> first
>> as a primary target, however it's not mentioned for GCC 9
On 7/17/20 9:19 AM, Romain Naour wrote:
> Hello,
>
> Le 15/07/2020 à 13:50, Richard Biener a écrit :
>>
>> The first release candidate for GCC 10.2 is available from
>>
>> https://gcc.gnu.org/pub/gcc/snapshots/10.2.0-RC-20200715/
>> ftp://gcc.gnu.org/pub/gcc/snapshots/10.2.0-RC-20200715/
>>
>> a
On 12/14/20 10:21 PM, Joseph Myers wrote:
> On Mon, 14 Dec 2020, Martin Liška wrote:
>
>> +spawn -noecho pytest -rA -s --tb=no $script
>
> "pytest" might not be the right command everywhere. If I install
> python3-pytest on Ubuntu 20.04 I only get /usr/bin/pytest-3 not
> /usr/bin/pytest.
On 4/1/21 2:35 PM, Richard Biener wrote:
>
> The first release candidate for GCC 10.3 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
> ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/
>
> and shortly its mirrors. It has been generated from git commit
>
On 4/6/21 12:27 PM, Richard Biener via Gcc wrote:
> On Thu, Apr 1, 2021 at 9:21 PM Ian Lance Taylor via Gcc
> wrote:
>>
>> On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell wrote:
>>>
>>> Richard Biener pointed out dysfunction in the SC. The case of the
>>> missing question I asked in 2019 also po
On 08/26/2015 09:41 PM, Jeff Law wrote:
> On 08/26/2015 01:31 PM, Eric S. Raymond wrote:
>>> mib = mib
> Michael Bushnell. Aagain, not active in forever. m...@geech.gnu.ai.mit.edu
> probably doesn't work anymore.
>
>> miles = miles
> Miles Bader. mi...@gnu.ai.mit.edu
>
>> mkoch = mkoch
> Mic
On 15.10.2015 17:57, Cary Coutant wrote:
PR gold/19119
* options.h (General_options): Remove "obsolete" from -m.
I'm a little reluctant to remove "obsolete" from the description --
maybe "deprecated" instead?
* parameters.cc (set_parameters_target): Check if input t
On 25.10.2015 18:40, H.J. Lu wrote:
On Sun, Oct 25, 2015 at 10:37 AM, Matthias Klose wrote:
On 15.10.2015 17:57, Cary Coutant wrote:
PR gold/19119
* options.h (General_options): Remove "obsolete" from -m.
I'm a little reluctant to remove "obsolete&q
On 26.10.2015 01:14, H.J. Lu wrote:
Please open a gold bug with missing emulations.
PR gold/19172
On 01.12.2015 03:58, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at the end.
This macro *should* work for cross-compiling but somehow
.
2015-12-02 Matthias Klose
* configure.ac: Move AM_ENABLE_MULTILIB before
GCC_LIBSTDCXX_RAW_CXX_FLAGS.
* configure: Regenerate.
Here are some first results from a distro test rebuild using GCC 6. A snapshot
of the current Ubuntu development series was taken on 20151218 for all
architectures (amd64, arm64, armhf, i386/i686, powerpc, ppc64el, s390x), and
rebuilt unmodified using the current GCC 5 branch, and using GCC 6 20
On 22.01.2016 06:09, Martin Michlmayr wrote:
In terms of build failures, I reported 520 bugs to Debian. Most of them
were new GCC errors or warnings (some packages use -Werror and many
-Werror=format-security).
Here are some of the most frequent errors see:
[...]
Martin tagged these issues; h
On 22.01.2016 08:27, Matthias Klose wrote:
On 22.01.2016 06:09, Martin Michlmayr wrote:
In terms of build failures, I reported 520 bugs to Debian. Most of them
were new GCC errors or warnings (some packages use -Werror and many
-Werror=format-security).
Here are some of the most frequent
With the removal of libgcj, the only user of libffi in GCC is libgo, however
there is now no maintainer listed anymore for libffi in the MAINTAINERS file,
and the libffi subdir is a bit outdated compared to the libffi upstream
repository (got aware of this by libffi issue #197). Who would be respo
With the removal of GCJ, boehm-gc is now only used in libobjc to build an
additional variant of libobjc. In the GCJ removal thread I proposed to remove
boehm-gc and build the libobjc_gc variant using an external boehm-gc, however
that didn't find everybody's approval. Assuming that boehm-gc shoul
Here are the results of a first test rebuild of the Debian (amd64) and Ubuntu
(all architectures) archives. The test was started with a GCC trunk around
20161202, and then build failures were retried later with r243559. I filed
around 10-15 issues for ICEs, the most of them already fixed on the tr
On 06.01.2017 15:13, Szabolcs Nagy wrote:
> On 06/01/17 13:11, Jakub Jelinek wrote:
>> On Fri, Jan 06, 2017 at 01:07:23PM +, Szabolcs Nagy wrote:
>>> On 06/01/17 12:48, Jakub Jelinek wrote:
SUSE and some other distros use a hack that omits the minor and patchlevel
versions from the di
On 06.01.2017 13:48, Jakub Jelinek wrote:
> Hi!
>
> SUSE and some other distros use a hack that omits the minor and patchlevel
> versions from the directory layout, just uses the major number, it is very
> uncommon to have more than one compiler for the same major number installed
> in the same pr
Ada binaries for powerpc64le-linux-gnu can be found at [1], these should be good
for bootstrapping (or install gnat-4.8 in Ubuntu 14.04 LTS). Ada should then be
buildable from the 4.9.0 release. Install the deb, or use ar(1) on the deb file
to extract the files. Thanks to Ulrich Weigand helping a
Am 02.06.2014 22:30, schrieb Eric Botcazou:
>> I have successfully built without the switch, but I am not sure of the
>> effects at runtime.
>
> For sure libitm cannot work, there is a 'flushw' in config/sparc/sjlj.S.
>
>> If V9 is indeed required, is there a way to build without those libs? Or
>
on some linux architectures there are some symbols missing in libstdc++.so.6
built from the 4.9 branch. I didn't notice before due to a packaging bug.
affected are ARM32, HPPA, SPARC.
- ARM32 (build log [1], both soft and hard float) are missing
__aeabi_atexit@CXXABI_ARM_1.3.3
__aeabi_
Am 01.07.2014 11:32, schrieb Jonathan Wakely:
> On 1 July 2014 09:40, Matthias Klose wrote:
>> - HPPA (build log [2]), is missing all the future_base symbols and
>>exception_ptr13exception symbols, current_exception and
>>rethrow_exception.
>
> This implies AT
Am 08.10.2014 um 09:16 schrieb Richard Biener:
> On Tue, 7 Oct 2014, Marek Polacek wrote:
> I think it makes sense to do this (and I expect C++ will follow
> with defaulting to -std=c++11 once the ABI stuff has settled).
>
> Of course it would be nice to look at the actual fallout in
> a whole-dis
Both gccjit and gnat now use sphinx to build the documentation. While not a
direct part of the build process, it would be nice to document the requirements
on sphinx, and agree on a common version used to generate that documentation.
Coming from a distro background where I have to "build from sou
In the past (at least it worked for me in 4.9) it was possible to use the
uninstalled C & C++ compilers to build another compiler, using the just built
compilers. Useful if you want to build e.g. libgccjit in a second step without
bootstrapping again. This doesn't seem to work anymore with 5. At
On 03/31/2015 01:09 PM, Matthias Klose wrote:
> In the past (at least it worked for me in 4.9) it was possible to use the
> uninstalled C & C++ compilers to build another compiler, using the just built
> compilers. Useful if you want to build e.g. libgccjit in a second st
This is seen in a distro upgrade, with a shared library built using GCC 6, which
now fails to dynamically link, when the library is rebuilt using GCC 8.
Details in https://bugs.debian.org/911090
Jonathan pointed me to PR71712, fixing the C++ mangling.
$ cat > foo.C
#include
struct foo {
I'm running into some issues building LTO+profiled enabled configurations in
some constrained build environment called buildds, having four cores and 16GB of
RAM.
configured for all frontends (maximum number of LTO links) and configured with
--enable-bootstrap \
--with-build-config=bootstrap-
On 30.09.19 18:46, Gaius Mulley wrote:
again is this sensible? Are there [obvious] issues I've missed?
does the profiled LTO build now work? I didn't check recently myself.
Matthias
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision 277823.
I have so far bootstrapped and tested the release candidate o
libsanitizer on trunk only bumps the soversion for asan, but the other libraries
drop some symbols without bumping the soname, Are these changes intended, and
should the soversions be bumped?
Matthias
diff --git a/debian/liblsan0.symbols b/debian/liblsan0.symbols
index f318d9a..5aa23a6 100644
--
On 06.01.20 11:03, Andrew Pinski wrote:
> +GCC
>
> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>>
>> In an archive test rebuild with binutils and GCC trunk, I see a lot of build
>> failures on both aarch64-linux-gnu and arm-linux-gnueabihf failing with
>>
On 06.01.20 13:30, Wilco Dijkstra wrote:
> On 06.01.20 11:03, Andrew Pinski wrote:
>> +GCC
>>
>> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>>>
>>> In an archive test rebuild with binutils and GCC trunk, I see a lot of build
>>> failures o
On 06.01.20 14:29, Matthias Klose wrote:
> On 06.01.20 13:30, Wilco Dijkstra wrote:
>> On 06.01.20 11:03, Andrew Pinski wrote:
>>> +GCC
>>>
>>> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>>>>
>>>> In an archive test reb
On 06.01.20 15:02, Wilco Dijkstra wrote:
>> However, this is an undocumented change in the current NEWS, and seeing
>>> literally hundreds of package failures, I doubt that's the right thing to
>>> do, at
>>> least without any deprecation warning first. Could that be handled,
>>> deprecating
>>>
On 24.02.2017 18:55, NightStrike wrote:
> Currently, to build natively on cygwin, this patch is required to zlib:
>
> https://github.com/Alexpux/MSYS2-packages/blob/master/zlib/1.2.11-cygwin-no-widechar.patch
>
> Otherwise, this error occurs:
>
> ./../zlib/libz.a(libz_a-gzlib.o):gzlib.c:(.text+0
On 16.05.2017 05:35, Bernhard Reutner-Fischer wrote:
> On 16 May 2017 at 14:16, Jonathan Wakely wrote:
>> On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote:
>>> 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2
>>> and later.
>>
>> Ah I missed that in the earlier dis
On 07.06.2017 13:25, Antonio Diaz Diaz wrote:
> Dear GCC steering committee,
>
> This has been recently asked in this list[1], but in case you have missed it
> because of a subject line not explicit enough, I would like to appeal to you
> directly.
>
> [1] http://gcc.gnu.org/ml/gcc/2017-06/msg000
On 17.01.2018 09:19, Richard Biener wrote:
> On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts
> wrote:
>> Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0
>> snapshot, it still is working fine with 7.2.0.
>> I've added bug: 83903
>>
>> x86_64, armv6, armv7, aarch64 all seem
On 18.07.2018 14:49, Joel Sherrill wrote:
> On Wed, Jul 18, 2018, 7:15 AM Jonathan Wakely wrote:
>
>> On Wed, 18 Jul 2018 at 13:06, Eric S. Raymond wrote:
>>>
>>> Jonathan Wakely :
On Wed, 18 Jul 2018 at 11:56, David Malcolm wrote:
> Python 2.6 onwards is broadly compatible with Python 3
On 18.07.2018 19:29, Paul Koning wrote:
>
>
>> On Jul 18, 2018, at 1:22 PM, Boris Kolpackov wrote:
>>
>> Paul Koning writes:
>>
On Jul 18, 2018, at 11:13 AM, Boris Kolpackov
wrote:
I wonder what will be the expected way to obtain a suitable version of
Python if one is
On 19.07.2018 22:20, Karsten Merker wrote:
> David Malcolm wrote:
>> On Tue, 2018-07-17 at 14:49 +0200, Martin Liška wrote:
>>> I've recently touched AWK option generate machinery and it's
>>> quite unpleasant to make any adjustments. My question is
>>> simple: can we starting using a scripting la
On 20.07.2018 20:53, Konovalov, Vadim wrote:
>> From: Segher Boessenkool
>> On Fri, Jul 20, 2018 at 12:54:36PM -0400, Paul Koning wrote:
> Fully agree with that. Coming up with a new scripts written in python2
> really
> makes no sense.
Then python cannot be a build requireme
On 22.07.2018 03:24, Carlo Pisani wrote:
> hi guys
> got some deb files from an old Debian's archive(1), converted .deb
Debian stretch (9) comes with GCC 6, and gnat cross compilers available, same
for Ubuntu 18.04 LTS (GCC 7). It may be better to start with more recent
versions (packages are gna
On 27.07.2018 16:31, Michael Matz wrote:
> Hi,
>
> On Fri, 27 Jul 2018, Michael Matz wrote:
>
>> Using any python scripts as part of generally building GCC (i.e. where
>> the generated files aren't prepackaged) will introduce a python
>> dependency for distro packages. And for those distros th
On 04/21/2011 12:40 PM, Richard Guenther wrote:
A first release candidate for GCC 4.5.3 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.3-RC-20110421/
and shortly its mirrors. It has been generated from SVN revision 172803.
I have sofar bootstrapped and tested the release candid
On 11/10/2011 06:30 PM, Joseph S. Myers wrote:
> On Thu, 10 Nov 2011, Rainer Orth wrote:
>
>> I've recently noticed that several of our target libraries are not
>> properly (if at all) represented as bugzilla components. The following
>> table shows the current situation:
>>
>> directory
On 11/09/2011 07:50 PM, Ian Lance Taylor wrote:
> santi writes:
>
>> I recently updated my Ubuntu 10.10 to 11.10 and since then I have been
>> having problems with my compiler. I have seen that this new Ubuntu
>> distribution uses gcc 4.6 whilest my old 10.10 used gcc 4.4.5 or
>> 4.4.6.
>>
>> The
On 27.07.2009 18:12, Richard Guenther wrote:
A release candidate for the GCC 4.3.4 is now available at
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.4-RC-20090727
I plan to roll out the final release at the beginning of next week
if there are no major problems reported.
testsuite doesn't show regr
On 12.08.2009 23:07, Martin Guy wrote:
On 8/12/09, Joel Sherrill wrote:
So any ACATS results from any other ARM target would be
appreciated.
I looked into gnat-arm for the new Debian port and the conclusion was
that it has never been bootstrapped onto ARM. The closest I have seen
is Adaco
On 17.08.2009 12:00, Mikael Pettersson wrote:
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose wrote:
On 12.08.2009 23:07, Martin Guy wrote:
On 8/12/09, Joel Sherrill wrote:
So any ACATS results from any other ARM target would be
appreciated.
I looked into gnat-arm for the new
On 20.08.2009 10:16, Matthias Klose wrote:
On 17.08.2009 12:00, Mikael Pettersson wrote:
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose
wrote:
On 12.08.2009 23:07, Martin Guy wrote:
On 8/12/09, Joel Sherrill wrote:
So any ACATS results from any other ARM target would be
appreciated.
I
On 24.08.2009 15:57, Toon Moene wrote:
Tobias Grosser wrote:
The problem was in the cloog-ppl headers and was fixed in CLooG-ppl
0.15.4 (I think).
We should add a check for ClooG revision to make configure fail on
outdated cloog 0.15 revisions.
I think that's the best option. I was waiting f
On 09.09.2009 03:07, John David Anglin wrote:
the testsuite on the hppa machine (gcc61 on the compile farm) has
always hanged for me from time to time. However, lately (at least
since I returned from vacation last Monday) it hangs every time.
This is likely a kernel problem. There are lo
--enable-plugin is used by classpath (part of libjava) and now by GCC itself.
disabling the build of the gcjwebplugin now disables plugin support in GCC as
well. Please could the option for enabling GCC plugin support be renamed to
something like --enable-plugins, --enable-gcc-plugin, --enable-g
On 19.10.2009 19:42, Andrew Haley wrote:
Ian Lance Taylor wrote:
Andrew Haley writes:
Matthias Klose wrote:
--enable-plugin is used by classpath (part of libjava) and now by GCC
itself. disabling the build of the gcjwebplugin now disables plugin
support in GCC as well. Please could the
On 05.01.2010 23:29, Ian Lance Taylor wrote:
"H.J. Lu" writes:
On Tue, Jan 5, 2010 at 1:35 PM, Ian Lance Taylor wrote:
Roland McGrath writes:
I'm still not entirely convinced that this is the way to go. It seems
to me that ideally one wants to be able to select the linker at
runtime. I
On 05.01.2010 23:59, Roland McGrath wrote:
>> I'm still not entirely convinced that this is the way to go. It seems
>> to me that ideally one wants to be able to select the linker at
>> runtime. I don't see how this patch supports that. What am I
>> missing?
>
> It covers the first step by lett
A rebuild test of the current Debian unstable distribution on x86_64-linux-gnu
was done, one rebuild test with the current gcc-4.4 from the branch, and another
one with GCC trunk 20100107. The latter did show about 200 additional build
failures, which are listed in [1] (minus some already known
On 23.02.2010 12:10, Manuel López-Ibáñez wrote:
On 23 February 2010 12:00, Richard Guenther wrote:
On Tue, 23 Feb 2010, Manuel López-Ibáñez wrote:
Bootstrapped and regression tested (it seems nothing was testing these
options) on x86_64-unknown-linux-gnu.
OK?
This is ok if nobody has serio
On 14.03.2010 13:15, Basile Starynkevitch wrote:
Basile Starynkevitch wrote in
http://lists.debian.org/debian-gcc/2010/03/msg00047.html
Now, one of the issues about MELT & Debian packaging is the fact that
melt-runtime.c (the source of melt.so plugin) uses GTY
http://gcc.gnu.org/onlinedocs/gcci
For packages of GCC I would like to see a common location where plugins can be
installed; currently a path to the plugin has to be given on the command line,
which is likely to be different for different installations. What about
-fplugin= (without the .so) meaning to search for the plugin in a
Richard Guenther schrieb:
> A release candidate for GCC 4.3.3 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/
>
> and shortly its mirrors. It has been generated from SVN revision 143460.
Lucas did do two test rebuilds of the current Debian lenny/testing archive for
Laurent GUERBY schrieb:
> Before my testresult I could find only trunk 140564
> in september 2008 with a patch by David Daney then no more testresults:
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02009.html
>
> I could'nt find any 4.3 result on mipsel posted on gcc-testresults (?).
>
>
Noticed that some symbols introduced for the exception propagation support are
missing in libstdc++.so.6 on arm-linux-gnueabi, hppa-linux-gnu and
sparc-linux-gnu (no results for mips*-linux yet). The libstdc++ configure check
GLIBCXX_ENABLE_ATOMIC_BUILTINS fails, because three of the five __sync_*
Paolo Carlini schrieb:
> Paolo Carlini wrote:
>> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
>> case conservative to have a link type test identical to the one used in
>> libgomp and libgfortran and a fall back to the .s file (as currently used).
>>
> I committed the bel
Paolo Carlini schrieb:
> Matthias Klose wrote:
>> Paolo Carlini schrieb:
>>
>>> Paolo Carlini wrote:
>>>
>>>> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
>>>> case conservative to have a link type test i
Ralf Wildenhues schrieb:
> * Matthias Klose wrote on Wed, May 06, 2009 at 09:44:07AM CEST:
>> On arm-linux-gnueabi there are regressions of the form
>>
>> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
>> /home/doko/gcc/4.4/gcc-4.
On 26.05.2010 02:44, Mark Mitchell wrote:
In a biweekly call with the other GCC Release Managers, I was asked
today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
particular, the question of whether or not we can use "literate
programming" techniques to extract documentation fro
On 02.06.2010 01:31, Mark Mitchell wrote:
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether or not the GFDL is a "free" license, or whether it's a good
license, or anything else about its merits
On 28.06.2010 23:25, David Daney wrote:
On 06/28/2010 01:11 PM, Brett Neumeier wrote:
The GCC build process uses ecj, which is obtained from sourceware.org
using contrib/download_ecj. The current latest version of ecj, used
for the GCC build, is ecj 4.5.
The previous version of ecj was 4.3, the
On 30.06.2010 23:18, Basile Starynkevitch wrote:
Practical advices welcome.
Cheers.
PS. On Debian, the make-kpkg command has a --rootcmd=sudo option. I am
trying to imagine the equivalent for GCC. Of course on my machine sudo
don't ask any password.
unsure if I understand this correctly, but
On 10.10.2010 22:02, Kalle Olavi Niemitalo wrote:
Basile Starynkevitch writes:
Of course, one can always force ld to be a particular linker (i.e. the
BFD one on a system where the default is GOLD, or vice versa) with ugly
$PATH and symlink tricks. But that is ugly.
You mentioned you use Debi
On 31.10.2010 20:09, Ian Lance Taylor wrote:
Currently we build the Java frontend and libjava by default. At the GCC
Summit we raised the question of whether should turn this off, thus only
building it when java is explicitly selected at configure time with
--enable-languages. Among the people
Mark Mitchell writes:
> and the 3.4.x branch is official dead at this point.
No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html
Matthias
Summary:
GCC 4.1 itself appears to be very stable, both on MIPS and AMD64.
There are, however, a large number of packages using code (especially
C++) which GCC 4.1 treats as errors. Fortunately, most of them are
trivial to fix. By compiling about 6200 packages, over 500 new
bugs have been discov
Martin Michlmayr writes:
> I get the following failure while building gcc 4.2 on hppa:
>
> checking for pid_t... no
> checking for library containing strerror... configure: error: Link tests are
> not allowed after GCC_NO_EXECUTABLES.
> make[3]: *** [configure-target-libiberty] Error 1
> make[3]:
Andrew Pinski writes:
>
> On Jul 28, 2006, at 4:47 AM, Richard Guenther wrote:
>
> >
> > The memory requirement for PR12245 will nearly double.
>
> Saying it will double is not prove, please provide the memory usage
> dumps. If it does double then you should not be using x86 to optimize
> the m
Richard Guenther writes:
> On 9/9/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Kenny Simpson wrote:
> > > What is the status of the 4.1 branch? Any word on 4.1.2?
> >
> > My current plan is to do a 4.1.2 along with 4.2.0. My concern has been
> > that with 4.2.0 moving slowly, trying to organi
Using -flto exposes some new warnings in code, as seen in the both build logs
below, for upstream elfutils and systemd. I have seen others. These upstreams
enable -Werror by default, but probably don't see these warnings turning to
errors themself, because the LTO flags are usually injected by th
Starting with GCC 8, the configury allows to encode extra features into the
architecture string. Debian and Ubuntu's armhf (hard float) architecture is
configured with
--with-arch=armv7-a --with-fpu=vfpv3-d16
and now should be configured with
--with-arch=armv7-a+fp
The --with-fpu configure
On 1/26/22 14:04, jia...@iscas.ac.cn wrote:
> Hi all,
>
> There is an agenda for tomorrow's meeting. If you have topics to
> discuss or share, please let me know and I can add them to the agenda.
>
> Agenda:
>
>
>
>
>
> - Bump GCC default ISA spec and got bug report[1] for that.
Tried to jo
On 1/28/22 11:06, David Abdurachmanov wrote:
> On Thu, Jan 27, 2022 at 6:21 PM Matthias Klose wrote:
>
>> On 1/26/22 14:04, jia...@iscas.ac.cn wrote:
>>> Hi all,
>>>
>>> There is an agenda for tomorrow's meeting. If you have topics to
>>> di
On 1/31/22 15:06, Martin Liška wrote:
> Hello.
>
> It's about 5 months since the last project status update:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577108.html
> Now it's pretty clear that it won't be merged before GCC 12.1 gets released.
>
> So where we are? I contacted document
Am 16.03.2013 04:57, schrieb Jakub Jelinek:> GCC 4.8.0 Release Candidate
available from gcc.gnu.org
>
> The first release candidate for GCC 4.8.0 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.0-RC-20130316
>
> and shortly its mirrors. It has been generated from SVN revision 196699
Am 03.04.2013 17:27, schrieb Simon Baldwin:
> Suppose you had a month in which to reorganise gcc so that it builds
> its 3-stage bootstrap and runtime libraries in some massively parallel
> fashion, without hardware or resource constraints(*). How might you
> approach this?
>
> I'm looking for id
I see all the plugin tests fail when trying to build the tests; this looks a bit
like PR41569, and the tests fail with
make -k -C /gcc check RUNTESTFLAGS="plugin.exp --debug"
In file included from /gcc/testsuite/../../gcc/gcc-plugin.h:28:0,
from /gcc/testsuite/g++.dg/plugin/attribute_plugin
1 - 100 of 125 matches
Mail list logo