Am 11.10.2024 um 18:07 schrieb Jonathan Wakely:
The c99 executable is provided by your distro, it's not part of GCC.
Maybe it wants a space between the -O and 2, but I don't know.
thanks for clearing that up
does not work with spaces - will ask on the Tumbleweed list
On Fri, 11 Oct 2024 at 17:02, Dennis Luehring via Gcc
wrote:
> latest SUSE Tumbleweed/gcc 14.2
>
> c99 -O2 test.c
>
> returns:
> c99: invalid option -- '2'
>
> cc -O2 test.c
>
> returns successfull
>
>
> according to https://linux.die.net/man/1/c
latest SUSE Tumbleweed/gcc 14.2
c99 -O2 test.c
returns:
c99: invalid option -- '2'
cc -O2 test.c
returns successfull
according to https://linux.die.net/man/1/c99 the -O2 option should work
c99 is used in an older build system and that didn't work due to the -O2
problem
On Wed, May 11, 2022 at 1:46 AM RICHU NORMAN wrote:
>
> Hi,
> I am new in gcc development and I am focusing on cross-compilers.I have
> added a few instructions for the target machine in binutils and invoked it
> using asm() from c program.Now I want to add those instructions to gcc and
> define t
Hi,
I am new in gcc development and I am focusing on cross-compilers.I have
added a few instructions for the target machine in binutils and invoked it
using asm() from c program.Now I want to add those instructions to gcc and
define that instruction in target.md file.I have a few queries regarding
On 1/18/22 20:10, Harald Anlauf via Fortran wrote:
Am 17.01.22 um 22:26 schrieb Martin Liška:
On 1/12/22 16:54, Martin Liška wrote:
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
The patc
Am 17.01.22 um 22:26 schrieb Martin Liška:
On 1/12/22 16:54, Martin Liška wrote:
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
The patch has been installed as I've made the re
On 1/18/22 14:10, Richard Earnshaw wrote:
Is that worth adding to contrib/gcc-git-customization.sh ?
Yes, can you please do that?
Thanks,
Martin
On 17/01/2022 21:41, Martin Liška wrote:
On 1/13/22 12:01, Martin Liška wrote:
Hello.
Based on the discussion with release managers, the change is going to
happen
after stage4 begins.
Martin
Hi.
The renaming patches have been just installed and I've built a few
target compilers so far
LGTM.
I've just installed that, the Ada testsuite should work now.
Martin
> anticipated.
>
> Yeah, I thought that building Ada FE is enough for testing effort, sorry.
>
> I would like to install the following 2 patches that revert the changes.
> After the change we're going to have:
>
> marxin@marxinbox:~/Programming/gcc/gcc/ada> f
to install the following 2 patches that revert the changes.
After the change we're going to have:
marxin@marxinbox:~/Programming/gcc/gcc/ada> find . -name '*.cc'
./gcc-interface/targtyps.cc
./gcc-interface/decl.cc
./gcc-interface/cuintp.cc
./gcc-interface/trans.cc
./gcc-inter
On Tue, Jan 18, 2022 at 9:46 AM Eric Botcazou via Gcc-patches
wrote:
>
> > Release managers.
>
> They certainly have authority on the timing, but not on the contents.
Technically all release managers are also global reviewers, but I
agree the speciality
of the Ada setup (esp. the runtime being in
> Release managers.
They certainly have authority on the timing, but not on the contents.
> Working on that right now, sorry..
OK, thanks in advance.
--
Eric Botcazou
On 1/18/22 09:36, Eric Botcazou wrote:
Martin,
The renaming patches have been just installed and I've built a few target
compilers so far. I'll be online in ~10 hours from now so I can address
potential issues caused by the patch.
Who approved it though?
Release managers.
The renaming of
Martin,
> The renaming patches have been just installed and I've built a few target
> compilers so far. I'll be online in ~10 hours from now so I can address
> potential issues caused by the patch.
Who approved it though? The renaming of the C files in the ada/ directory is
wrong and should be
On 1/13/22 12:01, Martin Liška wrote:
Hello.
Based on the discussion with release managers, the change is going to happen
after stage4 begins.
Martin
Hi.
The renaming patches have been just installed and I've built a few target
compilers so far.
I'll be online in ~10 hours from now so I can
On 1/12/22 16:54, Martin Liška wrote:
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
The patch has been installed as I've made the renaming now.
Cheers,
Martin
On 1/14/22 08:44, Bernhard Reutner-Fischer wrote:
On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška wrote:
+def replace_file_in_changelog(lines, filename):
+if not filename.endswith('.cc'):
+return
+
+# consider all componenets of a path: gcc/ipa-icf.cc
+whil
On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška wrote:
> +def replace_file_in_changelog(lines, filename):
> +if not filename.endswith('.cc'):
> +return
> +
> +# consider all componenets of a path: gcc/ipa-icf.cc
> +while filename:
> +
Hello.
Based on the discussion with release managers, the change is going to happen
after stage4 begins.
Martin
Hi.
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
Example usage:
$ git show test
commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604 (test)
Author: Martin Liska
Date: Wed Jan 12 16:08:13
would need that as well?
From the directories that use .c files for C++, I think that is all.
c++tools/, libcody/, libitm/, libsanitizer/, libstdc++-v3/ already
use .cc or .cpp.
All right, I've included libcpp folder in the renaming effort.
Please take a look at V2 of the series here:
On Tue, Jan 11, 2022 at 06:23:51PM +, Jonathan Wakely via Gcc-patches wrote:
> > Regarding fortran: can we have a vote on this one?
> >
> > Some developers (including myself) are not really familiar with C++,
> > and in the past preference has been expressed on the fortran ML in
> > favor of no
On Tue, 11 Jan 2022 at 18:02, Harald Anlauf via Gcc wrote:
>
> Am 11.01.22 um 16:50 schrieb Martin Liška:
> > On 1/11/22 16:48, Toon Moene wrote:
> >> On 1/11/22 13:56, Martin Liška wrote:
> >>
> >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>> Plus it survives buil
Am 11.01.22 um 16:50 schrieb Martin Liška:
On 1/11/22 16:48, Toon Moene wrote:
On 1/11/22 13:56, Martin Liška wrote:
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Plus it survives build of all FEs (--enable-languages=all) on
x86_64-linux-gnu
and I've built all cross co
s well?
>From the directories that use .c files for C++, I think that is all.
c++tools/, libcody/, libitm/, libsanitizer/, libstdc++-v3/ already
use .cc or .cpp.
Jakub
On 1/11/22 16:56, Jakub Jelinek wrote:
While e.g. libcpp or gcc are in C++.
Which means I should rename .c files under libcpp, right?
Is there any other folder from gcc/ and libcpp/ that would need that as well?
Martin
On Tue, Jan 11, 2022 at 04:50:02PM +0100, Martin Liška wrote:
> On 1/11/22 16:48, Toon Moene wrote:
> > On 1/11/22 13:56, Martin Liška wrote:
> >
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > Plus it survives build of all FEs (--enable-languages=all) on
> > >
On 1/11/22 16:48, Toon Moene wrote:
On 1/11/22 13:56, Martin Liška wrote:
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu
and I've built all cross compilers.
Does this also rename .c files in
On 1/11/22 13:56, Martin Liška wrote:
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Plus it survives build of all FEs (--enable-languages=all) on
x86_64-linux-gnu
and I've built all cross compilers.
Does this also rename .c files in the fortran and libgfortran direct
old_filename}\b
with ${old_filename}c
(with some exceptions). That corresponds to patch #1 and #2 and the patches are
quite huge.
The last piece are manual changes needed for Makefile.in, configure.ac and so
on.
The git branch can be seen here:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;
On Fri, Jan 07, 2022 at 03:33:54PM -0300, Alexandre Oliva via Gcc wrote:
> On Jan 7, 2022, Martin Jambor wrote:
>
> > Would anyone be terribly against mass renaming all *.c files (that are
> > actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
&
On Jan 7, 2022, Martin Jambor wrote:
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
I wouldn't mind that.
> (Any important caveats I might have missed?)
Having recently renamed
On Fri, 7 Jan 2022 at 16:00, David Malcolm wrote:
> Presumably the generated files should also change from .c to .cc (e.g.
> gengtype generates a gtype-desc.c which is actually C++).
We could do that separately (and right away), couldn't we? That could
even have been done back in the
On Fri, 2022-01-07 at 11:25 +0100, Martin Jambor wrote:
> Hi,
>
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc
> suffix?
>
> We already have 47 files with suffix .cc directly in t
On 1/7/2022 7:49 AM, Jeff Law wrote:
On 1/7/2022 3:25 AM, Martin Jambor wrote:
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
On 1/7/2022 3:25 AM, Martin Jambor wrote:
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
subdirectory and 160 if we also count
> On 7 Jan 2022, at 12:55, Martin Liška wrote:
>
> On 1/7/22 12:05, Jonathan Wakely via Gcc wrote:
>> References to .cc files in the commit message won't get changed to .c
>> automatically, but maybe the gcc-backport alias could be taught to do
>> that.
> +
On 1/7/22 12:05, Jonathan Wakely via Gcc wrote:
References to .cc files in the commit message won't get changed to .c
automatically, but maybe the gcc-backport alias could be taught to do
that.
Hi.
+1 for me. I'm willing to extend gcc-backport script to support renaming
files in
On Fri, 7 Jan 2022 at 10:54, Jakub Jelinek via Gcc wrote:
> My big worry would be backporting for the next 2 years.
> Do we need to adjust commit messages when backporting to replace *.cc with
> *.c in there? Does git cherry-pick handle the changed files or do we
> need to resol
On Fri, Jan 07, 2022 at 11:25:50AM +0100, Martin Jambor wrote:
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
> We already have 47 files with suffix .cc directly in the gcc
> s
On Fri, 7 Jan 2022 at 10:26, Martin Jambor wrote:
> I have already missed stuff when grepping because I did not include *.cc
> files and the inconsistency is also just ugly and must be very confusing
> to anyone who encounters it for the first time.
Yes, and it affects tooling li
On Fri, Jan 7, 2022 at 2:35 AM Richard Sandiford via Gcc
wrote:
>
> Martin Jambor writes:
> > Hi,
> >
> > Would anyone be terribly against mass renaming all *.c files (that are
> > actually C++ files) within the gcc subdirectory to ones with .cc suffix?
> &g
Martin Jambor writes:
> Hi,
>
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and 160 if we als
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
subdirectory and 160 if we also count those in (non-testsuite)
subdirectories, while
On Fri, Jun 01, 2018 at 02:49:51PM -0400, Paul Koning wrote:
> Given that the starting insn had a post_inc in it, what would be a proper
> parallel... construct? If the post_inc only appears in one of the two
> mentions of the source operatnd, then the match_dup is going to fail. I
> suppose I c
88r.dse dump file, looks like
>> this:
>
> I'd say it is upset by multiple post_inc in the same instruction, that is I
> believe invalid.
>
>> (insn 195 194 197 11 (parallel [
>>(set (reg:CC 16 cc)
>>(compare:CC (mem:QI (post_inc:
at is I
believe invalid.
> (insn 195 194 197 11 (parallel [
> (set (reg:CC 16 cc)
> (compare:CC (mem:QI (post_inc:HI (reg/v/f:HI 0 r0 [orig:41 p
> ] [41])) [0 MEM[base: p_38, offset: 65535B]+0 S1 A8])
> (const_int 0 [
Gentlepeople,
I'm using Eric Botcazou's recipe #2 for the CCmode version of pdp11 -- where
most instructions step on the condition codes so the CC references are inserted
post-reload. As part of that, the compare-elim pass gets rid of compares that
are redundant given that the i
On Fri, 2016-10-21 at 17:03 +0100, Jonathan Wakely wrote:
>
> > Is there some C++ standard change that I am not aware of or some
> > other header file I need to include?
> No, what probably happened is GCC didn't detect a usable Pthreads
> implementation and so doesn't define std::thread. The hea
On 19 October 2016 at 18:45, Ellcey, Steve wrote:
> I have built the latest glibc sources with a ToT GCC and am trying to run the
> glibc testsuite now. I ran into a couple of
> new warnings that I fixed (locally) and am now looking at
> nptl/tst-thread_local1.cc which dies w
On Wed, Oct 19, 2016 at 10:45 AM, Ellcey, Steve wrote:
> I have built the latest glibc sources with a ToT GCC and am trying to run the
> glibc testsuite now. I ran into a couple of
> new warnings that I fixed (locally) and am now looking at
> nptl/tst-thread_local1.cc which dies w
I have built the latest glibc sources with a ToT GCC and am trying to run the
glibc testsuite now. I ran into a couple of
new warnings that I fixed (locally) and am now looking at
nptl/tst-thread_local1.cc which dies with:
tst-thread_local1.cc:172:7: error: ‘thread’ is not a member of ‘std
On 2/1/2016 12:40 PM, Richard Henderson wrote:
On 02/02/2016 01:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering
On 2/1/2016 6:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catches this case as well.
This
On 02/02/2016 01:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catches this case as well
David Wohlferd wrote:
> On 1/26/2016 4:31 PM, Bernd Schmidt wrote:
> > On 01/27/2016 12:12 AM, David Wohlferd wrote:
> >> I started by just commenting out the code in ix86_md_asm_adjust that
> >> unconditionally clobbered the flags. I figured this would allow the
>
On 1/26/2016 4:31 PM, Bernd Schmidt wrote:
On 01/27/2016 12:12 AM, David Wohlferd wrote:
I started by just commenting out the code in ix86_md_asm_adjust that
unconditionally clobbered the flags. I figured this would allow the
'normal' "cc" handling to occur. But apparently
On 01/27/2016 12:12 AM, David Wohlferd wrote:
I started by just commenting out the code in ix86_md_asm_adjust that
unconditionally clobbered the flags. I figured this would allow the
'normal' "cc" handling to occur. But apparently there is no 'normal'
"cc&qu
It is well known that on i386, the "cc" clobber is always set for
extended asm, whether it is specified or not. I was wondering how much
difference it might make if the generated code actually followed what
the user specified (expectation: not much). But implementing this
t
On Mon, Oct 26, 2015 at 8:47 PM, Yasser Shalabi wrote:
> So back to square one. Any tips on what code/config-files I need to
> modify with to get GCC to emit additional opcodes for certain
> instructions?
Maybe you should try cross-compiling. It looks like you have already
succeeded with the inst
So I tried Dyninst but it is not as clean as I need. I am afraid I
will need to implement this in the compiler. I have already
implemented it as a backend pass for another compiler, but
unfortunately it doesnt compile the linux kernel :P
So back to square one. Any tips on what code/config-files I
On 10/23/2015 11:37 AM, Yasser Shalabi wrote:
> Hey Will,
>
> Thanks for the quick reply. Yeah I need the int3 instruction to be
> statically included in he binary so I can't use any dynamic
> instrumentation tool.
Dyninst can do binary rewrites of executables so that might still be suitable.
ht
Hey Will,
Thanks for the quick reply. Yeah I need the int3 instruction to be
statically included in he binary so I can't use any dynamic
instrumentation tool.
On Fri, Oct 23, 2015 at 10:32 AM, William Cohen wrote:
> On 10/23/2015 01:37 AM, Yasser Shalabi wrote:
>> Hello,
>>
>> I am new to the GC
On 10/23/2015 01:37 AM, Yasser Shalabi wrote:
> Hello,
>
> I am new to the GCC code. I want to make a simple modification to the
> back end. I want to add a debug exception (int3) to be generated
> before any instance of certain x86 instructions.
>
> I tried to modify gcc/config/i386/i386.md by a
Hello,
I am new to the GCC code. I want to make a simple modification to the
back end. I want to add a debug exception (int3) to be generated
before any instance of certain x86 instructions.
I tried to modify gcc/config/i386/i386.md by adding a "int3" to the
define_insn for instructions of intere
On 1 September 2015 at 10:12, Sebastian Huber wrote:
> Hello,
>
> in this test case there are two bool test variables (global and local). Is
> this intentional?
You're much more likely to get an answer if you ask on the libstdc++ list.
It doesn't look right, not sure what I meant to do there but
Hello,
in this test case there are two bool test variables (global and local).
Is this intentional?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains
Started with the latter. By the way, what is the policy concerning
getting write access to the wiki?
You are expected to ask one of the existing editors who's
willing to vouch for you to add you to the EditorGroup:
http://gcc.gnu.org/wiki/EditorGroup
Martin
On 15.04.2015 19:21, Manuel López-Ibáñez wrote:
> The "right" steps to see progress:
>
> 1. You think that some concrete change may improve GCC, for example, to
> move vec.h and is-a.h to some gcc/include/core. Ask if the key people
> (Global Reviewers in this case) will accept this change.
<...>
On 04/15/2015 11:53 AM, Mikhail Maltsev wrote:
You mentioned that you are planning to do reorganization of the
directory structure. That would be really helpful. LLVM has two separate
directories for utility classes, functions and custom datatypes
(llvm/include/llvm/ADT and llvm/include/llvm/Supp
On Wed, Apr 15, 2015 at 10:09:14AM +0200, Richard Biener wrote:
> On Wed, Apr 15, 2015 at 2:09 AM, Trevor Saunders
> wrote:
> > On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
> >> On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders
> >> wrote:
> >> > Hi!
> >> >
> >> > To be clear
On 15.04.2015 3:09, Trevor Saunders wrote:
> On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
>> I see no value in doing this but making branch maintainance awkward.
>
> I think its mostly valuable to cause less confusion of new people, and
> though it is a simpler thing every littl
ving c++ files with .c
extensions was for importing gcc into DragonFly's base. The system .mk
files have targets based on extension (e.g. .c=.o) and it chooses cc or
c++ based on those targets. We had to install difficult hacks to work
around it.
Honestly, mandatory renaming of the files shou
On Wed, Apr 15, 2015 at 2:09 AM, Trevor Saunders wrote:
> On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
>> On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders
>> wrote:
>> > Hi!
>> >
>> > To be clear I only want to talk about gcc/**/*.c but *not* testsuite/
>> >
>> > The Question
On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
> On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders
> wrote:
> > Hi!
> >
> > To be clear I only want to talk about gcc/**/*.c but *not* testsuite/
> >
> > The Question of changing from .c to a more standard C++ file extension
> > has
On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders wrote:
> Hi!
>
> To be clear I only want to talk about gcc/**/*.c but *not* testsuite/
>
> The Question of changing from .c to a more standard C++ file extension
> has come up a couple times. I believe its reasonable accurate to say
> the consensus
Hi!
To be clear I only want to talk about gcc/**/*.c but *not* testsuite/
The Question of changing from .c to a more standard C++ file extension
has come up a couple times. I believe its reasonable accurate to say
the consensus is moderately in favor of doing this at some point. The
biggest con
--
> Date: Sat, 9 Feb 2013 23:41:24 -0800
> Subject: Re: problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
> From: pins...@gmail.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
>
> On Sat, Feb 9, 2013 at 3:49 PM, Jay K wrote:
> > p
On 02/10/2013 12:49 AM, Jay K wrote:
> problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
> [...]
>
> 2) given:
>
> int foo()
> {
> gcc_unreachable();
> }
>
>
> Solaris cc/CC gives a warning or maybe an error.
> It should be:
>
On Sat, Feb 9, 2013 at 3:49 PM, Jay K wrote:
> problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
>
>
> 1) ENUM_BITFIELD is not portable. I've reported this before.
>
>
> It should be more like:
>
>
> #ifdef __cplusplus
> #define ENUM_BIT
On 9 February 2013 23:49, Jay K wrote:
> problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
>
>
> 1) ENUM_BITFIELD is not portable. I've reported this before.
Have you reported it to bugzilla?
> It is likely that in 4.8 this is moot, as the C++ case
problems compiling 4.7, with Solaris cc and/or Solaris CC (C++)
1) ENUM_BITFIELD is not portable. I've reported this before.
It should be more like:
#ifdef __cplusplus
#define ENUM_BITFIELD(TYPE, NAME, SIZE) enum TYPE NAME : SIZE
#elif (GCC_VERSION > 2000)
On 30 October 2012 00:30, Perry Smith wrote:
>
> On Oct 29, 2012, at 1:47 PM, Jonathan Wakely wrote:
>
>> It compiles fine with gcc if you put it in a file that ends in .cc or
>> .C or .cpp or any of the other extensions that tell gcc to run the
>> cc1plus com
On 29 October 2012 23:44, Perry Smith wrote:
>
> On Oct 29, 2012, at 1:47 PM, Jonathan Wakely wrote:
>
>> Compiling with gcc does not imply you're not compiling C++.
>
> So, in my sample code, how do you compile it with gcc?
>
Put it in a file that ends with .cc or
On Oct 29, 2012, at 1:47 PM, Jonathan Wakely wrote:
> It compiles fine with gcc if you put it in a file that ends in .cc or
> .C or .cpp or any of the other extensions that tell gcc to run the
> cc1plus compiler. Please read
> http://gcc.gnu.org/onlinedocs/gcc/Invoking-G_002b_
On Oct 29, 2012, at 1:47 PM, Jonathan Wakely wrote:
> Compiling with gcc does not imply you're not compiling C++.
So, in my sample code, how do you compile it with gcc?
nstruct that causes the compiler to produce a call to atexit is a static
>of a variable with a non-trivial destructor declared inside a function. This
>program, does not compile with gcc:
[snip]
You're wrong.
It compiles fine with gcc if you put it in a file that ends in .cc or
.C or
On Mon, Oct 29, 2012 at 9:20 AM, Perry Smith wrote:
>
> I'm sure they could be rewritten in C. GNUs libc choose to do them in C++
> probably because C++ just gives a nicer way to do things.
In the GNU libc __cxa_atexit and __cxa_finalize are written in C, not C++.
We should not add C++ code to
On Oct 29, 2012, at 9:08 AM, David Edelsohn wrote:
>
> Some of the support you are adding is equivalent to code in
> libgcc/crtstuff.c. My question was if it is possible to re-use some
> of that code for the new AIX support.
>
> Is the code really C++? Both cxa_atexit.cc and cxa_finalize.cc ar
On Oct 29, 2012, at 9:32 AM, Jonathan Wakely wrote:
> On Oct 29, 2012 1:54 PM, "Perry Smith" wrote:
>>
>> My original logic in adding them to libstdc++.a is they are only used
>> (called) by code automatically produced by g++ and not gcc.
>
> That doesn't make sense. Both gcc and g++ are just
On Oct 29, 2012 1:54 PM, "Perry Smith" wrote:
>
> My original logic in adding them to libstdc++.a is they are only used
> (called) by code automatically produced by g++ and not gcc.
That doesn't make sense. Both gcc and g++ are just driver programs
that invoke the appropriate compiler program, wh
On Mon, Oct 29, 2012 at 9:54 AM, Perry Smith wrote:
> This is on my quest to add __cxa_atexit to AIX's GCC. I'm trying to port my
> patches to trunk.
>
> David said I should move my two files to libgcc.a instead of libstdc++.a
> which is where I put them before.
>
> These files define __cxa_fin
This is on my quest to add __cxa_atexit to AIX's GCC. I'm trying to port my
patches to trunk.
David said I should move my two files to libgcc.a instead of libstdc++.a which
is where I put them before.
These files define __cxa_finalize and __cxa_atexit. These files are mostly
from GNU's libc.
so I did not follow that) to C++
>> per http://gcc.gnu.org/ml/gcc/2012-08/msg00165.html message, why are files
>> under gcc/ still keeping a .c (not a .cc) extension
>> (for example gcc/gimple-fold.c is not renamed to gcc/gimple-fold.cc), and
>> why does
>> gcc/Makefile.
On Tue, Aug 28, 2012 at 8:45 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 28 Aug 2012, Ian Lance Taylor wrote:
>
>> > Or do we have a rule than any file using C++ specific feature should
>> > be renamed from *.c to *.cc at the moment the C++ feature goes inside?
>&g
On Aug 28, 2012, at 9:45 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 28 Aug 2012, Ian Lance Taylor wrote:
>
>>> Or do we have a rule than any file using C++ specific feature should
>>> be renamed from *.c to *.cc at the moment the C++ feature goes inside?
>>
On Tue, Aug 28, 2012 at 6:45 AM, Michael Matz wrote:
>
> On Tue, 28 Aug 2012, Ian Lance Taylor wrote:
>
>> > Or do we have a rule than any file using C++ specific feature should
>> > be renamed from *.c to *.cc at the moment the C++ feature goes inside?
>>
&g
Hi,
On Tue, 28 Aug 2012, Ian Lance Taylor wrote:
> > Or do we have a rule than any file using C++ specific feature should
> > be renamed from *.c to *.cc at the moment the C++ feature goes inside?
>
> We do not have such a rule and I would not recommend it. I think we
>
1 - 100 of 149 matches
Mail list logo
