Re: [gcc-in-cxx] replacing qsort with std::sort

[Magnus Fromreide]

On Fri, 2009-08-28 at 18:12 -0300, Pedro Lamarão wrote:
> 2009/8/11 Pedro Lamarão :
> 
> > I've recently started my contributions to the gcc-in-cxx project, and
> > eventually decided on the qsort suggestion because it seems the
> > easiest one.
> 
> Attached is a much more extensive patch replacing qsort with std::sort.
> 
> I did not follow the suggestion of using bind to reuse the old
> comparison functions.
> Their "less" variants require less address taking and dereferencing
> and are much smaller.
> These functions are used at only one or two places, each of them --
> perfect for inlining.
> This patch actually reduces the size of the final binary.
> 
> I have not yet made complete size and execution speed measurements, though.
> I've run the test suite and there are some failures; I think many of
> them are not regressions when compared with a pure build with C++.

Why the changes to gcc/system.h where you unpoision malloc and realloc?
Why the changes to libcpp/system.h where you unpoision malloc, realloc,
calloc and strdup?

/MF

Re: [Ada] Anyone else run ACATS on ARM?

[Mikael Pettersson]

Laurent GUERBY writes:
 > On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
 > > On Mon, 2009-08-17 at 12:00 +0200, 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 Debian port and the conclusion was
 > > > >> that it has never been bootstrapped onto ARM. The closest I have seen
 > > > >> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows and
 > > > >> targetting Nucleus OS (gak!)
 > > > >>
 > > > >> The community feeling was that it would "just go" given a prodigal
 > > > >> burst of cross-compiling, but I never got achieved sufficiently high
 > > > >> blood pressure to try it...
 > > > >
 > > > >is there any arm-linx-gnueabi gnat binary that could be used to 
 > > > >bootstrap an 
 > > > >initial gnat-4.4 package for debian?
 > > >  > 
 > > >  >Matthias
 > > > 
 > > > Yes, see .
 > > 
 > > Nice work!
 > > 
 > > Looks like Ada exception propagation (setjmp/longjmp based) is broken at
 > > least in some cases (see below), that might explain the high number of
 > > ACATS failure.
 > > 
 > > My understanding is that
 > > 
 > >   EH_MECHANISM=-gcc
 > > 
 > > is not correct for sjlj exceptions so I removed this line from the patch
 > > and I'm currently testing with trunk.
 > 
 > With this change plus the gcc/ada/gcc-interface/targtyps.c one
 > I get very good native arm ACATS and gnat.dg results:

Thanks Laurent. I've extracted an incremental diff for the Makefile
and targtyps.c changes and applied it to my gcc-4.4.1 version. When
it has finished its rebuild I'll see if this lets me eliminate the
xsinfo.adb exception handling workaround.

 > It would be nice to have a ZCX port but so far the sjlj exceptions
 > based port works fine.

See e.g. .
Apparently ZCX on ARM/EABI will require a new personality routine.

/Mikael

Re: Checking for -rdynamic flag in gcc/configure

[Joseph S. Myers]

On Fri, 28 Aug 2009, Ian Lance Taylor wrote:

> Link a small program with -rdynamic, one which defines a globally
> visible function which is not called.  Run objdump -T and see if you can
> see that symbol in the output.
> 
> If you follow this path you must do the in_tree_ld/ld_ver dance so that
> cross-compilers continue to work.

This is testing properties of the *host* linker (build-x-host in the 
Canadian cross case), so in-tree tools (which will be built as 
host-x-target) are irrelevant, and you can always assume that the host 
tools are already installed (of course you need to make sure you use the 
correct objdump, not that for build or target).

-- 
Joseph S. Myers
jos...@codesourcery.com

Online Poker - Multiplayer!

[WassPoker]

Online Poker, and have Fun!

http://tinyurl.com/mogdze

Enjoy!

Re: GCC Status Report (2009-08-23)

[Frank Ch. Eigler]

mitch...@codesourcery.com (Mark Mitchell) writes:

> [...]  In my opinion, the single hardest issue we face with respect
> to 4.5 is how to handle the VTA branch.  [...]  The problem it's
> setting out to solve is definitely important, but the scope of this
> particular solution frightens me.  [...]

I can only address the "benefits" side of this.

I think VTA (and control-flow-related followup technologies) would
mark the beginning of the end of the entrenched idea that "if you want
to debug your code, you have to compile with -O0", which have lead to
a proliferation of asserts, ad-hoc conditional printfs, compiled-in
debugging-only functions.

With the extra dwarf metadata, already existing consumer programs will
be able to trace/debug final deployed binaries.  Developers will be
able to better see into what's going on in released, running programs,
not just ones built differently in one's own sandbox.  It should
enable new whole new development tools.

This is the grand promise, anyway.  I think it's a big step forward.

- FChE

Re: Help ! Frozen by a comment in gcc/c-common.h!

[Alexei I. Adamovich]

Hi!

On Thu, Aug 27, 2009 at 09:51:30AM -0700, Ian Lance Taylor wrote:
> I suspect that that comment is no longer relevant.  At least, I can't
> seem to find the mask.  Perhaps somebody else knows.

I got. Since no anybody more has commented, let us be sure that the
mask mechanism has gone. [I've recently found corresponding bit mask in
gcc-3.3.6 in grokdeclarator (c-decl.c), e.g:
> 3589   if (i == RID_LONG && (specbits & (1 << (int) RID_LONG)))
or
> 3624   specbits |= 1 << (int) i;
where
> 3586   enum rid i = C_RID_CODE (id);
]

So for the sake of those who will develop C-derived front ends, should
we change the comment like below:
> /* Reserved identifiers.  This is the union of all the keywords for C,
>C++, and Objective-C.  In the past, in earlier GCC versions all the
>type modifiers had to be in one block at the beginning, because
>they were used as mask bits.  There were 27 type modifiers; so if
>anybody added many more the mask mechanism would have to be
>redesigned.  Now it doesn't matter, since corresponding mask
>machinery gone */
Should I (or you) submit a patch?

Alexei I. Adamovich

Re: Help ! Frozen by a comment in gcc/c-common.h!

[Alexey I. Adamovich]

Forgot RID_LAST_MODIFIER

On Sat, Aug 29, 2009 at 08:29:21PM +0400, Alexei I. Adamovich wrote:
> So for the sake of those who will develop C-derived front ends, should
> we change the comment like below:
> > /* Reserved identifiers.  This is the union of all the keywords for C,
> >C++, and Objective-C.  In the past, in earlier GCC versions all the
> >type modifiers had to be in one block at the beginning, because
> >they were used as mask bits.  There were 27 type modifiers; so if
> >anybody added many more the mask mechanism would have to be
> >redesigned.  Now it doesn't matter, since corresponding mask
> >machinery gone */

Should the last lines be re-written as follows:
>redesigned.  Now it doesn't matter, since corresponding mask
>machinery gone.  But anyway when adding any type modifier it's
>better to follow the old rule and to get sure that
>RID_LAST_MODIFIER is defined and handled correctly also */
[?]

Alexei I. Adamovich

Re: [gcc-in-cxx] replacing qsort with std::sort

[Pedro Lamarão]

2009/8/29 Magnus Fromreide :
>
> Why the changes to gcc/system.h where you unpoision malloc and realloc?
> Why the changes to libcpp/system.h where you unpoision malloc, realloc,
> calloc and strdup?

Including  requires them for some reason.
I haven't really looked into it.

--
 P.

proper c source coding standard - style changes?

[David C. Rankin]

Listmates,

First post, and more of a curiosity than a problem. Years ago I worked 
extensively with c, fortran, etc. (late '80s, early 90s). I do my own office 
infrastructure/networking/groupware, etc. all with linux and open source 
software. Occasionally that requires me to dust off my programming tools to 
tweak this or that to work in my setting. Most recently a bit of c with the 
mysql connector. In doing so I have noticed one big change to the way source 
files are now formatted.

When I grew up doing this your source files and functions would 
normally be 
laid out in this order:

#include 

void function ();// function headers defs
int *function ();

int main () {
do something;
return 0;
}

void function () {
stuff;
}

int *function () {
stuff;
}

Now I see through much of the glibc documentation and other sources a 
layout 
like this:

#include 

void
function ()
{
stuff;
}

int *
function ()
{
stuff;
}

int
main ()
{
do something;
return 0;
}

And, yes, I know it doesn't matter to the compiler, but as I said I was 
curious. Has there been some type of recommended standard for doing it in this 
way, or is it just more of a some people like chocolate ice cream versus 
vanilla issue? In the olden days, IIRC, the logic was that you wanted to see 
the most important part of your code up top -- the main function, without 
having to wade through all the function bodies before you got to it. With the 
new layout, you don't have to worry about an additional function def up top 
with eliminates the chance of typos and makes changes easier. So I see the 
benefits of both.

Also, if this is some type of flame war issue like vi/emacs, I 
apologize in 
advance, I am not aware of its sensitivity, I'm just curious and like to 
follow the "recommended" standard in case somebody has to read my code in the 
future. Thanks.

All I'm looking for is either a (yep there was a new recommendation, 
here's 
the link) or a (it's a chocolate or vanilla thing). 

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: proper c source coding standard - style changes?

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David C. Rankin wrote:
> Listmates,
>
> First post, and more of a curiosity than a problem. Years ago I
> worked extensively with c, fortran, etc. (late '80s, early 90s). I
> do my own office infrastructure/networking/groupware, etc. all with
> linux and open source software. Occasionally that requires me to
> dust off my programming tools to tweak this or that to work in my
> setting. Most recently a bit of c with the mysql connector. In
> doing so I have noticed one big change to the way source files are
> now formatted.
>
> When I grew up doing this your source files and functions would
> normally be laid out in this order:
>
> #include 
>
> void function ();// function headers defs int *function ();
>
> int main () { do something; return 0; }
>
> void function () { stuff; }
>
> int *function () { stuff; }
>
> Now I see through much of the glibc documentation and other sources
> a layout like this:
>
> #include 
>
> void function () { stuff; }
>
> int * function () { stuff; }
>
> int main () { do something; return 0; }
>
> And, yes, I know it doesn't matter to the compiler, but as I said I
> was curious. Has there been some type of recommended standard for
> doing it in this way, or is it just more of a some people like
> chocolate ice cream versus vanilla issue? In the olden days, IIRC,
> the logic was that you wanted to see the most important part of
> your code up top -- the main function, without having to wade
> through all the function bodies before you got to it. With the new
> layout, you don't have to worry about an additional function def up
> top with eliminates the chance of typos and makes changes easier.
> So I see the benefits of both.
>
> Also, if this is some type of flame war issue like vi/emacs, I
> apologize in advance, I am not aware of its sensitivity, I'm just
> curious and like to follow the "recommended" standard in case
> somebody has to read my code in the future. Thanks.
>
> All I'm looking for is either a (yep there was a new
> recommendation, here's the link) or a (it's a chocolate or vanilla
> thing).
>
I take it you haven't done much programming, take a look at any
project on the net they all have their own code formatting preferences
for whatever helps _you_ read your code. This should probably be moved
to gcc-help...

A benefit of using the bottom formating is you don't need to keep
prototypes for the extra functions if they are being called by main.

Try not to ask questions like this in GCC, GCC-help is for help on
using gcc etc.

- --Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqZ2b0ACgkQAhcOgIaQQ2GJ4QCfXCtFIHeDfYIhoVAbMQNiEV/P
WVIAn2/61h/MwEb0f4LTdVnnZXwarbNo
=6paS
-END PGP SIGNATURE-

Re: proper c source coding standard - style changes?

[David C. Rankin]

On Saturday 29 August 2009 08:45:37 pm Philip Herron wrote:

> 
> Try not to ask questions like this in GCC, GCC-help is for help on
> using gcc etc.
> 
> --Phil
> 

Sorry Phil,

I read the guidelines at http://gcc.gnu.org/lists.html before I posted. 
The 
guidelines say:


Open lists:

* gcc-help is a relatively high volume list for people searching for help 
in building or using GCC.

* gcc is a high volume list for general development discussions about GCC. 
Anything relevant to the development or testing of GCC and not covered by 
other mailing lists is suitable for discussion here.


I didn't see the distinction, and I'm still not sure I do. But I know 
now, 
posts about general code layout questions go to the help list. Thanks.


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

Re: proper c source coding standard - style changes?

[Dave Korn]

David C. Rankin wrote:

> * gcc-help is a relatively high volume list for people searching for help 
> in building or using GCC.
> 
> * gcc is a high volume list for general development discussions about 
> GCC. 

>   I didn't see the distinction, and I'm still not sure I do. 

  By "about GCC", it means exactly that: development discussions about GCC,
the compiler itself, and not about the programs that it may be used to
compile.  So questions for this list tend to be along the lines of "How do I
add a new optimisation pass" or "How can I port GCC to generate code for a new
CPU", and not about the more general end uses to which the compiler is put,
nor about general programming themes and discussions.  Hope that clears it up
a bit.

cheers,
  DaveK

Re: proper c source coding standard - style changes?

[David C. Rankin]

On Saturday 29 August 2009 10:17:57 pm you wrote:
> David C. Rankin wrote:
> > * gcc-help is a relatively high volume list for people searching for
> > help in building or using GCC.
> >
> > * gcc is a high volume list for general development discussions about
> > GCC.
> >
> > I didn't see the distinction, and I'm still not sure I do.
>
>   By "about GCC", it means exactly that: development discussions about GCC,
> the compiler itself, and not about the programs that it may be used to
> compile.  So questions for this list tend to be along the lines of "How do
> I add a new optimisation pass" or "How can I port GCC to generate code for
> a new CPU", and not about the more general end uses to which the compiler
> is put, nor about general programming themes and discussions.  Hope that
> clears it up a bit.
>
> cheers,
>   DaveK

DaveK,

That was an excellent explanation of the scope of topics for the list. 
Since 
most of my programs tend to be less than about 250 lines and use less than 3-4 
parsing passes with loops operating on file or pipe buffers, I don't think 
I'll have to much to add concerning the fine points of compiler optimization 
;-) I'll be vigilant concerning the topic. Thanks again for the guidelines 
explained. What wouldn't be a bad addition to the list subscription page as 
well.

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com