97303c c9a007a c9a009c c9a009g
cb1010a cb1010c cb1010d
=== g++ Summary ===
# of expected passes20986
# of unexpected failures4
# of expected failures 150
# of unsupported tests 286
/gnat/obj/gcc/testsuite/g++/../../g++ version 4.5.0
g...@coreland wrote:
> While there aren't *too* many test failures currently, there appears to
> be a problem with the test suite in that it returns a 'failure' exit
> code when the test ends and I'm not sure if this is expected behaviour
> or not.
Yes, it certainly is expected and by-design.
Ok, I've now reached a new milestone - the mshort.h which
redefines all the long names into ZZZ_123 etc is now
automatically generated as part of the build process.
The libiberty and gcc aren't split yet, but I'll probably defer
that to gcc 4, and see if I can simply reproduce what I have
with
On 2009-11-18 11:03:01, Dave Korn wrote:
> g...@coreland wrote:
>
> > While there aren't *too* many test failures currently, there appears to
> > be a problem with the test suite in that it returns a 'failure' exit
> > code when the test ends and I'm not sure if this is expected behaviour
> > or n
> That's slightly worrying. I'm using 'gmake -k check' (GNU make isn't the
> default make on my system) and yet it still fails...
Sure, it "fails" as long as you have failures in the testsuite.
--
Eric Botcazou
On 2009-11-18 12:04:47, Eric Botcazou wrote:
> > That's slightly worrying. I'm using 'gmake -k check' (GNU make isn't the
> > default make on my system) and yet it still fails...
>
> Sure, it "fails" as long as you have failures in the testsuite.
OK, that's fine then.
Is the quoting on "fails" s
Hi,
Due to pressing requirements of our target processor/application, I
am implementing several popular loop pragmas in our private porting.
I've already implemented "unroll" and "ivdep", and am now working
on "loop_count" to give GCC hints about number of iterations.
The problem I am now facin
> Is the quoting on "fails" significant?
Maybe. :-) Returning a failure code when there are failures is as expected.
--
Eric Botcazou
Hi C++ folks,
While debugging a patch, I stumbled across some kind of synthetic cdtor that
crashes debug_tree():
> Breakpoint 5, i386_pe_encode_section_info (decl=0x7f9b3e00, rtl=0x7f902220,
> first=1) at /gnu/gcc/gcc/gcc/config/i386/winnt.c:252
> 252 default_encode_section_info
On 05/29/2009 03:11 PM, Mark Wielaard wrote:
(Resent, now actually subscribed to the list from the correct address)
On Fri, 2009-05-29 at 14:28 +0530, M. Mohan Kumar wrote:
That's all true in the abstract, but modern gcc has been known to
abscond with variable location data even for values that
"M. Mohan Kumar" writes:
> Are VTA patches part of mainline gcc now?
Yes.
Ian
On Sun, Nov 15, 2009 at 4:32 PM, Bernie Innocenti wrote:
> I repacked our (un)official git mirror (http://gcc.gnu.org/git) with
>
> git repack -a -d -f --window=100 --depth=100 --window-memory=2g
>
> The pack is now 600MB, which is a bit scary, but still manageable.
> Mysteriously, cloning this r
On 11/17/2009 04:52 PM, Mark Mitchell wrote:
Joe Buck wrote:
I think that the cleanest way is to suppress the warning for structs
with one member
And recursively?
So that:
struct A { int i; };
struct B { struct A a };
struct C { struct B b };
struct C c = { 1 };
does not trigge
What do people think about making install-plugin not only install
headers to build new plugins, but also install all plugins that
have been contributed up to the code freeze for the release.
First, it would make testing the plugin interface and the plugins easier.
Second, if the version of a plu
2009/11/18 Joern Rennecke :
> What do people think about making install-plugin not only install
> headers to build new plugins, but also install all plugins that
> have been contributed up to the code freeze for the release.
>
> First, it would make testing the plugin interface and the plugins easi
On Wed, Nov 18, 2009 at 09:05, Joern Rennecke wrote:
> What do people think about making install-plugin not only install
> headers to build new plugins, but also install all plugins that
> have been contributed up to the code freeze for the release.
I agree, but we have no plugins included with t
El Wed, 18-11-2009 a las 07:13 -0800, H.J. Lu escribió:
> On Sun, Nov 15, 2009 at 4:32 PM, Bernie Innocenti wrote:
> > I repacked our (un)official git mirror (http://gcc.gnu.org/git) with
> >
> > git repack -a -d -f --window=100 --depth=100 --window-memory=2g
> >
> > The pack is now 600MB, which
I've recently looked into what it takes to support decimal float on
additional platforms (like Solaris, IRIX, and Tru64 UNIX in my case).
I've found no documentation, and while I could figure out some things
myself, I'd like to get some advice before continuing down that road.
I found that --enabl
Diego Novillo wrote:
On Wed, Nov 18, 2009 at 09:05, Joern Rennecke wrote:
What do people think about making install-plugin not only install
headers to build new plugins, but also install all plugins that
have been contributed up to the code freeze for the release.
I agree, but we have no plug
On Wed, Nov 18, 2009 at 10:09 AM, Bernie Innocenti wrote:
> El Wed, 18-11-2009 a las 07:13 -0800, H.J. Lu escribió:
>> On Sun, Nov 15, 2009 at 4:32 PM, Bernie Innocenti wrote:
>> > I repacked our (un)official git mirror (http://gcc.gnu.org/git) with
>> >
>> > git repack -a -d -f --window=100 --d
Hi,
and first thanks everyone for the constructive feedbacks!
>> And recursively?
>>
>> So that:
>>
>> struct A { int i; };
>> struct B { struct A a };
>> struct C { struct B b };
>> struct C c = { 1 };
>>
>> does not trigger the warning?
>
> Sure.
>
>>
>> What if struct B is now:
>>
>> struct B {
Quoting Basile STARYNKEVITCH :
The interesting question is: do we have an installed plugins
directory? (We might have already discussed that, I forgot
the details and the context, probably more than a year ago). I wish
we had one:
At the moment we have a directory for plugin header files,
On Wed, 2009-11-18 at 19:19 +0100, Rainer Orth wrote:
> I've recently looked into what it takes to support decimal float on
> additional platforms (like Solaris, IRIX, and Tru64 UNIX in my case).
> I've found no documentation, and while I could figure out some things
> myself, I'd like to get some
On Wed, 2009-11-18 at 10:38 -0800, H.J. Lu wrote:
> If nested subdirs in banches/ aren't handled properly, shouldn't we
> avoid putting them in git mirror?
You're right. I killed the bogus branches and asked the git folks for
advice.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar La
On Wed, 18 Nov 2009, Rainer Orth wrote:
> be added on legacy platforms like IRIX and Tru64 UNIX, and even on
> Solaris probably won't show up until DFP is fully standardized.
I'd have expected the Solaris maintainers to care more about whether
Solaris customers are asking for DFP support, than a
On 11/18/2009 10:43 AM, Paolo Carlini wrote:
struct S5 { int s[3]; };
struct S5 { struct S5 a; int b; };
struct S5 s34 = { { 1, 1, 1 }, 1 };
Please also test
struct S1 { int s[3], t };
struct S2 { struct S1 a; };
struct S3 { struct S1 a; int i; };
struct S2 s1 = { 1, 1, 1, 1 }; // wa
On Fri, 6 Nov 2009, Dave Korn wrote:
>> I wonder if there would be an interest for a C++ template / compile
>> time ray tracer as a heavy test for
>>
>> * templates in general
>> * the type system
>> * regression and conformance testing
> How big is it? It might be suitable to go in the contrib/
Hi,
and thanks for your further guidance...
On 11/18/2009 09:26 PM, Richard Henderson wrote:
> struct S1 { int s[3], t; };
> struct S2 { struct S1 a; };
>
> struct S2 s2 = { { 1, 1, 1 }, 1 };// no warn
This case looks somewhat special to me: my draft warns, unchanged
behavior. But note that i
I'm getting this build failure with latest trunk, as of the composing of
this email:
../gcc-trunk/configure --prefix=/home/matt --enable-stage1-checking=all
--enable-bootstrap --enable-lto
--enable-languages=c,c++../gcc-trunk/configure --prefix=/home/matt
--enable-stage1-checking=all --enable
Is it possible to disable the heuristic inline function logic? I would
like the following behaviour:
* static inline functions are always inlined
* non-static functions are never inlined
* static functions that are called once are inlined
* static functions that are called more than once are not i
2009/11/18 Shaun Jackman :
> Is it possible to disable the heuristic inline function logic? I would
> like the following behaviour:
>
> * static inline functions are always inlined
> * non-static functions are never inlined
> * static functions that are called once are inlined
> * static functions
On 11/19/2009 02:21 AM, Shaun Jackman wrote:
> I haven't done a lot of testing, but
> -Os -fno-inline-small-functions
> seems to accomplish this.
>
Note that this issue really doesn't qualify for gcc, gcc-help is more
suited.
Anyway, there are some attributes available, which probably you can f
'Lo.
Is anyone interested in committing the two extremely minor patches to enable
proper support for FreeBSD x86_64?
Support for Debian/kFreeBSD x86_64 already exists in GCC, this Makefile patch
just enables support for "pure" FreeBSD (same kernel, different userland):
http://gcc.coreland.ath.cx
On Nov 18, 2009, Bernie Innocenti wrote:
> I guess git-svn does not cope automatically with nested subdirs in
> banches/.
That's correct. (save for b*r*anches ;-)
> One could manually select them by passing multiple --branches options.
Yup. Here's the configuration I'm using to build a git r
On Thu, 2009-11-19 at 03:11 -0200, Alexandre Oliva wrote:
> Yup. Here's the configuration I'm using to build a git repo with all
> branches, tags, and also retaining the ability to check out any
> directory containing multiple tags, branches, and even the entire SVN
> tree (look for dirs).
>
> [s
35 matches
Mail list logo
