.opt file help
Hi All,
As part of updating the OS/2 port of GCC from v4.4.x to v4.6.x I've hit
a snag where the passing of options to the linker is no longer working.
Previous OS/2 builds of gcc have supported -Zlinker on the command
line to pass the option to the linker.
With previous gcc versions this worked, however with 4.6 I get an error
about gcc not recognising the option.
I added:
-Zlinker
driver separate
to the opt file I'm using, now the option is recognised but it doesn't
know what to do with it.
I added
{-Zlinker}
to LINK_SPEC - but it's passing -Zlinker and the option to the linker.
Any hints, tips or documentation on LINK_SPEC?
Thanks in advance,
Paul
Re: Switching to C++ by default in 4.8
On Fri, Apr 6, 2012 at 2:11 AM, David Edelsohn wrote: > On Thu, Apr 5, 2012 at 4:35 PM, Gabriel Dos Reis > wrote: > >>> xlc -fno-exceptions -fno-rtti conftest.c >>> >>> fails. I don't think -fno-rtti -fno-exceptions does what GCC expects. >> >> Thanks for these data. I think -fno-rtti and -fno-exceptions don't make >> much sense at the linker level so we should leave them out, and use >> them only when "compiling", e.g. with "-c". > > It is used when compiling, e.g. gcov.c, but when compiling and linking > directly from source without an intermediate object file. These flags should be only used for stage2+ or when compiling with GCC. Did you try to bootstrap with xlc or did you use --disable-bootstrap? gcov.c is supposed to be compiled with the built GCC C++ compiler. Richard. > - David
Re: Switching to C++ by default in 4.8
On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl wrote:
> On 4/5/12, Richard Guenther wrote:
>> On Apr 4, 2012 Lawrence Crowl wrote:
>> > On 4/4/12, Richard Guenther wrote:
>> > > Making tree or gimple a C++ class with inheritance and
>> > > whatever is indeed a huge waste of time and existing developer
>> > > ressources (that, if only because they have to adapt and
>> > > maintain two completely different code-bases over some time).
>> >
>> > Trees are presently a significant problem in that many static
>> > errors become dynamic errors, which entails more debugging.
>>
>> How do you expect tree errors to become static? By using derived
>> types everywhere? Note that this would only be possible in a
>> _very_ limited sub-set of places.
>
> Yes, a class hierarchy that directly represents the type hierarchy
> already implicit in trees. With that structure in place, functions
> that require a certain kind of tree as a parameter can say so
> directly in the parameter list. Functions that return a certain
> kind of tree can say so in the return type. Calling a function
> that is inappropriate to the type will result in a static error.
>
> Certainly there are cases where the type must be made more specific,
> and getting the wrong type here would necessarily be a dynamic check.
> However, the number of dynamic checks can be substantially reduced.
> To provide a specific example, suppose I have a common_decl *p and
> need to do extra work if it is a var_decl.
>
> do_general_work (p);
> if (var_decl *q = p->to_var ())
> {
> do_var_work_1 (q);
> do_var_work_2 (q);
> do_var_work_3 (q);
> do_var_work_4 (q);
> }
>
> The only dynamic work is in the pointer conversion. All other
> function calls can be statically typed.
Ok. But the above represents a completely different programming
style than what we use currently. We do
if (is_var_decl (p))
{
do_var_work_1 (p);
...
}
so what I was refering to was static errors we get when we are
able to promote function argument / return types to more specific
sub-classes.
>> > > I expect the GCC core to maintain written in C, compiled
>> > > by C++.
>> >
>> > Converting VECs to C++ vectors vector would provide significant
>> > code clarity benefits. The files in which that is done would
>> > necessarily be C++ only.
>>
>> I already had VECs as the very first and best example why C++
>> might be good.
>
> But my point was that if we're using a C++ vector, the files are
> not written in C any more.
Of course - the whole point was to switch to C++ and start using C++
features. The point I wanted to raise is that the switch to C++ should
happen with a change that is useful and that includes getting GC "right".
Converting vec.h is such a change.
Richard.
>> > > > I also find debugging C++ in gdb somewhat more annoying
>> > > > than debugging plain C, and at the moment I always go back
>> > > > to a stage1 compiler.
>> > >
>> > > Indeed - I'd be worried if my debugging efficiency decreases
>> > > by more than 5%.
>> >
>> > If the number of debugging sessions was reduced by the same
>> > amount, the result would be a net wash.
>>
>> I have no expectation that the number of debug sessions will
>> be reduced.
>
> On the other hand, I do. There are many instances were I've debugged
> a problem to realize that it could have been a static type error.
>
> --
> Lawrence Crowl
Re: Missed optimization in PRE?
On Mon, Apr 9, 2012 at 8:00 AM, Bin.Cheng wrote: > On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote: >> On Fri, Mar 30, 2012 at 4:15 PM, Richard Guenther >> wrote: >>> On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng wrote: On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng wrote: >> On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther >> wrote: >>> On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng >>> wrote: Hi, Following is the tree dump of 094t.pre for a test program. Question is loads of D.5375_12/D.5375_14 are redundant on path >>> bb7, bb5, bb6>, but why not lowered into basic block 3, where it is used. BTW, seems no tree pass handles this case currently. >>> >>> tree-ssa-sink.c should do this. >>> >> It does not work for me, I will double check and update soon. > > Well, "should" as in, it's the place to do it. And certainly the pass > can sink > loads, so this must be a missed optimization. > Curiously, it is said explicitly that "We don't want to sink loads from memory." in tree-ssa-sink.c function statement_sink_location, and the condition is if (stmt_ends_bb_p (stmt) || gimple_has_side_effects (stmt) || gimple_has_volatile_ops (stmt) || (gimple_vuse (stmt) && !gimple_vdef (stmt)) <-check load || (cfun->has_local_explicit_reg_vars && TYPE_MODE (TREE_TYPE (gimple_assign_lhs (stmt))) == BLKmode)) return false; I haven't found any clue about this decision in ChangeLogs. >>> >>> Ah, that's probably because usually you want to hoist loads and sink stores, >>> separating them (like a scheduler would do). We'd want to restrict sinking >>> of loads to sink into not post-dominated regions (thus where they end up >>> being executed less times). > > Hi Richard, > I am testing a patch to sink load of memory to proper basic block. > Everything goes fine except auto-vectorization, sinking of load sometime > corrupts the canonical form of data references. I haven't touched auto-vec > before and cannot tell whether it's good or bad to do sink before auto-vec. > For example, the slp-cond-1.c > > : > # i_39 = PHI > D.5150_5 = i_39 * 2; > D.5151_10 = D.5150_5 + 1; > D.5153_17 = a[D.5150_5]; > D.5154_19 = b[D.5150_5]; > if (D.5153_17 >= D.5154_19) > goto ; > else > goto ; > > : > d0_6 = d[D.5150_5]; <-this is sunk from bb3 > goto ; > > : > e0_8 = e[D.5150_5]; <-this is sunk from bb3 > > : > # d0_2 = PHI > k[D.5150_5] = d0_2; > D.5159_26 = a[D.5151_10]; > D.5160_29 = b[D.5151_10]; > if (D.5159_26 >= D.5160_29) > goto ; > else > goto ; > > > : > d1_11 = d[D.5151_10]; <-this is sunk from bb3 > goto ; > > : > e1_14 = e[D.5151_10]; <-this is sunk from bb3 > > : > ... > > I will look into auto-vect but not sure how to handle this case. > > Any comments? Thanks very much. Simple - the vectorizer expects empty latch blocks. So simply never sink stuff into latch-blocks - I think the current code already tries to avoid that for regular computations. Richard. > -- > Best Regards.
Re: .opt file help
On 9 April 2012 10:59, Paul Smedley wrote: > Hi All, > > As part of updating the OS/2 port of GCC from v4.4.x to v4.6.x I've hit a > snag where the passing of options to the linker is no longer working. > > Previous OS/2 builds of gcc have supported -Zlinker on the command line > to pass the option to the linker. > > With previous gcc versions this worked, however with 4.6 I get an error > about gcc not recognising the option. > > I added: > -Zlinker > driver separate Can you simply make it an alias of the existing -Xlinker option? -Zlinker Driver Separate Alias(-Xlinker)
Re: Switching to C++ by default in 4.8
On Mon, Apr 9, 2012 at 6:37 AM, Richard Guenther wrote: > These flags should be only used for stage2+ or when compiling with GCC. > Did you try to bootstrap with xlc or did you use --disable-bootstrap? gcov.c > is supposed to be compiled with the built GCC C++ compiler. I was attempting to bootstrap with xlc and xlC -- the IBM C and C++ native compilers. - David
Re: RFC: -Wall by default
On Sun, 8 Apr 2012, Robert Dewar wrote: > Do you really want me to file hundreds of bug reports that are for > cases of uninitialized variables well known to everyone, and well > understood by everyone, and not easy to fix (or would have been > fixed long ago)? Perhaps we should move this class of warning from -Wall to -Wextra? (I'd prefer that over introducing yet another option -Wstandard.) Gerald
RE: RFC: -Wall by default
I think removing an existing warning from -Wall would be a bad idea. paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Gerald Pfeifer Sent: Monday, April 09, 2012 12:30 PM To: Robert Dewar Cc: Jonathan Wakely; James Cloos; gcc@gcc.gnu.org; Miles Bader; Gabriel Dos Reis; Ian Lance Taylor; Andrew Haley Subject: Re: RFC: -Wall by default On Sun, 8 Apr 2012, Robert Dewar wrote: > Do you really want me to file hundreds of bug reports that are for > cases of uninitialized variables well known to everyone, and well > understood by everyone, and not easy to fix (or would have been fixed > long ago)? Perhaps we should move this class of warning from -Wall to -Wextra? (I'd prefer that over introducing yet another option -Wstandard.) Gerald
Re: RFC: -Wall by default
On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer wrote: > On Sun, 8 Apr 2012, Robert Dewar wrote: >> Do you really want me to file hundreds of bug reports that are for >> cases of uninitialized variables well known to everyone, and well >> understood by everyone, and not easy to fix (or would have been >> fixed long ago)? > > Perhaps we should move this class of warning from -Wall to -Wextra? > > (I'd prefer that over introducing yet another option -Wstandard.) That would be my preferred solution -- by far. But, my understanding is that that would provoke a riot so I am willing to compromise by introducing a new warning switch (even if I dislike that thought.) Hopefully, it is it is going to be the default, most people would not have to learn yet another GCC switch. > > Gerald
Re: RFC: -Wall by default
On 4/9/2012 1:08 PM, Gabriel Dos Reis wrote: On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer wrote: On Sun, 8 Apr 2012, Robert Dewar wrote: Do you really want me to file hundreds of bug reports that are for cases of uninitialized variables well known to everyone, and well understood by everyone, and not easy to fix (or would have been fixed long ago)? Perhaps we should move this class of warning from -Wall to -Wextra? (I'd prefer that over introducing yet another option -Wstandard.) That would be my preferred solution -- by far. But, my understanding is that that would provoke a riot so I am willing to compromise by introducing a new warning switch (even if I dislike that thought.) Hopefully, it is it is going to be the default, most people would not have to learn yet another GCC switch. I would not like to see -Wall lose warnings that it has now, and I think others would find that a problme. -Wextra may be too much for that same group of people. We have certainly found it useful to have three general categories of warnings in GNAT a) the warnings that are on by default b) the warnings that are turned on by -gnatWa (similar to -Wall) c) all warnings (tunred on by -gnatw.e) Gerald
Re: RFC: -Wall by default
On Mon, Apr 9, 2012 at 12:15 PM, Robert Dewar wrote: > On 4/9/2012 1:08 PM, Gabriel Dos Reis wrote: >> >> On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer >> wrote: >>> >>> On Sun, 8 Apr 2012, Robert Dewar wrote: Do you really want me to file hundreds of bug reports that are for cases of uninitialized variables well known to everyone, and well understood by everyone, and not easy to fix (or would have been fixed long ago)? >>> >>> >>> Perhaps we should move this class of warning from -Wall to -Wextra? >>> >>> (I'd prefer that over introducing yet another option -Wstandard.) >> >> >> That would be my preferred solution -- by far. But, my understanding >> is that that would provoke a riot so I am willing to compromise by >> introducing >> a new warning switch (even if I dislike that thought.) >> Hopefully, it is it is going to be the default, most people would not have >> to learn yet another GCC switch. > > > I would not like to see -Wall lose warnings that it has now, and I think > others would find that a problme. -Wextra may be too much for that same > group of people. > > We have certainly found it useful to have three general categories of > warnings in GNAT > > a) the warnings that are on by default > b) the warnings that are turned on by -gnatWa (similar to -Wall) > c) all warnings (tunred on by -gnatw.e) We are in agreement. I was just explaining to Gerald that his proposal would have been my first choice, but I am compromising by moving to your suggestion. My complaint is the introduction of a new switch just to accomodate warnings that should not have been in -Wall. But, I can live with that. > >> >>> >>> Gerald > >
Re: RFC: -Wall by default
> That would be my preferred solution -- by far. But, my understanding > is that that would provoke a riot so I am willing to compromise by > introducing a new warning switch (even if I dislike that thought.) > Hopefully, it is it is going to be the default, most people would not have > to learn yet another GCC switch. Why to introduce a new switch then? Just select a few -W switches and enable them by default, keeping in mind that -w will disable them in any cases. -- Eric Botcazou
Re: RFC: -Wall by default
On 4/9/2012 1:29 PM, Gabriel Dos Reis wrote: We are in agreement. I was just explaining to Gerald that his proposal would have been my first choice, but I am compromising by moving to your suggestion. My complaint is the introduction of a new switch just to accomodate warnings that should not have been in -Wall. But, I can live with that. Well if the set of options is chosen right, -Wstandard is not a switch that will be used, and equally -Wno-standard will not be often used, so yes, it is an extra switch, but not one that has to be remembered. Gerald
Re: RFC: -Wall by default
On 4/9/2012 1:29 PM, Eric Botcazou wrote: That would be my preferred solution -- by far. But, my understanding is that that would provoke a riot so I am willing to compromise by introducing a new warning switch (even if I dislike that thought.) Hopefully, it is it is going to be the default, most people would not have to learn yet another GCC switch. Why to introduce a new switch then? Just select a few -W switches and enable them by default, keeping in mind that -w will disable them in any cases. I think the idea is just to have an easy way to describe the relevant set of warnings, and a specific way (-Wno-standard) to go back to the status quo.
Re: RFC: -Wall by default
On 9 April 2012 18:29, Eric Botcazou wrote: >> That would be my preferred solution -- by far. But, my understanding >> is that that would provoke a riot so I am willing to compromise by >> introducing a new warning switch (even if I dislike that thought.) >> Hopefully, it is it is going to be the default, most people would not have >> to learn yet another GCC switch. > > Why to introduce a new switch then? Just select a few -W switches and enable > them by default, keeping in mind that -w will disable them in any cases. -w prevents any warnings being printed at all, it couldn't be used to turn off -Wstandard then selectively re-enable individual options, e.g. with -Wno-standard -Wmain Introducing a new switch would mean there's a single -Wno-standard switch for those who want to restore the old default behaviour, so they don't have to explicitly add -Wno-aaa -Wno-bbb -Wno-ccc etc. Maybe -Wstandard isn't the best name though, as "standard" usually means something quite specific for compilers, and the warning switch wouldn't have anything to do with standards conformance.
Re: RFC: -Wall by default
On 4/9/2012 1:36 PM, Jonathan Wakely wrote: Maybe -Wstandard isn't the best name though, as "standard" usually means something quite specific for compilers, and the warning switch wouldn't have anything to do with standards conformance. -Wdefault might be better
Re: Switching to C++ by default in 4.8
On 4/9/12, Richard Guenther wrote:
> On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl wrote:
>> On 4/5/12, Richard Guenther wrote:
>>> How do you expect tree errors to become static? By using derived
>>> types everywhere? Note that this would only be possible in a
>>> _very_ limited sub-set of places.
>>
>> Yes, a class hierarchy that directly represents the type hierarchy
>> already implicit in trees. With that structure in place, functions
>> that require a certain kind of tree as a parameter can say so
>> directly in the parameter list. Functions that return a certain
>> kind of tree can say so in the return type. Calling a function
>> that is inappropriate to the type will result in a static error.
>>
>> Certainly there are cases where the type must be made more specific,
>> and getting the wrong type here would necessarily be a dynamic check.
>> However, the number of dynamic checks can be substantially reduced.
>> To provide a specific example, suppose I have a common_decl *p and
>> need to do extra work if it is a var_decl.
>>
>> do_general_work (p);
>> if (var_decl *q = p->to_var ())
>> {
>> do_var_work_1 (q);
>> do_var_work_2 (q);
>> do_var_work_3 (q);
>> do_var_work_4 (q);
>> }
>>
>> The only dynamic work is in the pointer conversion. All other
>> function calls can be statically typed.
>
> Ok. But the above represents a completely different programming
> style than what we use currently. We do
>
> if (is_var_decl (p))
> {
>do_var_work_1 (p);
> ...
> }
>
> so what I was refering to was static errors we get when we are
> able to promote function argument / return types to more specific
> sub-classes.
Certainly fully exploiting a class hierarchy will require a
migration of the source base. That can happen incrementally over
time. In the meantime, there are other tasks that will show more
immediate progress.
>>> > > I expect the GCC core to maintain written in C, compiled
>>> > > by C++.
>>> >
>>> > Converting VECs to C++ vectors vector would provide significant
>>> > code clarity benefits. The files in which that is done would
>>> > necessarily be C++ only.
>>>
>>> I already had VECs as the very first and best example why C++
>>> might be good.
>>
>> But my point was that if we're using a C++ vector, the files are
>> not written in C any more.
>
> Of course - the whole point was to switch to C++ and start using
> C++ features. The point I wanted to raise is that the switch to
> C++ should happen with a change that is useful and that includes
> getting GC "right". Converting vec.h is such a change.
A build conversion to C++ is a precondition to any source change
using C++, though the two could be bundled into one patch. In any
event, I agree that the conversion needs to provide value. Vectors
and hash tables are a good early target.
--
Lawrence Crowl
Re: RFC: -Wall by default
On Mon, Apr 9, 2012 at 12:36 PM, Jonathan Wakely wrote: > Maybe -Wstandard isn't the best name though, as "standard" usually > means something quite specific for compilers, and the warning switch > wouldn't have anything to do with standards conformance. I agree. I have been resisting to go there for fear of derailing the discussion, but I am open to better suggestion. -Wsanity? :-) -- Gaby
Re: RFC: -Wall by default
On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: > On 4/9/2012 1:36 PM, Jonathan Wakely wrote: > >> Maybe -Wstandard isn't the best name though, as "standard" usually >> means something quite specific for compilers, and the warning switch >> wouldn't have anything to do with standards conformance. > > > -Wdefault > > might be better except if people want warnings about "defaults" in C++11 (which can mean lot of things). -- Gaby
Re: Mirror
On Thu, 22 Mar 2012, Игорь wrote: > I've set up a new mirror for GCC. > Here are the details: > Server name – Webhostinggeeks > Server admin – Igor, whg@gmail.com > Server location – Riga, Latvia > Server address – http://mirrors.webhostinggeeks.com/ > Server protocol – http > Connection speed – 100 Mbps > Mirror location – http://mirrors.webhostinggeeks.com/gcc/ > Frequency of updates – Once a day > Please, add my mirror to your mirrors list if it’s possible. I was just going to add your server by means of the patch below, alas all attempts to rach the server time out. What's going on? Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.217 diff -u -3 -p -r1.217 mirrors.html --- mirrors.html4 Feb 2012 23:11:59 - 1.217 +++ mirrors.html9 Apr 2012 18:08:16 - @@ -29,6 +29,7 @@ mirrors. The following sites mirror Hungary, Budapest: http://robotlab.itk.ppke.hu/gcc/";>robotlab.itk.ppke.hu, thanks to Adam Rak (neurhlp at gmail.com) Japan: ftp://ftp.dti.ad.jp/pub/lang/gcc/";>ftp.dti.ad.jp, thanks to IWAIZAKO Takahiro (ftp-admin at dti.ad.jp) Japan: http://ftp.tsukuba.wide.ad.jp/software/gcc/";>ftp.tsukuba.wide.ad.jp, thanks to Kohei Takahashi (tsukuba-ftp-servers at tsukuba.wide.ad.jp) +Latvia, Riga: http://mirrors.webhostinggeeks.com/gcc/";>mirrors.webhostinggeeks.com/gcc/, thanks to Igor (whg.igp at gmail.com) The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan Cristiaan van Winkel (jc at ATComputing.nl) Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, thanks to Jan Teluch (admin at 2600.sk) UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/, thanks to mirror at mirrorservice.org
Re: Switching to C++ by default in 4.8
On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: > A build conversion to C++ is a precondition to any source change > using C++, though the two could be bundled into one patch. In any > event, I agree that the conversion needs to provide value. Vectors > and hash tables are a good early target. Hash tables? Ugh, what is wrong with the hash tables we have right now in GCC? Jakub
Re: Switching to C++ by default in 4.8
On 4/9/12, Jakub Jelinek wrote: > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: > > A build conversion to C++ is a precondition to any source change > > using C++, though the two could be bundled into one patch. In any > > event, I agree that the conversion needs to provide value. Vectors > > and hash tables are a good early target. > > Hash tables? Ugh, what is wrong with the hash tables we have > right now in GCC? Lots of boiler plate involving casting to void*. Some of that boiler plate makes the optimizer less effective. -- Lawrence Crowl
Re: Switching to C++ by default in 4.8
On Mon, Apr 09, 2012 at 11:51:56AM -0700, Lawrence Crowl wrote: > On 4/9/12, Jakub Jelinek wrote: > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: > > > A build conversion to C++ is a precondition to any source change > > > using C++, though the two could be bundled into one patch. In any > > > event, I agree that the conversion needs to provide value. Vectors > > > and hash tables are a good early target. > > > > Hash tables? Ugh, what is wrong with the hash tables we have > > right now in GCC? > > Lots of boiler plate involving casting to void*. Some of that > boiler plate makes the optimizer less effective. Have you any numbers that back that up? Jakub
Re: RFC: -Wall by default
Gabriel Dos Reis writes: > On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: >> On 4/9/2012 1:36 PM, Jonathan Wakely wrote: >> >>> Maybe -Wstandard isn't the best name though, as "standard" usually >>> means something quite specific for compilers, and the warning switch >>> wouldn't have anything to do with standards conformance. >> >> >> -Wdefault >> >> might be better > > except if people want warnings about "defaults" in C++11 (which can mean > lot of things). It doesn't have to be short: -Wdefault-warnings. 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."
Re: Switching to C++ by default in 4.8
On 4/9/12, Jakub Jelinek wrote: > On Mon, Apr 09, 2012 at 11:51:56AM -0700, Lawrence Crowl wrote: >> On 4/9/12, Jakub Jelinek wrote: >> > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: >> > > A build conversion to C++ is a precondition to any source change >> > > using C++, though the two could be bundled into one patch. In any >> > > event, I agree that the conversion needs to provide value. Vectors >> > > and hash tables are a good early target. >> > >> > Hash tables? Ugh, what is wrong with the hash tables we have >> > right now in GCC? >> >> Lots of boiler plate involving casting to void*. Some of that >> boiler plate makes the optimizer less effective. > > Have you any numbers that back that up? Not for the optimizer claim, as the conversion hasn't been done yet. -- Lawrence Crowl
Re: .opt file help
Hi Jonathan,
On 09/04/12 21:54, Jonathan Wakely wrote:
On 9 April 2012 10:59, Paul Smedley wrote:
Hi All,
As part of updating the OS/2 port of GCC from v4.4.x to v4.6.x I've hit a
snag where the passing of options to the linker is no longer working.
Previous OS/2 builds of gcc have supported -Zlinker on the command line
to pass the option to the linker.
With previous gcc versions this worked, however with 4.6 I get an error
about gcc not recognising the option.
I added:
-Zlinker
driver separate
Can you simply make it an alias of the existing -Xlinker option?
-Zlinker
Driver Separate Alias(-Xlinker)
I discovered the above shortly after posting last night. I tried it
this morning and it doesn't work :(
Looking at emx.h again - the previous code that worked with GCC <= 4.5
had as part of GCC_DRIVER_HOST_INITIALIZATION:
else if (!strcmp (argv [i], "-Zlinker"))
\
{\
if (i + 1 >= argc) \
fatal_error ("argument to `-Zlinker' is missing");\
arg [0] = "-Xlinker"; \
arg [1] = "-O"; \
arg [2] = "-Xlinker"; \
arg [3] = argv [++i]; \
arg_count = 4;\
} \
So it looks like it was rewriting a gcc option of (for example)
-Zlinker /PM:PM
to -Xlinker -O -Xlinker /PM:PM
whereas alias's Zlinker to -xlinker just results in -Xlinker /PM:PM
which fails :(
Re: .opt file help
On 10/04/12 07:17, Paul Smedley wrote:
Hi Jonathan,
On 09/04/12 21:54, Jonathan Wakely wrote:
On 9 April 2012 10:59, Paul Smedley wrote:
Hi All,
As part of updating the OS/2 port of GCC from v4.4.x to v4.6.x I've
hit a
snag where the passing of options to the linker is no longer working.
Previous OS/2 builds of gcc have supported -Zlinker on the
command line
to pass the option to the linker.
With previous gcc versions this worked, however with 4.6 I get an error
about gcc not recognising the option.
I added:
-Zlinker
driver separate
Can you simply make it an alias of the existing -Xlinker option?
-Zlinker
Driver Separate Alias(-Xlinker)
I discovered the above shortly after posting last night. I tried it this
morning and it doesn't work :(
Looking at emx.h again - the previous code that worked with GCC <= 4.5
had as part of GCC_DRIVER_HOST_INITIALIZATION:
else if (!strcmp (argv [i], "-Zlinker")) \
{ \
if (i + 1 >= argc) \
fatal_error ("argument to `-Zlinker' is missing");\
arg [0] = "-Xlinker"; \
arg [1] = "-O"; \
arg [2] = "-Xlinker"; \
arg [3] = argv [++i]; \
arg_count = 4; \
} \
So it looks like it was rewriting a gcc option of (for example)
-Zlinker /PM:PM
to -Xlinker -O -Xlinker /PM:PM
whereas alias's Zlinker to -xlinker just results in -Xlinker /PM:PM
which fails :(
FWIW - having the following in LINK_SPEC appears to fix it:
"%{Zlinker*:-O %*}" \
Re: Switching to C++ by default in 4.8
On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
wrote:
> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt wrote:
>> On 04/04/2012 11:06 AM, Richard Guenther wrote:
>>> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined
>>> by transitioning vec.h to a C++ template class, with proper GC support.
>>> (not sure that I can veto anything - heh)
>>
>> I don't think I can veto anything, but I'll go on the record again
>> saying that I don't think this entire plan is a good idea. Write a new
>> project in C++? Absolutely. Convert a large existing one to a different
>> language? A huge waste of time that will distract us for years from
>> actual user-visible changes.
>
> I agree for the idea of converting all of GCC to C++ (whatever that means).
> I disagree for the part making the internal infrastructure easier to use,
> understand and maintain. Which means targeting mostly isolated sub-systems,
> like vec.h (and other various containers), double-int.[ch] (and other various
> way of representing and working with constants). Making tree or gimple a
> C++ class with inheritance and whatever is indeed a huge waste of time
> and existing developer ressources (that, if only because they have to adapt
> and maintain two completely different code-bases over some time).
>
> I expect the GCC core to maintain written in C, compiled by C++.
GCC's current C programming APIs (both browsing APIs and
creator/factory APIs) are somewhat primitive and too low level. I
expect switching to C++ can significantly make GCC more modern
looking. It can greatly improve readability and productivity (for
simplifying transformation and instrumentation development). C++
features should not be be abused (e.g., MI, VI etc), but we should not
miss on basic C++ features.
Class hierarchy is one such feature that is useful. Assuming we have
two hierarchies for gcc: one for values rooted at ValExp, and one for
gimple stmts rooted at GimpInst.
1) For IR browsing,
*) all the macro accessors can be eliminated -- a big plus for debugging;
*) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
e.g.
exp->as_component_ref().get_field() ..
exp->as_mem_access().get_base() ...
exp->as_mem_acesss().get_address() --> produces the
address expression for memory access
exp->as_mem_access().get_alias_handle ()
gimple_inst->serialize (&fixup_list) --> a virtual
function overriden by actual instruction types that knows its byte
code format.
For experienced GCC developers, current APIs won't a problem at all --
but it does become a big minus for newbies and in the long run will
hurt gcc community.
2) IR manipulation APIs -- the problem seems more serious. It seems
GCC prefers low level APIs so that incremental update of derived data
(control flow, SSA) can be easier -- but that does not have to be the
case -- high level APIs can hide most of the update from the
programmer.
Example: Create a a simple assignment instruction from a load (this
example comes from Asan implementation in gcc by Kostya)
t = build1 (INDIRECT_REF, some_type,
build1 (VIEW_CONVERT_EXPR, some_type, addr));
t = force_gimple_operand (t, &stmts, false, NULL_TREE);
gimple_seq_add_seq (&seq, stmts);
the_value = make_rename_temp (shadow_type, "__var_name");
g = gimple_build_assign (the_value, t);
nm = make_ssa_name (the_value, g);
gimple_assign_set_lhs (g, nm);
This can be as simple as (by hiding the gimplification, ssa name creation etc)
new_assign_insn = gimple::new_load_insn (INDIRECT_REF, some_type, addr_exp);
new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("...");
The creator interface can also take a form that accepts the addr_insn
that produces the address.
Another example:
Instrument a BB1 so that it is guarded:
if (counts > sampling_rate) // BB0
{
counts = 0;
ORIGINAL BB1 code
} // BB2
It can be as simple as the following:
basic_block bb0, bb1;
gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (),
bb1,
/* taken branch* /
&bb2, /* fall through */
&bb2, /* merge point */
&bb0 /* New predecessor */);
reset_count = gimple:new_store_insn (..., bb1, insert_before);
If the current APIs are used to do the coding, it will take how X
times more API calls which is non-readable for human beings.
thanks,
David
>
>> I also find debugging C++ in gdb somewhat more annoying than debugging
>> plain C, and at the moment I always go back to a stage1 compiler.
>
> Indeed - I'd be worried if my debugging efficiency decreases by more than 5%.
>
> Richard.
Re: RFH - Testing targets for the switch to C++
On Fri, 6 Apr 2012, Diego Novillo wrote: > The testing plan is, then, to go through this table to make sure that > we can build all of them with C++ enabled for all stages. > > I have created a wiki page to track testing progress: > http://gcc.gnu.org/wiki/CppBuildStatus > > My plea for help is to everyone who has access to the targets > mentioned in the list: please follow the instructions in that > page and fill-in the table entries of the targets that you tested. Done for i386-unknown-freebsd10.0 (GCC 4.2 as system compiler). No problems. Gerald
Re: Warn if making external references to local stack memory?
"sa...@hederstierna.com" writes: > GCC does warn if returning a pointer to a local variable (stack memory). > But there are alot of more cases where GCC could possibly warn, > eg. when references are made to local variables or stack memory. > > See this attached example code. > GCC warns for first case, but not the others. > I think all cases can be considered program bugs, > and could trigger a compiler warning I think. Thanks. I would encourage you to file an enhancement request at http://gcc.gnu.org/bugzilla/ . > I've found out that the present warning is done in "c-typeck.c", > is this the right place to but additional warnings of this kind too? Since these sorts of errors can occur in both C and C++ it would be slightly better to use a common framework for them if possible, perhaps in c-family/c-common.c. I haven't really thought about what is required here, though. Ian
Re: RFC: -Wall by default
Maybe -Wstandard isn't the best name though, as "standard" usually... AS> It doesn't have to be short: -Wdefault-warnings. I haven't looked at all of the replies since I posted, and I *had* forgotten about -Wextra (I can't even remember how many years it has been since I last read that section of the manual), but adding a new option to contain the default warnings fits well with my thesis. Something like -Wdefault-warnings is a reasonable choice, for the reasons already mentioned in this sub-thread. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: RFC: -Wall by default
> Something like -Wdefault-warnings is a reasonable choice, for the > reasons already mentioned in this sub-thread. Purists will find that -Wdefault-warnings is redundant though, since -W is supposed to mean "warning" already, e.g. it's -Wall and not -Wall-warnings. -- Eric Botcazou
