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
> 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
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?
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.
> The merge is done and the trunk is open again under the usual
> stage1 rules.
Don't forget to update svn.html. ;-)
Cheers, Ben
"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
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
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
>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 r
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, th
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
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 h
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, inc
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.
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
"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
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 availab
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, pleas
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.
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 dire
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 so
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 optimization
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
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 wrot
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.
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
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 gi
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
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 fini
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
... 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.
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)
>>>
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 ret
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
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?
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 m
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 t
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 bas
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,
39 matches
Mail list logo
