On Sat, Feb 10, 2024 at 07:35:22PM +0100, Marc Glisse wrote:
> On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
>
> > So, how does one biulding all parts of gcc with "-O -g"?
> >
> > In my shell script, I have
> >
> > CFLAGS="-O -g"
> > export CFLAGS
> >
> > CXXFLAGS="-O -g"
> > export CXXFLAGS
On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure --prefix=$HOME/work --enable-languages=c,
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure --prefix=$HOME/work --enable-languages=c,c++,fortran \
--enable-bootstrap --disable-libssp
Trying to build default target in 13.1.0 source, and am hitting a
Pthreads are required error.
I have the .h and lib on my system, so not sure why hitting this error.
I goog'd the error and see nothing recent about why I'd get the error.
Any suggestions?
Please include me in response, as I'm n
023, 23:03 Chris Johns, >> <mailto:ch...@contemporary.net.au>> wrote:
>>>
>>> Hi,
>>>
>>> I am sorting out some issues building RTEMS on MacOS including the
>>> M
>>> processors.
>>> Th
sorting out some issues building RTEMS on MacOS including the M
processors.
The building gcc-12.2.1 for the few architectures I tested fail with
sig
faults
in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a
result I
wo
am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with
> sig
> faults
> in xgcc when building the runtime. I tried arm, aarch64 and sparc. As
> a
>
On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, wrote:
>
>
> On Fri, 24 Mar 2023, 23:03 Chris Johns, wrote:
>
>> Hi,
>>
>> I am sorting out some issues building RTEMS on MacOS including the M
>> processors.
>> The building gcc-12.2.1 for the few architectu
On Fri, 24 Mar 2023, 23:03 Chris Johns, wrote:
> Hi,
>
> I am sorting out some issues building RTEMS on MacOS including the M
> processors.
> The building gcc-12.2.1 for the few architectures I tested fail with sig
> faults
> in xgcc when building the runtime. I tried arm,
Hi,
I am sorting out some issues building RTEMS on MacOS including the M processors.
The building gcc-12.2.1 for the few architectures I tested fail with sig faults
in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a result I
wondered about bootstrapping gcc and using that to
In my opinion, the advantage of autotools is that it can generate a
configure script that can be shipped with the source tarball, then any
one with the source can run the configure script when the system has a
POSIX shell and tools. If using CMake, meson, xmake, etc. the user will
first need to
> On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote:
>
>> Hi,
>>
>> I want to get the opinions of GCC developers regarding adding CMake as a
>> build system for GCC. Is it something you would like, something you are
>> neutral about, or something you are strongly against?
>>
>> Thanks for you
On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote:
> Hi,
>
> I want to get the opinions of GCC developers regarding adding CMake as a
> build system for GCC. Is it something you would like, something you are
> neutral about, or something you are strongly against?
>
> Thanks for your valuable f
在 2022-09-11 22:29, Junk Trash via Gcc 写道:
Hi,
I want to get the opinions of GCC developers regarding adding CMake as a build
system for GCC. Is it something you would like, something you are neutral
about, or something you are strongly against?
Thanks for your valuable feedback!
https://
Hi,
I want to get the opinions of GCC developers regarding adding CMake as a build
system for GCC. Is it something you would like, something you are neutral
about, or something you are strongly against?
Thanks for your valuable feedback!
Regards,
JT
-languages=default,lto
> to achieve the same effect without getting the mpfr side-effect.
Oh that is great and I had no idea this is how it is controlled. I have rebuilt
my compiler and it is now building. Nice.
>> I have assumed the enable option for LTO is for the cross compiler and
e cross compiler and not the
> host gcc?
it's for the built GCC, enabling LTO support (but not for enabling
building GCC itself
with LTO).
Richard.
>
> Thanks
> Chris
Hi,
I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
chip vendor is using it when building controller software that is part of a
system.
The build I am using symlinks gmp, mpfr etc as source so they are built as part
of the gcc build.
The mpfr package is reporting ..
Adrian Glaubitz wrote:
Hi!
I'm currently building GCC from git on various Debian targets to help
with the
gccrs development effort a bit. On 32-bit PowerPC, I have run into a
problem
which seems to be related to Multi-Arch (see below).
I have already the patch gcc-multiarch.diff that Debi
I believe that was recently fixed on trunk by
fb6b24c66ea5a2ccbf6fb9f299c20a69f962ac9b
On 6/3/21 4:59 AM, John Paul Adrian Glaubitz wrote:
Hi!
I'm currently building GCC from git on various Debian targets to help with the
gccrs development effort a bit. On 32-bit PowerPC, I have run i
Hi!
I'm currently building GCC from git on various Debian targets to help with the
gccrs development effort a bit. On 32-bit PowerPC, I have run into a problem
which seems to be related to Multi-Arch (see below).
I have already the patch gcc-multiarch.diff that Debian is shipping and pa
On 1/17/21 4:08 PM, H.J. Lu wrote:
On Sun, Jan 17, 2021 at 1:06 PM Tom Honermann via Gcc wrote:
Hi all. I've been trying to build a custom gcc (trunk) with a custom
glibc (trunk) with support for C and C++ on x86_64 Linux and have so far
been unsuccessful at identifying a sequence of configure
On Sun, Jan 17, 2021 at 1:06 PM Tom Honermann via Gcc wrote:
>
> Hi all. I've been trying to build a custom gcc (trunk) with a custom
> glibc (trunk) with support for C and C++ on x86_64 Linux and have so far
> been unsuccessful at identifying a sequence of configure/make
> invocations that compl
Hi all. I've been trying to build a custom gcc (trunk) with a custom
glibc (trunk) with support for C and C++ on x86_64 Linux and have so far
been unsuccessful at identifying a sequence of configure/make
invocations that completes successfully. I'm not trying to build a
cross compiler.
The
PS p5600 machine
> > under Debian Stretch. I'm getting an illegal instruction during libstdc++
> > build phase:
>
> This mailing list is for discussion of GCC development, not help using
> or building GCC. Your mail would be appropriate on the gcc-help list,
> which I&#
l instruction during libstdc++
> build phase:
This mailing list is for discussion of GCC development, not help using
or building GCC. Your mail would be appropriate on the gcc-help list,
which I've CC'd. Please remove gcc@ from further replies and use the
gcc-help@ list.
> libtool: c
Hello,
I'm trying to build gcc-7.3.0 (md5 747d5010b7c6938b480bc6e4d7c4be9a of
tar.gz) natively on a MACHTYPE=mipsel-unknown-linux-gnu MIPS p5600 machine
under Debian Stretch. I'm getting an illegal instruction during libstdc++
build phase:
libtool: compile: /home/gru/proj/gcc_build/./gcc/xgcc -s
On Mon, Sep 25, 2017 at 11:17 AM, nick wrote:
>
>
> On 2017-09-24 10:10 AM, Eric Gallager wrote:
>> On Sat, Sep 23, 2017 at 12:34 PM, nick wrote:
>>> If your able to just tell me where the functions are located or how do you
>>> enable ctags for all of
>>> gcc? That would just save me asking stu
On 09/23/2017 04:57 PM, Eric Gallager wrote:
> On Sat, Sep 23, 2017 at 12:34 PM, nick wrote:
>>
>>
>> On 2017-09-23 12:05 PM, Jeff Law wrote:
>>> On 09/22/2017 08:25 PM, nick wrote:
Greetings All,
I am wondering if this is a warning worth looking into or is it just
another fal
On 2017-09-24 10:10 AM, Eric Gallager wrote:
> On Sat, Sep 23, 2017 at 12:34 PM, nick wrote:
>> If your able to just tell me where the functions are located or how do you
>> enable ctags for all of
>> gcc? That would just save me asking stupid questions. Is there a global
>> setting like make
On Sat, Sep 23, 2017 at 12:34 PM, nick wrote:
> If your able to just tell me where the functions are located or how do you
> enable ctags for all of
> gcc? That would just save me asking stupid questions. Is there a global
> setting like make ctags for
> doing this or you I have to do it manuall
On Sat, Sep 23, 2017 at 12:34 PM, nick wrote:
>
>
> On 2017-09-23 12:05 PM, Jeff Law wrote:
>> On 09/22/2017 08:25 PM, nick wrote:
>>> Greetings All,
>>>
>>> I am wondering if this is a warning worth looking into or is it just
>>> another false postive:
>>>
>>> /home/nick/gcc/gcc/combine.c:1316:8
On 2017-09-23 12:05 PM, Jeff Law wrote:
> On 09/22/2017 08:25 PM, nick wrote:
>> Greetings All,
>>
>> I am wondering if this is a warning worth looking into or is it just another
>> false postive:
>>
>> /home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used
>> uninitialized in this fu
On 09/22/2017 08:25 PM, nick wrote:
> Greetings All,
>
> I am wondering if this is a warning worth looking into or is it just another
> false postive:
>
> /home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> if ((ne
e (insn, prev, nextlinks->insn,
NULL, &new_direct_jump_p,
last_combined_insn)) != 0)
goto retry;
}
Maybe it's just me being new here. Further more, was wondering if ctags support
is there. I assume it&#
On 15 July 2016 at 00:45, Patrick Oppenlander wrote:
> Hi,
>
> I'm running into a build problem when building GCC 6.1.0:
>
>
> /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc/xgcc
> -shared-libgcc -B/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./g
Hi,
I'm running into a build problem when building GCC 6.1.0:
/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc/xgcc
-shared-libgcc
-B/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc
-nostdinc++
-L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-ea
Hi,
> -Original Message-
> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> Sent: Tuesday, April 12, 2016 3:09 PM
> To: Kumar, Venkataramanan
> Cc: gcc Development ; Sebastian Pop
>
> Subject: Re: Building gcc with graphite
>
> [ cc-ing gcc ml ]
&g
[ cc-ing gcc ml ]
On 12/04/16 11:22, Kumar, Venkataramanan wrote:
Hi,
I am trying to build gcc with graphite enabled both on trunk and the
graphite branch.
I don't know anything about the graphite branch.
Should I need to build and install cloog , ISL PPL etc?
Trunk needs ISL.
Is ther
Martin> The one that's more difficult is 18881 where the debugger cannot
Martin> resolve calls to functions overloaded on the constness of the
Martin> argument. Do you happen to have a trick for dealing with that
Martin> one?
Nothing really convenient to use. Sometimes you can get it to do the
r
On 12/04/2015 10:32 AM, Tom Tromey wrote:
"Martin" == Martin Sebor writes:
Martin> To get around these, I end up using info macro to print the
Martin> macro definition and using whatever it expands to instead. I
Martin> wonder if someone has found a more convenient workaround.
For some of th
> "Martin" == Martin Sebor writes:
Martin> To get around these, I end up using info macro to print the
Martin> macro definition and using whatever it expands to instead. I
Martin> wonder if someone has found a more convenient workaround.
For some of these, like the __builtin_offsetof and __
On 3 December 2015 at 16:01, Martin Sebor wrote:
> On 12/02/2015 06:48 PM, Peter Bergner wrote:
>>
>> On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote:
>>>
>>> Is there any way to easily build a stage1 gcc with macro support for
>>> debugging?
>>>
>>> I tried setting CFLAGS, and CXXFLAGS to speci
On 12/02/2015 06:48 PM, Peter Bergner wrote:
On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote:
Is there any way to easily build a stage1 gcc with macro support for debugging?
I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the
command line before running configure, but that only
Ryan Burn writes:
> Is there any way to easily build a stage1 gcc with macro support for
> debugging?
Set STAGE1_CFLAGS.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote:
> Is there any way to easily build a stage1 gcc with macro support for
> debugging?
>
> I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the
> command line before running configure, but that only includes those
> flags for some of t
Is there any way to easily build a stage1 gcc with macro support for debugging?
I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the
command line before running configure, but that only includes those
flags for some of the compilation steps.
I was only successful after I manually edi
er05/gcc-pass1.html)
>
> But this is not the right list for help using or building gcc, please
> follow up in the gcc-h...@gcc.gnu.org list instead, thanks.
a C library
to be already installed (as explained in the GCC Pass 1 section of
http://www.linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html)
But this is not the right list for help using or building gcc, please
follow up in the gcc-h...@gcc.gnu.org list instead, thanks.
I am trying to build a GCC (version 4.9.3)cross compiler on my windows
machine using Cygwin. I am using the source package that came along
with cygwin.
I have already built binutils version 2.25 and installed, this is
through cygwin as well.
binutils configuration used:
../binutils-x.y.z/configu
=/work/llvm/install-release/bin/clang++
And the bootstrap was successful. One useful thing I got to see was clang
warnings. Clang produced several warnings (> 1000 unique ones). I have attached
two files with this email.
I also recently interested in building GCC by LLVM. Although I
On 20 September 2014 00:52, Ian Grant wrote:
> None of this is useful to me. I'm trying to make a case for why people
> should have confidence in GNU software. You are NOT helping me in
> that, I assure you,
You seem to have already made up your mind it's GNU crap.
Being insulting is a funny way
On Sat, Sep 20, 2014 at 08:33:01AM +0100, Andrew Haley wrote:
> On 20/09/14 02:45, Ian Grant wrote:
>
> > You get first prize for most informative intelligent answer so far!
> > Careful, you might get second prize too :-)
> >
> > The problem is that we need to find a way to tell people _what_ is
On 20/09/14 02:45, Ian Grant wrote:
> You get first prize for most informative intelligent answer so far!
> Careful, you might get second prize too :-)
>
> The problem is that we need to find a way to tell people _what_ is in
> that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and
>
Thanks Andrew!
You get first prize for most informative intelligent answer so far!
Careful, you might get second prize too :-)
The problem is that we need to find a way to tell people _what_ is in
that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and
goes about its business. That's
On Fri, Sep 19, 2014 at 4:52 PM, Ian Grant wrote:
> None of this is useful to me. I'm trying to make a case for why people
> should have confidence in GNU software. You are NOT helping me in
> that, I assure you,
Again, try stripping out debugging information and look at the numbers
again. Or be
None of this is useful to me. I'm trying to make a case for why people
should have confidence in GNU software. You are NOT helping me in
that, I assure you,
We need to publish some simple steps that people can take to reassure
themselves that the 64MB binaries that GCC 4.9 produces on Linux
system
On 20 September 2014 00:01, Jonathan Wakely wrote:
> On 19 September 2014 16:21, Ian Grant wrote:
>> Thanks. But I asked what the non-vanilla sources were. I know what
>> the vanilla sources are, because I'm using them!
>
> The non-vanilla sources are everything else. That should be pretty obvious
On 19 September 2014 16:21, Ian Grant wrote:
> Thanks. But I asked what the non-vanilla sources were. I know what
> the vanilla sources are, because I'm using them!
The non-vanilla sources are everything else. That should be pretty obvious.
Are you just intentionally trying to waste everyone's t
On Thu, Sep 18, 2014 at 10:35 PM, Thomas Preud'homme
wrote:
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Ian Grant
>>
>> And can anyone tell me what are the 'non-vanilla' sources?
>
> "Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org
> for
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ian Grant
>
> And can anyone tell me what are the 'non-vanilla' sources?
"Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org for
the case of gcc). This is in contrast to modified source from distr
On Thu, Sep 18, 2014 at 9:37 PM, Joe Buck wrote:
> (delurking)
> Ah, this is commonly called the Thompson hack, since Ken Thompson
> actually produced a successful demo:
How do you know Thompson's attempt was the first instance? The
document I refer to in the blog is the "Unknown Air Force Repor
(delurking)
Ian Grant writes:
> In case it isn't obvious, what I am interested in is how easily we can know
> the problem of infeasibly large binaries isn't an instance of this one:
>
> http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html
Ah, this is commonly calle
In case it isn't obvious, what I am interested in is how easily we can
know the problem of infeasibly large binaries isn't an instance of
this one:
http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html
Ian
On Thu, Sep 18, 2014 at 8:32 PM, Jonathan Wakely wrote:
>> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>>text databssdechexfilename
>> 14965183 23708 74494415733835 f0144b
>> i686-pc-linux-gnu/4.9.0/cc1
>> 15882830
On 19 September 2014 00:07, Ian Grant wrote:
>
> Actually, when I look at the output of size I realise I don't know
> what it means:
>
> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>text databssdechexfilename
> 14965183 23708
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> Have you compared the binaries using size(1) instead of ls(1)?
Actually, when I look at the output of size I realise I don't know
what
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
I can compile the first stage OK, and the binaries are quite modest:
>
On 18 September 2014 23:46, Ian Grant wrote:
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>>> I can compile the first stage OK, and the binaries are quite modest:
>>>
>>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> I can compile the first stage OK, and the binaries are quite modest:
>>
>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
>> -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev
On Thu, Sep 18, 2014 at 5:37 PM, Ian Grant wrote:
>
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> > The reason I'm doing this is that I want to understand why the total
>> > size of the binaries grew from around 10MB (gc
On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
> The reason I'm doing this is that I want to understand why the total
> size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
> 4.9
>
> I can compile the first stage OK, and the binaries are quite modest:
>
> -rwxr-xr-x
On Wed, Sep 17, 2014 at 2:59 PM, Marc Glisse wrote:
>>> Please don't call it "the Intel library", that doesn't mean anything.
>> Doesn't it? How did you know what 'it' was then? Or is that a stupid
>> question? This identity concept is much slipperier than it seems at
>> first, isn't it?
> You in
On Wed, 17 Sep 2014, Ian Grant wrote:
On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote:
On Wed, 17 Sep 2014, Ian Grant wrote:
And is there any way to disable the Intel library?
--disable-libcilkrts (same as the other libs)
If it explicitly doesn't support your system, I am a bit surpris
On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote:
> On Wed, 17 Sep 2014, Ian Grant wrote:
>
>> And is there any way to disable the Intel library?
> --disable-libcilkrts (same as the other libs)
> If it explicitly doesn't support your system, I am a bit surprised it isn't
> disabled automaticall
On Wed, 17 Sep 2014, Ian Grant wrote:
And is there any way to disable the Intel library?
--disable-libcilkrts (same as the other libs)
If it explicitly doesn't support your system, I am a bit surprised it
isn't disabled automatically, that seems like a bug.
Please don't call it "the Intel l
The reason I'm doing this is that I want to understand why the total
size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
4.9
I can compile the first stage OK, and the binaries are quite modest:
-rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
-rwxr-xr-x 1 ian ian 1.2
The reason I'm doing this is that I want to understand why the total
size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
4.9
I can compile the first stage OK, and the binaries are quite modest:
-rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
-rwxr-xr-x 1 ian ian 1.2
** [linking.lo] Error 127
make[1]: *** [all-target-libobjc] Error 2
make: *** [all] Error 2
--->8->8----->8-----
Note: the "Checking multilib configuration for libobjc..."
The strange thing here is that the line above the failed one builds fine, but
suddenly ./libtool is not found (?!??)
My question is: What's the correct / intended way of building GCC with ObjC
support ?
Love
Jens
On 20 February 2014 18:16, Patrick Palka wrote:
> On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely
> wrote:
>> On 20 February 2014 15:31, Patrick Palka wrote:
>>> (I counted nearly 100 (non-debug)
>>> functions that could be made static in gcc, and 4 in libstdc++, by the
>>> way.)
>>
>> Which wer
On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely wrote:
> On 20 February 2014 15:31, Patrick Palka wrote:
>> (I counted nearly 100 (non-debug)
>> functions that could be made static in gcc, and 4 in libstdc++, by the
>> way.)
>
> Which were the four in libstdc++?
>
> I only see __gslice_on_index a
On 20 February 2014 15:31, Patrick Palka wrote:
> (I counted nearly 100 (non-debug)
> functions that could be made static in gcc, and 4 in libstdc++, by the
> way.)
Which were the four in libstdc++?
I only see __gslice_on_index and __concat_size_t.
Patrick Palka writes:
>> Maybe others will disagree and will think enabling
>> -Wmissing-declarations would be a useful change, but I don't see the
>> point.
>
> In my novice opinion, I think the flag helps keep source files tidy
> and modular, and their interfaces well-defined. Its biggest benef
On Thu, Feb 20, 2014 at 7:42 AM, Jonathan Wakely wrote:
> On 20 February 2014 10:02, Patrick Palka wrote:
>> On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely
>> wrote:
>>> On 13 February 2014 20:47, Patrick Palka wrote:
On a related note, would a patch to officially enable
-Wmissing-d
On 20 February 2014 10:02, Patrick Palka wrote:
> On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely
> wrote:
>> On 13 February 2014 20:47, Patrick Palka wrote:
>>> On a related note, would a patch to officially enable
>>> -Wmissing-declarations in the build process be well regarded?
>>
>> What wo
On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely wrote:
> On 13 February 2014 20:47, Patrick Palka wrote:
>> On a related note, would a patch to officially enable
>> -Wmissing-declarations in the build process be well regarded?
>
> What would be the advantage?
A missing declaration for an extern
On 13 February 2014 20:47, Patrick Palka wrote:
> On a related note, would a patch to officially enable
> -Wmissing-declarations in the build process be well regarded?
What would be the advantage?
> Since
> -Wmissing-prototypes is currently enabled, I assume it is the
> intention of the GCC devs
Hi everyone,
I noticed that the GCC build process currently only uses the
-Wmissing-prototypes flag, and not the -Wmissing-declarations flag.
It seems that the former flag only works on C source files, which
means that GCC's source files no longer benefit from this flag as they
are now C++ files.
On Fri, 2013-11-22 at 13:48 -0800, H.J. Lu wrote:
> On Fri, Nov 22, 2013 at 1:24 PM, Steve Ellcey wrote:
> >
> > I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
> > want to build the compiler as a 32 bit executable. I thought the right way
> > to do this was to do:
> >
> I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
> want to build the compiler as a 32 bit executable. I thought the right way
> to do this was to do:
>
> export CFLAGS='-O2 -g -m32'
> export CXXFLAGS-'-O2 -g -m32'
>
> before running configure and make.
>
> This is wo
On Fri, Nov 22, 2013 at 1:24 PM, Steve Ellcey wrote:
>
> I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
> want to build the compiler as a 32 bit executable. I thought the right way
> to do this was to do:
>
> export CFLAGS='-O2 -g -m32'
> export CXXFLAGS-'-O2 -g -m32'
I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
want to build the compiler as a 32 bit executable. I thought the right way
to do this was to do:
export CFLAGS='-O2 -g -m32'
export CXXFLAGS-'-O2 -g -m32'
before running configure and make.
This is working in that it cr
Richard Biener wrote:
On Tue, Jan 15, 2013 at 6:46 AM, Uday P. Khedker wrote:
GCC has been building stages 2 and 3 in C++ mode for a while.
The C++ compiler is created anyway since 4.7 and is used to build
stage2+. Starting with GCC 4.8 stage1 requires a C++ host compiler.
In GCC 4.7 you c
On Tue, Jan 15, 2013 at 6:46 AM, Uday P. Khedker wrote:
> I was trying to understand the exact meaning of a loose statement
> floating around ("gcc has moved to C++ from version 4.7 onwards).
>
> I reckon from http://gcc.gnu.org/wiki/gcc-in-cxx that now gcc is
> compiled using C++. However, the ve
On Tue, Jan 15, 2013 at 11:36:53AM +0530, Uday P. Khedker wrote:
>
>
> Basile Starynkevitch wrote, On Tuesday 15 January 2013 11:34 AM:
> >My belief is that it is no more possible to configure a recent GCC straight
> >(non-cross) compiler without --enable-language=c++
> >(that is, if you ask only
Basile Starynkevitch wrote, On Tuesday 15 January 2013 11:34 AM:
On Tue, Jan 15, 2013 at 11:16:54AM +0530, Uday P. Khedker wrote:
I was trying to understand the exact meaning of a loose statement
floating around ("gcc has moved to C++ from version 4.7 onwards).
I reckon from http://gcc.gnu.or
On Tue, Jan 15, 2013 at 11:16:54AM +0530, Uday P. Khedker wrote:
> I was trying to understand the exact meaning of a loose statement
> floating around ("gcc has moved to C++ from version 4.7 onwards).
>
> I reckon from http://gcc.gnu.org/wiki/gcc-in-cxx that now gcc is
> compiled using C++. Howeve
I was trying to understand the exact meaning of a loose statement
floating around ("gcc has moved to C++ from version 4.7 onwards).
I reckon from http://gcc.gnu.org/wiki/gcc-in-cxx that now gcc is
compiled using C++. However, the very first line of the description
confused me. It says:
GCC has
for
>>>>> handling whacky windows printfs, and we were doing very well for a
>>>>> long time. Currently, however, there are two instances where giant
>>>>> massive piles of warnings spit out due to enums not being handled in a
>>>>> switc
or a
>>>> long time. Currently, however, there are two instances where giant
>>>> massive piles of warnings spit out due to enums not being handled in a
>>>> switch. Is this a warning that we could just disable by default for
>>>> building gcc? My bu
1 - 100 of 256 matches
Mail list logo
