patch for long lines in makefile

[Jay]

Whenever I open gcc/Makefile in my usual editor, Visual C++ 5.0,
which is often, I get a warning about lines being
wrapped at 2048. I can't edit the file, without fixing this.


It is annoying.


This fixes it.
There are two parts and you can take either or both.
 Either newline for each language, or newline for every few files, or both.
 If there are any quotes, the second part gives up, since they could be quoting
  spaces and lead to breaks at incorrect points.
I only tested this on Cygwin, but could test on a few others if required.
I know it's not a huge issue, but it would be nice to fix.
It sadly took quite a while to get to work. I tried with just one temp file, 
and failed.
The diff is against the 4.3.1 release.


--- /src/gcc.orig/gcc/configure 2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure  2008-07-28 01:55:52.692206100 -0700
@@ -17026,13 +17026,31 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
-   all_gtfiles="$all_gtfiles [$subdir] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third 
escapes the newline.
+   all_gtfiles="$all_gtfiles"' \\\
+  '"[$subdir] $gtfiles"
 done

 # Pick up gtfiles for c
 gtfiles=
 . ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [c] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third 
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+  '"[c] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+if grep [\"\'] conftest.gt1; then :; else
+  # Six slashes will immediately become three slashes. Later, via 
sed/AC_SUBST, first two will become one, third escapes the newline.
+  # The seventh slash is for the newline the first time.
+  sed 's/\([^ \\][^ \\]* \)\{5\}/\0\\\n  /g' conftest.gt1> conftest.gt2
+  all_gtfiles=`cat conftest.gt2`
+fi

 check_languages=
 for language in $all_selected_languages


--- /src/gcc.orig/gcc/configure.ac  2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure.ac   2008-07-28 01:55:43.270331100 -0700
@@ -3639,13 +3639,33 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
-   all_gtfiles="$all_gtfiles [[$subdir]] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third 
escapes the newline.
+   all_gtfiles="$all_gtfiles"' \\\
+  '"[[$subdir]] $gtfiles"
 done

 # Pick up gtfiles for c
 gtfiles=
 . ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [[c]] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third 
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+  '"[[c]] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+changequote(,)dnl
+if grep [\"\'] conftest.gt1; then :; else
+  # Six slashes will immediately become three slashes. Later, via 
sed/AC_SUBST, first two will become one, third escapes the newline.
+  # The seventh slash is for the newline the first time.
+  sed 's/\([^ \\][^ \\]* \)\{5\}/\0\\\n  /g' conftest.gt1> conftest.gt2
+  all_gtfiles=`cat conftest.gt2`
+fi
+changequote([,])dnl

 check_languages=
 for language in $all_selected_languages


Thanks,
 - Jay
--- /src/gcc.orig/gcc/configure 2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure  2008-07-28 01:55:52.692206100 -0700
@@ -17026,13 +17026,31 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
-   all_gtfiles="$all_gtfiles [$subdir] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third 
escapes the newline.
+   all_gtfiles="$all_gtfiles"' \\\
+  '"[$subdir] $gtfiles"
 done
 
 # Pick up gtfiles for c
 gtfiles=
 . ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [c] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third 
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+  '"[c] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+if grep [\"\'] conftest.gt1; then :; else
+  # Six slashes will immediately become three slashes. Later, via 
sed/AC_SUBST, first two will become one, third escapes the newline.
+  # The seventh slash is for the newline the first time.
+  sed 's/\([^ \\][^ \\]* \)\{5\}/\0\\\n  /g' conftest.gt1 > conftest.gt2
+  all_gtfiles=`cat conftest.gt2`
+fi
 
 check_languages=
 for language in $all_selected_languages
--- /src/gcc.orig/gcc/configure.ac  2008-05-21 01:5

Re: gcc will become the best optimizing x86 compiler

[Andrew Haley]

Agner Fog wrote:
> Basile STARYNKEVITCH wrote:
>>At last, at the recent (july 2008) GCC summit, someone (sorry I forgot
> who, probably someone from SuSE)
>> proposed in a BOFS to have architecture and machine specific
> hand-tuned (or even hand-written assembly) low
>> level libraries for such basic things as memset etc..
> 
> That's exactly what I meant. The most important memory, string and math
> functions should use hand-tuned assembly with CPU dispatching for the
> latest instruction sets. My experiments show that the speed can be
> improved by a factor 3 - 10 for unaligned memcpy on Intel processors
> (http://www.agner.org/optimize/optimizing_cpp.pdf page 12).

Is this still true if you have to go through the PLT to make a position-
independent call?  That's the most common case for userspace on GNU/Linux.

Andrew.

Re: I will not merge tuples into mainline today

[Martin Jambor]

Hi,

On Fri, Jul 25, 2008 at 04:35:51PM -0300, Diego Novillo wrote:
>
> While doing the final trunk->tuples merge, I was surprised to find several 
> changes to the inliner and IPA cprop that I was convinced were not going to 
> happen until after the branch was merged.

I'm sorry this turned out this bad.  I thought that by providing
tuples version I'd make my changes barable.

> So, I will now review the changes that Martin had posted for tuples, let 
> him commit the reviewed patch and then try again the merge next week 
> (probably next Thursday or Friday).
>
> Martin, Jan, does this sound OK to you?

That's perfectly fine.  I hope Richi will have more luck today.

Martin

Re: gcc will become the best optimizing x86 compiler

[Agner Fog]

Michael Meissner wrote:
>Memcpy/memset optimizations were added to glibc 2.8, though when your 
favorite

>distribution will provide it is a different question:
>http://sourceware.org/ml/libc-alpha/2008-04/msg00050.html

I finally got a SUSE with glibc 2.8. I can see that 32-bit memcpy has 
been modified with an extra misalignment branch, but no significant 
improvement. Glibc 2.8 is NOT faster than glibc 2.7 in my tests. It 
still doesn't use XMM registers.


Glibc 2.8 is still almost 5 times slower than the best function 
libraries for unaligned data on Intel Core 2, and the default builtin 
function is slower than any other implementation I have seen (copies 1 
byte at a time!).


Tarjei Knapstad wrote:
>2008/7/26 Agner Fog <[EMAIL PROTECTED]>:
>>I have libc version 2.7. Can't find version 2.8
>It's in Fedora 9, I have no idea why the source isn't directly
>available from the glibc homepage.

2.8 is not an official final release yet.

std::isfinite broken?

[Neal Becker]

gcc-4.3.0-8.x86_64

I have test code that does passes std::isfinite (x), yet if I print the
values to std::cout the value printed is 'inf'.  Is std::isfinite (x)
broken?

Re: std::isfinite broken?

[Paolo Carlini]

Neal Becker wrote:

gcc-4.3.0-8.x86_64

I have test code that does passes std::isfinite (x), yet if I print the
values to std::cout the value printed is 'inf'.  Is std::isfinite (x)
broken?
  
Whatever bug it may have - it can, of course - std::isfinite returns an 
*int*, therefore your statement seems at the very least rather weird. A 
self-contained testcase is badly needed.


Paolo.

Re: std::isfinite broken?

[Neal Becker]

Paolo Carlini wrote:

> Neal Becker wrote:
>> gcc-4.3.0-8.x86_64
>>
>> I have test code that does passes std::isfinite (x), yet if I print the
>> values to std::cout the value printed is 'inf'.  Is std::isfinite (x)
>> broken?
>>   
> Whatever bug it may have - it can, of course - std::isfinite returns an
> *int*, therefore your statement seems at the very least rather weird. A
> self-contained testcase is badly needed.
> 
> Paolo.

I found that compiling without -ffast-math would allow std::isfinite to
work.  Sorry if the statement was confusing.  The code looks something
like:

[calculate x]
if (not isfinite (x))
  throw std::runtime_error ("blah")

Re: std::isfinite broken?

[Richard Guenther]

On Mon, Jul 28, 2008 at 1:52 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
> Paolo Carlini wrote:
>
>> Neal Becker wrote:
>>> gcc-4.3.0-8.x86_64
>>>
>>> I have test code that does passes std::isfinite (x), yet if I print the
>>> values to std::cout the value printed is 'inf'.  Is std::isfinite (x)
>>> broken?
>>>
>> Whatever bug it may have - it can, of course - std::isfinite returns an
>> *int*, therefore your statement seems at the very least rather weird. A
>> self-contained testcase is badly needed.
>>
>> Paolo.
>
> I found that compiling without -ffast-math would allow std::isfinite to
> work.

That's by desing.  With -ffast-math you are assessing that Infs and NaNs
do not occur, so the compiler optimizes the call to isfinite.

Richard.

Re: std::isfinite broken?

[Paolo Carlini]

... ah, ok, now I see what you meant, you meant that x is *not* finite, 
still, std::isfinite(x) != 0. Still, testcase badly needed...


Paolo.

Re: std::isfinite broken?

[Paolo Carlini]

Neal Becker wrote:

I found that compiling without -ffast-math would allow std::isfinite to
work.  Sorry if the statement was confusing.  The code looks something
like:

[calculate x]
if (not isfinite (x))
  throw std::runtime_error ("blah")
  
Well, -ffast-math implies -ffinite-math-only, I think you have to pass 
-fno-finite-math-only if you want to deal correctly with infinities.


Paolo.

Re: std::isfinite broken?

[Neal Becker]

Paolo Carlini wrote:

> ... ah, ok, now I see what you meant, you meant that x is *not* finite,
> still, std::isfinite(x) != 0. Still, testcase badly needed...
> 
> Paolo.
#include 
#include 

int main () {
  double x = log (0);
  if (not std::isfinite (x)) {
throw std::runtime_error ("not finite");
  }
}

Compiled with -O3 -ffast-math will not throw.

Re: gcc will become the best optimizing x86 compiler

[Daniel Jacobowitz]

On Mon, Jul 28, 2008 at 12:56:57PM +0200, Agner Fog wrote:
> >2008/7/26 Agner Fog <[EMAIL PROTECTED]>:
> >>I have libc version 2.7. Can't find version 2.8
> >It's in Fedora 9, I have no idea why the source isn't directly
> >available from the glibc homepage.
>
> 2.8 is not an official final release yet.

That's incorrect; the glibc maintainers just don't care much for
tarballs.  You can find the tag in CVS from several months ago.

-- 
Daniel Jacobowitz
CodeSourcery

Re: lto gimple types and debug info

[Michael Matz]

Hi,

On Fri, 25 Jul 2008, Chris Lattner wrote:

> >But not all the trees implementing those types (and all the 
> >cross-references between those, that are important for parsing but not 
> >interesting at all for the middle-end).  All you need is a tag (alias 
> >set number) per type and a graph giving the conflicts between those 
> >tags.
> 
> With that level of information,

[Of course I wasn't saying that alias tags would be the _only_ information 
we would store about types, but the only important one for retaining 
useful aliasing info]

> how do you "link" the alias trees for different modules at LTO time?

You merge the graphs, create cross module conflicts, and possibly can 
collapse some nodes into one, namely when both are associated with the 
"same" type.

You need a way to recognize certain types as "the same".  There are 
several means to do that (let A and B be two modules):
1) no cross-module type is the same --> create conflicts between all
   types(A) and types(B), 
2) name-based type equality, works for a subset of languages, those nodes 
   only generate one node in the destination graph (and hence no conflict 
   between them)
3) structural equality, is not correct for many languages
4) special cases; e.g. the compiler "knowing" that fortran REAL*8 and C's 
   double is the same.

and some in between.  Of course that is the important thing to ask for a 
type system: "when are two types the same".  Everything follows from that, 
including how to deal with aliasing.  Hence we need to make sure that what 
we store about types let's us answer this question conservatively correct.  

Storing everything the trees contain doesn't even help here, as even that 
one only allows to answer the same-ness test inside one module (as can be 
seen by the hacks required to make -combine work, and that was only C).  

When discussing about the middle-end type system (i.e. the one implemented 
in useless_type_conversion_p) we defined type equality in terms of 
operations applicable to values of that type.  That's unfortunately not 
possible for real cross-module (and even cross-language) modules that 
define types explicitely via their layout and attributes, not implicitely 
by their operations (though we can infer operations for simple types).


Ciao,
Michael.

Aldy and Jakub apponted GIMPLE maintainers

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Aldy Hernandez and Jakub Jelinek as GIMPLE maintainers.

Please join me in congratulating Aldy and Jakub on their new role.
Aldy, Jakub, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: GCC trunk frozen for the tuples merge

[Richard Guenther]

On Sun, 27 Jul 2008, Richard Guenther wrote:

> The trunk is frozen now until after the merge of the tuples branch
> which will happen tomorrow, Monday Jul 28th.  Unfreezing of the
> trunk will be annonced after the fact.

The merge is done and the trunk is open again under the usual
stage1 rules.

Please make sure to re-check your patches before committing them,
as the tuples merge brought in quite some changes in infrastructure.

Thanks,
Richard.

Re: GCC trunk frozen for the tuples merge

[Jack Howarth]

Richard,
   Is there any information on what sort of performance improvements
we might see from the tuples merge? Or would those require additional
merges like graphite?
 Jack

On Mon, Jul 28, 2008 at 04:42:26PM +0200, Richard Guenther wrote:
> On Sun, 27 Jul 2008, Richard Guenther wrote:
> 
> > The trunk is frozen now until after the merge of the tuples branch
> > which will happen tomorrow, Monday Jul 28th.  Unfreezing of the
> > trunk will be annonced after the fact.
> 
> The merge is done and the trunk is open again under the usual
> stage1 rules.
> 
> Please make sure to re-check your patches before committing them,
> as the tuples merge brought in quite some changes in infrastructure.
> 
> Thanks,
> Richard.

Re: GCC trunk frozen for the tuples merge

[Richard Guenther]

On Mon, 28 Jul 2008, Jack Howarth wrote:

> Richard,
>Is there any information on what sort of performance improvements
> we might see from the tuples merge? Or would those require additional
> merges like graphite?

The tuples is supposed to reduce the memory footprint of our tree IL
and as a second order effect reduce compile-time.  There are no
performance improvements expected - in fact any changes in performance
are unwanted.

Richard.

Re: GCC trunk frozen for the tuples merge

[Jack Howarth]

Richard,
Thanks for the clarification. So we ought to see some improvements
in the compile time of the polyhedron benchmarks by tomorrow...

http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/

The graphite merge should provide some performance improvement
regarding loop optimizations, no?
  Jack

On Mon, Jul 28, 2008 at 05:04:56PM +0200, Richard Guenther wrote:
> On Mon, 28 Jul 2008, Jack Howarth wrote:
> 
> > Richard,
> >Is there any information on what sort of performance improvements
> > we might see from the tuples merge? Or would those require additional
> > merges like graphite?
> 
> The tuples is supposed to reduce the memory footprint of our tree IL
> and as a second order effect reduce compile-time.  There are no
> performance improvements expected - in fact any changes in performance
> are unwanted.
> 
> Richard.

Re: gcc will become the best optimizing x86 compiler

[Michael Matz]

Hi,

On Mon, 28 Jul 2008, Agner Fog wrote:

> Glibc 2.8 is still almost 5 times slower than the best function 
> libraries for unaligned data on Intel Core 2, and the default builtin 
> function is slower than any other implementation I have seen (copies 1 
> byte at a time!).

You must be doing something wrong.  If the compiler decides to inline the 
string ops it either knows the size or you told it to do it anyway 
(-minline-all-stringops or -minline-stringops-dynamically).  In both cases 
will it use wider than byte moves when possible.


Ciao,
Michael.

Re: gcc will become the best optimizing x86 compiler

[Dennis Clarke]

On Mon, Jul 28, 2008 at 8:10 AM, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 28, 2008 at 12:56:57PM +0200, Agner Fog wrote:
>> >2008/7/26 Agner Fog <[EMAIL PROTECTED]>:
>> >>I have libc version 2.7. Can't find version 2.8
>> >It's in Fedora 9, I have no idea why the source isn't directly
>> >available from the glibc homepage.
>>
>> 2.8 is not an official final release yet.
>
> That's incorrect; the glibc maintainers just don't care much for
> tarballs.  You can find the tag in CVS from several months ago.

this page :

http://www.gnu.org/software/libc/

says :

Current Status
The current version is 2.7.

See the NEWS file for more information.

There is a FAQ which you should read first.


also, IMO, the NEWS sections says nothing useful to any human.

Dennis

Re: gcc will become the best optimizing x86 compiler

[Paolo Carlini]

Dennis Clarke wrote:

also, IMO, the NEWS sections says nothing useful to any human.
  

but, *some* humans like to click on the first (download) link on top.

Paolo.

Re: Aldy and Jakub apponted GIMPLE maintainers

[Aldy Hernandez]

On Mon, Jul 28, 2008 at 10:38:43AM -0400, David Edelsohn wrote:
>   I am pleased to announce that the GCC Steering Committee has
> appointed Aldy Hernandez and Jakub Jelinek as GIMPLE maintainers.
> 
>   Please join me in congratulating Aldy and Jakub on their new role.
> Aldy, Jakub, please update your listing in the MAINTAINERS file.

I added both Jakub and myself.

Thank you.

* MAINTAINERS: Add Jakub and myself as gimple maintainers.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 138210)
+++ MAINTAINERS (working copy)
@@ -166,6 +166,8 @@ c++ runtime libsLoren J. Rittle ljritt
 *synthetic multiplyTorbjorn Granlund   [EMAIL PROTECTED]
 *c-torture Torbjorn Granlund   [EMAIL PROTECTED]
 fixincludesBruce Korb  [EMAIL PROTECTED]
+gimple*Jakub Jelinek   [EMAIL PROTECTED]
+gimple*Aldy Hernandez  [EMAIL PROTECTED]
 gcse.c Jeff Law[EMAIL PROTECTED]
 global opt framework   Jeff Law[EMAIL PROTECTED]
 jump.c David S. Miller [EMAIL PROTECTED]

Re: gcc will become the best optimizing x86 compiler

[Dennis Clarke]

On Mon, Jul 28, 2008 at 1:17 PM, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Dennis Clarke wrote:
>>
>> also, IMO, the NEWS sections says nothing useful to any human.
>>
>
> but, *some* humans like to click on the first (download) link on top.

where ?

It says

Availability
The releases are available at http://ftp.gnu.org/gnu/glibc/ and its mirrors.

which has glibc-2.7.tar.bz2 as the latest.

hold on .. on the NEWS page I see ... okay .. how very user friendly.
Sort of the thing one would put on the project homepage I would think.

Dennis

Re: gcc will become the best optimizing x86 compiler

[Ian Lance Taylor]

"Dennis Clarke" <[EMAIL PROTECTED]> writes:

> hold on .. on the NEWS page I see ... okay .. how very user friendly.
> Sort of the thing one would put on the project homepage I would think.

The glibc project has their own special approach to user friendliness.

Ian

RE: gcc will become the best optimizing x86 compiler

[Dave Korn]

Dennis Clarke wrote on 28 July 2008 18:54:

> On Mon, Jul 28, 2008 at 1:17 PM, Paolo Carlini <[EMAIL PROTECTED]>
> wrote: 
>> Dennis Clarke wrote:
>>> 
>>> also, IMO, the NEWS sections says nothing useful to any human.
>>> 
>> 
>> but, *some* humans like to click on the first (download) link on top.
> 
> where ?
> 
> It says
> 
> Availability
> The releases are available at http://ftp.gnu.org/gnu/glibc/ and its
> mirrors. 
> 
> which has glibc-2.7.tar.bz2 as the latest.
> 
> hold on .. on the NEWS page I see ... okay .. how very user friendly.
> Sort of the thing one would put on the project homepage I would think.

  It's not the NEWS page; it's a link to the source of the NEWS file stored
in the glibc CVS repository.

  The gnu.org page is rather out of date, and a bit obfuscated.

  Most GNU projects have a prominent link in their gnu.org directory page to
the actual project home page; in this case it's tucked away on the
"resources" page in the "Project website" section.  (Oh, and it still points
to "sources.redhat.com", which is a sign of just how out-of-date that
gnu.org page really is...)

  Follow that link, and you'll see the *real* project home, with the real
news and the real latest-release info, and the real list of mailing lists,
and the wiki, and ...



cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: gcc will become the best optimizing x86 compiler

[Dennis Clarke]

On Mon, Jul 28, 2008 at 2:30 PM, Dave Korn <[EMAIL PROTECTED]> wrote:
> Dennis Clarke wrote on 28 July 2008 18:54:
>
>> On Mon, Jul 28, 2008 at 1:17 PM, Paolo Carlini <[EMAIL PROTECTED]>
>> wrote:
>>> Dennis Clarke wrote:

 also, IMO, the NEWS sections says nothing useful to any human.

>>>
>>> but, *some* humans like to click on the first (download) link on top.
>>
>> where ?
>>
>> It says
>>
>> Availability
>> The releases are available at http://ftp.gnu.org/gnu/glibc/ and its
>> mirrors.
>>
>> which has glibc-2.7.tar.bz2 as the latest.
>>
>> hold on .. on the NEWS page I see ... okay .. how very user friendly.
>> Sort of the thing one would put on the project homepage I would think.
>
>  It's not the NEWS page; it's a link to the source of the NEWS file stored
> in the glibc CVS repository.
>
>  The gnu.org page is rather out of date, and a bit obfuscated.
>
>  Most GNU projects have a prominent link in their gnu.org directory page to
> the actual project home page; in this case it's tucked away on the
> "resources" page in the "Project website" section.  (Oh, and it still points
> to "sources.redhat.com", which is a sign of just how out-of-date that
> gnu.org page really is...)
>
>  Follow that link, and you'll see the *real* project home, with the real
> news and the real latest-release info, and the real list of mailing lists,
> and the wiki, and ...

the *real* wiki ?  :-)

Dennis

ps: I used CVS to get the sources.

Re: RFC: Adding non-PIC executable support to MIPS

[Richard Sandiford]

Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>>> All comments welcome - Richard, especially from you.  How would you
>>> like to proceed?  I think the first step should be to get your other
>>> binutils/gcc patches merged, including MIPS16 PIC; I used those as a
>>> base.  But see a few of the notes for potential problems with those
>>> patches.
>> 
>> Yeah, Nick's approved most of the remaining binutils changes (thanks).
>> I haven't applied them yet because of the doubt over whether st_size
>> should be even or odd for ISA-encoded MIPS16 symbols.  I don't really
>> have an opinion, so I'll accept a maintainerly decision...
>
> [I'm not sure if this is a helpful suggestion or not, so feel free to 
> ignore it if it's not.]
>
> I would suggest that st_size be the actual size of the function, as it 
> lives in memory.  A test of it's start/end location is "could I stick a 
> random data byte there and have it affect the function".  For example, 
> for a Thumb function whose ISA address is "0x0001", I would consider 
> for size purposes that it starts at "0x", since altering that 
> byte at run-time would change the meaning of the function.

For the record, my reasoning when picking the odd st_size was similar,
but with the opposite outcome.  The point of using an ISA-encoded
st_value is that that's what most users want.  Most of them won't
even have code to say "is this a MIPS16 symbol?".

So if users are going to get into the habit of using MIPS st_values
without checking the "ISA bit", I thought it was more conservative to
base the end address on the unmodified st_value rather than the modified
one.  In other words, I thought it was more conservative to have
"st_value + st_size" be the end point of the function, rather than
"(st_value & ~1) + st_size".  This ensures that "st_value" and
"st_value + st_size - 1" are bytes in the function, rather than making
"st_value + st_size" be two bytes past the end of the function (and thus
making "st_value + st_size - 1" refer to something outside the function).

But like I say, I can see there are pros and cons both ways, so I don't
really have an opinion.  I'm happy to (and do) accpet Dan's decision.
And I guess the ARM experience shows that my concern isn't really an
issue in practice anyway.

Richard

frameworklet to assess the quality of debug information

[Alexandre Oliva]

Here's my first cut at trying to tell how well or how bad we perform
in terms of debug info, that can be dropped into the GCC run-time test
infrastructure and used by means of #include in new tests that add
GUALCHK* annotations (or with separate compilation, if some stuff is
moved into a separate header).

Thoughts, comments, suggestions, tomatoes, eggs? :-)

/* Infrastructure to test the quality of debug information.
   Copyright (C) 2008 Free Software Foundation, Inc.
   Contributed by Alexandre Oliva <[EMAIL PROTECTED]>.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3.  If not see
.  */

#include 
#include 
#include 
#include 
#include 
#include 

/* This is a first cut at checking that debug information matches
   run-time.  The idea is to annotate programs with GUALCHK* macros
   that guide the tests.

   In the current implementation, all of the macros expand to function
   calls.  On the one hand, this interferes with optimizations; on the
   other hand, it establishes an optimization barrier and a clear
   inspection point, where previous operations (as in the abstract
   machine) should have been completed and have their effects visible,
   and future operations shouldn't have started yet.

   In the current implementation of guality_check(), we fork a child
   process that runs gdb, attaches to the parent process (the one that
   called guality_check), moves up one stack frame (to the caller of
   guality_check) and then examines the given expression.

   If it matches the expected value, we have a PASS.  If it differs,
   we have a FAILure.  If it is missing, we'll have a FAIL or an
   UNRESOLVED depending on whether the variable or expression might be
   unavailable at that point, as indicated by the third argument.

   We envision a future alternate implementation with two compilation
   and execution cycles, say one that runs the program and uses the
   macros to log expressions and expected values, another in which the
   macros expand to nothing and the logs are used to guide a debug
   session that tests the values.  How to identify the inspection
   points in the second case is yet to be determined.  It is
   recommended that GUALCHK* macros be by themselves in source lines,
   so that __FILE__ and __LINE__ will be usable to identify them.
*/

/* Attach a debugger to the current process and verify that the string
   EXPR, evaluated by the debugger, yields the long long number VAL.
   If the debugger cannot compute the expression, say because the
   variable is unavailable, this will count as an error, unless unkok
   is nonzero.  */

#define GUALCHKXPRVAL(expr, val, unkok) \
  guality_check ((expr), (val), (unkok))

/* Check that a debugger knows that EXPR evaluates to the run-time
   value of EXPR.  Unknown values are marked as acceptable,
   considering that EXPR may die right after this call.  This will
   affect the generated code in that EXPR will be evaluated and forced
   to remain live at least until right before the call to
   guality_check, although not necessarily after the call.  */

#define GUALCHKXPR(expr) \
  GUALCHKXPRVAL (#expr, (long long)(expr), 1)

/* Check that a debugger knows that EXPR evaluates to the run-time
   value of EXPR.  Unknown values are marked as errors, because the
   value of EXPR is forced to be available right after the call, for a
   range of at least one instruction.  This will affect the generated
   code, in that EXPR *will* be evaluated both before and after the
   call to guality_check.  */

#define GUALCHKFLA(expr) do {   \
GUALCHKXPRVAL (#expr, (long long)(expr), 0);\
guality_forced_live = (long long)(expr);\
  } while (0)

/* GUALCHK is the simplest way to assert that debug information for an
   expression matches its run-time value.  Whether to force the
   expression live after the call, so as to flag incompleteness
   errors, can be disabled by defining DONT_FORCE_LIVE_AFTER.  */

#ifndef DONT_FORCE_LIVE_AFTER
#define GUALCHK(var) GUALCHKFLA(var)
#else
#define GUALCHK(var) GUALCHKXPR(var)
#endif

/* The program that GDB is going to be told to attach to.  */

static char *guality_program_name;

/* The pid of the process it should attach to, as a string.  */

char guality_pid_str[30];

/* The name of the GDB program.  This is gdb by default, but it can be
   overridden by setting the GUALITY_GDB environment variable.  */

static const char *gu

Re: gcc will become the best optimizing x86 compiler

[Gerald Pfeifer]

On Mon, 28 Jul 2008, Dennis Clarke wrote:
> hold on .. on the NEWS page I see ... okay .. how very user friendly.
> Sort of the thing one would put on the project homepage I would think.

See how user friendly we in GCC-land are in comparison? ;-)

Gerald

Re: frameworklet to assess the quality of debug information

[Alexandre Oliva]

On Jul 28, 2008, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> Thoughts, comments, suggestions, tomatoes, eggs? :-)

>Contributed by Alexandre Oliva <[EMAIL PROTECTED]>.

 

Heh.  So now you know I copied the header from some other file :-)

Fixed, thanks Dodji for pointing it out.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
FSFLA Board Member   ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}

Re: gcc emit wrong symbols in multiple inheritance case

[Bo Yang]

>When I am trying to build Mozilla with gcc-mingw, I came across
> the linkage error of undefined symbols in multiple inheritance case.
> And I have made a simple test case to reproduce the problem. But the
> test case is still very complex, I think. So, I came down to find the
> what are the real problems. And now, I think I have, so I just
> describe what I found here:
>
> For a class hierarchy :
>
> class SuperSuperBase {
> public:
>SuperSuperBase();
>~SuperSuperBase();
>
>virtual void __attribute__((__stdcall__)) funcSSB() = 0;
> };
>
> class SuperBase : public SuperSuperBase {
> public:
>SuperBase();
>~SuperBase();
>
>virtual void __attribute__((__stdcall__)) funcSB() = 0;
> };
>
> class Base : public SuperBase {
> public:
>Base();
>~Base();
>
>virtual void __attribute__((__stdcall__)) funcB() = 0;
> };
>
> class ChildA: public Base {
> public:
>ChildA();
>~ChildA();
>
>virtual void __attribute__((__stdcall__)) funcCA() = 0;
> };
>
> class ChildB: public SuperBase {
> public:
>ChildB();
>~ChildB();
>
>virtual void __attribute__((__stdcall__)) funcCB() = 0;
> };
>
> class DLL Child :   public  ChildA,
> public  ChildB {
> public:
>Child();
>~Child();
>
>virtual void __attribute__((__stdcall__)) funcSSB();
>virtual void __attribute__((__stdcall__)) funcSB();
>virtual void __attribute__((__stdcall__)) funcB();
>virtual void __attribute__((__stdcall__)) funcCB();
>virtual void __attribute__((__stdcall__)) funcCA();
> };
>
> I make the Child in a DLL and then I import it from the DLL to build a
> test application. But I failed with the undefined symbols of
> "funcSSB,funcSB,funcCB".
> And the errors occurs when I build with gcc 4.3.0 but not with gcc
> 3.4.2. So, I use i686-mingw32-nm to dump the object file which
> contains the definition of the Child class. And for the three
> undefined functions, the two compiler output different symbols,
> Gcc 3.4.2:
> U __ZTVN10__cxxabiv117__class_type_infoE
> U __ZTVN10__cxxabiv120__si_class_type_infoE
> U __ZTVN10__cxxabiv121__vmi_class_type_infoE
>  T [EMAIL PROTECTED]
>  T [EMAIL PROTECTED]
>  T [EMAIL PROTECTED]
>
> Gcc 4.3.0:
> U __ZTVN10__cxxabiv117__class_type_infoE
> U __ZTVN10__cxxabiv120__si_class_type_infoE
> U __ZTVN10__cxxabiv121__vmi_class_type_infoE
> 0306 T __ZThn4_N5Child6funcCBEv
> U [EMAIL PROTECTED]
> 02d7 T __ZThn4_N5Child6funcSBEv
> U [EMAIL PROTECTED]
> 02c8 T __ZThn4_N5Child7funcSSBEv
> U [EMAIL PROTECTED]
>
> I think the difference here is the key point of the linkage error.
> Could anybody help to give some more insight here? Any advice will be
> appreciated very much!

Could anybody give some advice on this? Thanks!

Regards!
Bo

Re: frameworklet to assess the quality of debug information

[Joseph S. Myers]

On Mon, 28 Jul 2008, Alexandre Oliva wrote:

> Here's my first cut at trying to tell how well or how bad we perform
> in terms of debug info, that can be dropped into the GCC run-time test
> infrastructure and used by means of #include in new tests that add
> GUALCHK* annotations (or with separate compilation, if some stuff is
> moved into a separate header).
> 
> Thoughts, comments, suggestions, tomatoes, eggs? :-)

For the GCC testsuite parts of this will of course need to be written in 
Tcl to use the DejaGnu interfaces to execute both the debugger (on a 
possibly remote host) and the test program (on a possibly remote, 
simulator, etc. target), rather than fork/exec.  (For experimenting with 
different approaches, assessing the current state of the compiler, etc., 
this isn't needed so much.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: frameworklet to assess the quality of debug information

[Ian Lance Taylor]

Alexandre Oliva <[EMAIL PROTECTED]> writes:

> Here's my first cut at trying to tell how well or how bad we perform
> in terms of debug info, that can be dropped into the GCC run-time test
> infrastructure and used by means of #include in new tests that add
> GUALCHK* annotations (or with separate compilation, if some stuff is
> moved into a separate header).
>
> Thoughts, comments, suggestions, tomatoes, eggs? :-)

It's an interesting approach.  Have you considered an approach more
like Dejagnu's dg support?  It would be harder to write tests, but
would permit testing debugging info less invasively.

int
main (int argc, char *argv[])
{
  int i = argc+1;
  int j = argc-2;
  int k = 5;

  /* { gualchk argc  1 } */
  /* { gualchk i 2 } */
  /* { gualchk j -1 }  */
}

Ian

Re: gcc emit wrong symbols in multiple inheritance case

[Ian Lance Taylor]

"Bo Yang" <[EMAIL PROTECTED]> writes:

> Could anybody give some advice on this? Thanks!

The mailing list gcc@gcc.gnu.org is for gcc developers, who mostly do
not use cygwin.  Try asking on [EMAIL PROTECTED] and/or
[EMAIL PROTECTED]

Ian

Re: GCC trunk frozen for the tuples merge

[Ben Elliston]

> The merge is done and the trunk is open again under the usual
> stage1 rules.

Don't forget to update svn.html. ;-)

Cheers, Ben

Re: gcc will become the best optimizing x86 compiler

[Agner Fog]

Michael Matz wrote:
You must be doing something wrong.  If the compiler decides to inline the 
string ops it either knows the size or you told it to do it anyway 
(-minline-all-stringops or -minline-stringops-dynamically).  In both cases 
will it use wider than byte moves when possible.
  
g++ (v. 4.2.3) without any options converts memcpy with unknown size to  
rep movsb

g++ with option -fno-builtin calls memcpy in libc

The rep movs, stos, scas, cmps instructions are slower than function 
calls except in rare cases. The compiler should never use the string 
instructions. It is OK to use mov instructions if the size is known, but 
not string instructions.

Re: gcc will become the best optimizing x86 compiler

[Agner Fog]

Gerald Pfeifer wrote:

See how user friendly we in GCC-land are in comparison? ;-)
  
Since there is no libc mailing list, I thought that the gcc list is the 
place to contact the maintainers of libc. Am I on the wrong list? Or are 
there no maintainers of libc?

Re: gcc will become the best optimizing x86 compiler

[Ben Elliston]

> Since there is no libc mailing list, I thought that the gcc list is the 
> place to contact the maintainers of libc. Am I on the wrong list? Or are 
> there no maintainers of libc?

See:
  http://sources.redhat.com/glibc/

You want the libc-alpha list, I think.

Cheers, Ben

Re: lto gimple types and debug info

[Paolo Bonzini]

Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the 
same value when debugging optimized code as when debugging unoptimized 
code, even if the compiler has optimized X away to an empty structure!


I disagree.  sizeof(X) in the code will return a value as small as 
possible in that case (so that malloc-ing an array of structures) does 
not waste memory, and the debugger should do the same.


Paolo