Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
Hello. I'm now doing regular builds/tests from SVN of GCC, G++ and GNAT on FreeBSD x86_64 and publishing the build logs at: http://gcc.coreland.ath.cx I hope to produce builds weekly. Unfortunately I can't publish the actual binaries due to space/bandwidth restrictions. 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. Highlights of the first build (SVN r154276): === acats Summary === # of expected passes2290 # of unexpected failures31 *** FAILURES: c52103x c52104x c52104y c761007 c85005c c85006c c910002 c93004b c93004c c93004d c93005a c93005b c94001c c94002b c94002e c94002f c94002g c94007a c94007b c94008c c94008d c94020a c95040c c97203c c97303c 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 20091118 (experimental) (GCC) === gcc Summary === # of expected passes57515 # of unexpected failures42 # of unexpected successes 4 # of expected failures 169 # of unsupported tests 1511 /gnat/obj/gcc/xgcc version 4.5.0 20091118 (experimental) (GCC) === gnat Summary === # of expected passes739 # of unexpected failures4 # of expected failures 5 === libgomp Summary === # of expected passes1001 # of unexpected failures2 # of unsupported tests 2 === libmudflap Summary === # of expected passes1884 # of unexpected failures10 === libstdc++ Summary === # of expected passes6337 # of unexpected failures2 # of expected failures 89 # of unsupported tests 389 Regards, M
Re: Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
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. Generally people give make the "-k" option when running any of various the check targets. cheers, DaveK
Re: i370 port - constructing compile script
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 3.4.6 first. But there are some things I want to change in the 3.4.6 before starting that. There are some files that are being automatically generated as part of the build process, which I would like to stop. gcov-iov creates a gcov-iov.h which has a version number which changes when I change MVS versions. So I am thinking of updating gcov-iov.c so that when the target is MVS, it generates a more fixed format. Or maybe as part of the build process I can just put in a #define GCOV_VERSION 0 Not sure if it's actually being used for anything in my environment. gengtype-yacc.c & .h gets created with my new version of bison. I just want to use the one that came with 3.4.6 instead of having it regenerated. Do I need to hide my bison to stop that from happening? configargs.h I will just overwrite with something simple as part of the build process. gencheck.h is being generated as an empty file, which doesn't work well on some environments. I want it to at least have a comment saying "/* empty file */". I can put that in as part of the build script too. Basically I'm looking for consistent source that won't change with my build environment. The raw "MVS source" can then be taken to another environment to be compiled. Thanks. Paul.
Re: Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
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 not. > > Yes, it certainly is expected and by-design. Generally people give make the > "-k" option when running any of various the check targets. 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... M
Re: Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
> 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
Re: Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
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" significant? Regards, M
Loop pragmas dilemma
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 facing is that GCC has many loop optimizations in both tree and rtl levels that change loop property. For example, loop versioning by unrolling called by predom pass and loop fissions by graphite passes. This makes loop_count simply wrong for transformed loop(s). What is best strategy? Updating loop count pragma to track changed loops, or disable loop optimizations altogether in presence of loop pragma? To less extent, loop optimizations also affect other loop pragmas. For example, I have to disable cunroll pass in presence of #pragma unroll because it is confusing for user. Does anyone know how other compilers, e.g., icc, handle such issues? Thanks for any input, Bingfeng Mei Broadcom UK
Re: Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
> Is the quoting on "fails" significant? Maybe. :-) Returning a failure code when there are failures is as expected. -- Eric Botcazou
C++ comp_cdtor FUNCTION_DECL tree nodes with DECL_LANG_SPECIFIC but no DECL_CONTEXT: valid or not?
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 (decl, rtl, first);
> (gdb) call debug_tree (decl)
> type type align 8 symtab 0 alias set -1 canonical type 0x7fdc08f0
> pointer_to_this >
> QI
> size
> unit size
> align 8 symtab 0 alias set -1 canonical type 0x7f89ca50 method
> basetype
>
> arg-types
> chain >>
> pointer_to_this >
> addressable asm_written used nothrow public static in_system_header
> autoinli
> ne decl_3 decl_5 QI file
> /gnu/gcc/install-libstdc-latest/opt/gcc-tools/bin/../li
> b/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/basic_string.h line 258 col 7
> align
> 16 initial abstract_origin _Alloc_h
> ider>
> arguments type _Alloc_hider>
>
> readonly unsigned SI
> size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x7fa2a010>
> readonly used unsigned SI file
> /gnu/gcc/install-libstdc-latest/opt/gcc-t
> ools/bin/../lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/basic_string.h line
> 50
> 3 col 54 size unit size
> align 32 context
> abstract_origin
>
> (mem/f/c/i:SI (reg/f:SI 16 argp) [0 this+0 S4 A32]) arg-type
> pe 0x7fa2a010>
> incoming-rtl (mem/f/c/i:SI (reg/f:SI 16 argp) [0 this+0 S4 A32])>
> result
> ignored VOID file
> /gnu/gcc/install-libstdc-latest/opt/gcc-tools/bin/../l
> ib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/basic_string.h line 258 col 7
> align 8 context >
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x004cb6d2 in dump_function_name (t=0x7f9b3e00, flags=116)
> at /gnu/gcc/gcc/gcc/cp/error.c:1433
> 1433 if (LAMBDA_TYPE_P (DECL_CONTEXT (t)))
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on"
> Evaluation of the expression containing the function (debug_tree) will be
> abando
> ned.
> (gdb)
The crash happens when calling dump_function_name in cp/error.c:
/* Handle the function name for a FUNCTION_DECL node, grokking operators
and destructors properly. */
static void
dump_function_name (tree t, int flags)
{
tree name = DECL_NAME (t);
/* We can get here with a decl that was synthesized by language-
independent machinery (e.g. coverage.c) in which case it won't
have a lang_specific structure attached and DECL_CONSTRUCTOR_P
will crash. In this case it is safe just to print out the
literal name. */
if (!DECL_LANG_SPECIFIC (t))
{
pp_cxx_tree_identifier (cxx_pp, name);
return;
}
if (TREE_CODE (t) == TEMPLATE_DECL)
t = DECL_TEMPLATE_RESULT (t);
/* Don't let the user see __comp_ctor et al. */
if (DECL_CONSTRUCTOR_P (t)
|| DECL_DESTRUCTOR_P (t))
{
if (LAMBDA_TYPE_P (DECL_CONTEXT (t)))
name = get_identifier ("");
else
name = constructor_name (DECL_CONTEXT (t));
}
... here. The node in question does have a lang-specific entry, but the
context is NULL, crashing the call to LAMBDA_TYPE_P.
I reproduced it on an unpatched build of r.154010 just to make sure my patch
wasn't the cause.
Is it valid for the context to be NULL here? The testcase that provoked it
is simple:
> #include
> extern void bar (std::string x);
>
> int main (int argc, const char **argv)
> {
>
> std::string foo = "abc";
> foo += argv[1];
> bar (foo);
> }
... so I guess I can see why we're not in any class or namespace context here;
is the problem perhaps that the cdtor in question here is a template
instantiation, and we need to look at the template decl to find the context
rather than the instantiation decl? I see an entry in cp/ChangeLog-2000 that
says "* error.c (dump_function_name): Don't let the user see __comp_ctor" but
I'm not sure what the user should be seeing instead.
cheers,
DaveK
Re: [Dwarf-Discuss] Does gcc optimization impacts retrieving Dwarf information?
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 are live/recomputable. This is the main reason why the VTA (and debuglocus and other) gcc projects are under way -- to represent the maximum possible conceptual data, despite -O2 etc. Frank, Will VTA/debuglocus have the dwarf compatibility (i.e. it does not need modification to existing applications using libdwarf APIs)? When can we expect this features (VTA/debuglocus) integrated into mainline gcc? Yes, it will output (hopefully better/more complete) dwarf information. I don't know the schedule details of when this will land in gcc mainline. But the ideas behind how to improve the tracking of debug locations for variables in gcc can be found in this paper from Alexandre Olivia: http://www.lsd.ic.unicamp.br/~oliva/papers/vta/slides.pdf And on this GCC wiki page: http://gcc.gnu.org/wiki/Var_Tracking_Assignments Hi, In one of the dwarf mail threads it is mentioned that VTA is ready for integration into gcc, but its waiting for the acceptance from the maintainers. Are VTA patches part of mainline gcc now? If not, where could we get the VTA patches? Regards, M. Mohan Kumar. DebugLocus is an alternative idea on an implementation to improve tracking debug information from Andrew MacLeod described here: http://gcc.gnu.org/wiki/AndrewMacLeod/debuglocus Cheers, Mark ___ Dwarf-Discuss mailing list dwarf-disc...@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Does gcc optimization impacts retrieving Dwarf information?
"M. Mohan Kumar" writes: > Are VTA patches part of mainline gcc now? Yes. Ian
Re: git mirror repacked, new branches
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 repo yields a smaller pack of just 519MB, > which still contains all the branches. It was probably caused by entries > in the reflog, which I have now disabled. > > As an additional bonus, I've added refs for all the current branches tom > make them visible in gitweb and easier to clone. > Most of vendor branches are wrong. For example, there are many branches under branches/redhat. But I only see one redhat branch in git. BTW, I can't pull new changes from the new master into my local git branches which are based on the old master. -- H.J.
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
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 trigger the warning?
Sure.
What if struct B is now:
struct B { struct A a; int j; };
and I write:
struct C c = { 1, 2 };
Then warn.
I don't mind changing the behavior to not warn so long as all of the
initializers missing braces apply to the same aggregate. So in the
former case they all apply to struct A, whereas in the later case they
do not.
r~
[plugins-ici-cloning-instrumentation] install-plugin Makefile target
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 plugin available with the release is good enough for the needs of a user, (s)he can try out without having to install - or having to have installed - the plugins separately. Third, when someone uses an experimental plugin for a while and then upgrades some time later to a newer gcc release, it is useful when an updated plugin version that works with the new gcc release comes with the new gcc distribution.
Re: [plugins-ici-cloning-instrumentation] install-plugin Makefile target
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 easier. > > Second, if the version of a plugin available with the release is good enough > for the needs of a user, (s)he can try out without having to install - or > having to have installed - the plugins separately. > > Third, when someone uses an experimental plugin for a while and then > upgrades > some time later to a newer gcc release, it is useful when an updated plugin > version that works with the new gcc release comes with the new gcc > distribution. > Sound like a good idea, but I don't think we have agreed about including plugins with gcc. I would like it, but it is not the consensus. Cheers, -- Rafael Ávila de Espíndola
Re: [plugins-ici-cloning-instrumentation] install-plugin Makefile target
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 the release. I think it would be beneficial to include a tutorial plugin somewhere that shows the basics. I have no opinion on where in the tree. Diego.
Re: git mirror repacked, new branches
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 is a bit scary, but still manageable. > > Mysteriously, cloning this repo yields a smaller pack of just 519MB, > > which still contains all the branches. It was probably caused by entries > > in the reflog, which I have now disabled. > > > > As an additional bonus, I've added refs for all the current branches tom > > make them visible in gitweb and easier to clone. > > Most of vendor branches are wrong. For example, there are many branches > under branches/redhat. But I only see one redhat branch in git. I guess git-svn does not cope automatically with nested subdirs in banches/. One could manually select them by passing multiple --branches options. For our case, the man page shows how to map those branches to separate namespaces: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* Properly handling vendor branches would be a requisite step for a real migration to git. For now, I'd rather be lazy and delay this work until someone asks for it. > BTW, I can't pull new changes from the new master into my local git branches > which are based on the old master. This is unexpected. Repacking doesn't change any SHA1, and I haven't touched any of the existing branches. What error do you get from pull? If you have access to the git tree on sourceware, would you mind investigating this issue yourself since you can easily reproduce it? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
Supporting decimal float on additional platforms
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 --enable-decimal-float alone is not enough. One at least needs to add config/t-dfprules to config.gcc, too. In addition, the platform _scalar_mode_supported_p function needs to be augmented accordingly. (I haven't tried this yet; it's just from code inspection.) Even if this works, I now think this won't be enough and probably not even remotely useful (if only to pass parts of the testsuite) without libc support for the new *printf/*scanf formats, which certainly won't be added on legacy platforms like IRIX and Tru64 UNIX, and even on Solaris probably won't show up until DFP is fully standardized. Comments? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [plugins-ici-cloning-instrumentation] install-plugin Makefile target
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 plugins included with the release. I think it
would be beneficial to include a tutorial plugin somewhere that shows
the basics. I have no opinion on where in the tree.
Diego, are you speaking of the GCC source tree, the GCC build tree, the GCC
installation tree?
We could simply adapt a plugin from our testsuite, and install it...
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:
We might even consider that invoking [sorry to be so selfish and take MELT as a
plugin example]
gcc-4.5 -fplugin=melt
doing the same as
gcc-4.5 -fplugin=$(gcc-trunk --print-file-name=plugin)/libexec/melt.so
That is, a plugin only specified with XXX [only letters or digits or underscores, no dots, so no .so extensions, no
slashes] being searched in some well known directory like
/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin/libexec/ . If I recall correctly, most other
pluginable software have their "standard plugin directory".
I would be delighted by having in practice short -fplugin=XXX program argument to GCC. In my understanding, the current
one is almost always long in practice [because in practice the plugin directory should depend of the GCC version].
The issues are:
* do we agree that having a well defined directory to contain some installed
plugins is desirable?
* what is that standard plugins directory?
And then, we have to implement & document that.
In the current state of the trunk, it seems that plugins are the only point where environment variables matter, and that
environment variable is LD_LIBRARY_PATH ... (because dlopen mandates that behavior).
BTW, I think that both MELT & ICI are dlopen-ing their own shared objects (in MELT I call these modules), and that MELT
(& probably ICI) have some mechanism for some standard paths for these.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: git mirror repacked, new branches
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 --depth=100 --window-memory=2g >> > >> > The pack is now 600MB, which is a bit scary, but still manageable. >> > Mysteriously, cloning this repo yields a smaller pack of just 519MB, >> > which still contains all the branches. It was probably caused by entries >> > in the reflog, which I have now disabled. >> > >> > As an additional bonus, I've added refs for all the current branches tom >> > make them visible in gitweb and easier to clone. >> >> Most of vendor branches are wrong. For example, there are many branches >> under branches/redhat. But I only see one redhat branch in git. > > I guess git-svn does not cope automatically with nested subdirs in > banches/. If nested subdirs in banches/ aren't handled properly, shouldn't we avoid putting them in git mirror? > One could manually select them by passing multiple --branches options. > For our case, the man page shows how to map those branches to separate > namespaces: > > branches = stable/*:refs/remotes/svn/stable/* > branches = debug/*:refs/remotes/svn/debug/* > > > Properly handling vendor branches would be a requisite step for a real > migration to git. For now, I'd rather be lazy and delay this work until > someone asks for it. > > >> BTW, I can't pull new changes from the new master into my local git branches >> which are based on the old master. > > This is unexpected. Repacking doesn't change any SHA1, and I haven't > touched any of the existing branches. What error do you get from pull? > Oops. Pilot error. -- H.J.
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
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 { struct A a; int j; };
>>
>> and I write:
>>
>> struct C c = { 1, 2 };
>
> Then warn.
>
> I don't mind changing the behavior to not warn so long as all of the
> initializers missing braces apply to the same aggregate. So in the
> former case they all apply to struct A, whereas in the later case they
> do not.
I tried quickly drafting the corresponding patch, attached, which
appears to work pretty well (no regressions), please correct me as soon
as possible if I misunderstood. For example, this
struct S { int s[3]; };
struct S s1 = { 1, 1, 1 };
and this
struct S1 { int s[3]; };
struct S2 { struct S1 a; };
struct S2 s22 = { 1, 1, 1 };
and this
struct A { int i; };
struct B { struct A a };
struct C { struct B b };
struct C c = { 1 };
do not warn anymore. Whereas, this
struct S3 { int s[3]; };
struct S4 { struct S3 a; int b; };
struct S4 s23 = { 1, 1, 1 , 1 };
warns, but only about "missing braces around initializer for ‘S3’", not
about "missing braces around initializer for ‘int [3]’", at variance
with mainline. Changed the following way doesn't warn:
struct S5 { int s[3]; };
struct S5 { struct S5 a; int b; };
struct S5 s34 = { { 1, 1, 1 }, 1 };
This
struct A1 { int i; };
struct B1 { struct A1 a; };
struct B1 { struct A1 a; int j; };
struct C1 { struct B1 b; };
struct C1 c2 = { 1, 2 };
likewise only warns about "missing braces around initializer for ‘A1’"
In case, the same kind of change should be implemented in the C
front-end, right?
Thanks,
Paolo.
Index: decl.c
===
--- decl.c (revision 154291)
+++ decl.c (working copy)
@@ -4707,7 +4707,7 @@
constructor_elt *end;
} reshape_iter;
-static tree reshape_init_r (tree, reshape_iter *, bool);
+static tree reshape_init_r (tree, reshape_iter *, bool, bool);
/* FIELD is a FIELD_DECL or NULL. In the former case, the value
returned is the next FIELD_DECL (possibly FIELD itself) that can be
@@ -4765,7 +4765,8 @@
tree elt_init;
check_array_designated_initializer (d->cur);
- elt_init = reshape_init_r (elt_type, d, /*first_initializer_p=*/false);
+ elt_init = reshape_init_r (elt_type, d, /*first_initializer_p=*/false,
+false);
if (elt_init == error_mark_node)
return error_mark_node;
CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (new_init), NULL_TREE,
elt_init);
@@ -4857,7 +4858,7 @@
/* Loop through the initializable fields, gathering initializers. */
while (d->cur != d->end)
{
- tree field_init;
+ tree field_init, nfield;
/* Handle designated initializers, as an extension. */
if (d->cur->index)
@@ -4876,8 +4877,9 @@
if (!field)
break;
+ nfield = next_initializable_field (TREE_CHAIN (field));
field_init = reshape_init_r (TREE_TYPE (field), d,
- /*first_initializer_p=*/false);
+ /*first_initializer_p=*/false, !nfield);
if (field_init == error_mark_node)
return error_mark_node;
@@ -4891,7 +4893,7 @@
if (TREE_CODE (type) == UNION_TYPE)
break;
- field = next_initializable_field (TREE_CHAIN (field));
+ field = nfield;
}
return new_init;
@@ -4904,7 +4906,7 @@
outermost CONSTRUCTOR node. */
static tree
-reshape_init_r (tree type, reshape_iter *d, bool first_initializer_p)
+reshape_init_r (tree type, reshape_iter *d, bool first_initializer_p, bool
no_warn)
{
tree init = d->cur->value;
@@ -5016,8 +5018,9 @@
}
}
- warning (OPT_Wmissing_braces, "missing braces around initializer for
%qT",
- type);
+ if (!no_warn)
+ warning (OPT_Wmissing_braces, "missing braces around initializer "
+"for %qT", type);
}
/* Dispatch to specialized routines. */
@@ -5066,7 +5069,7 @@
d.cur = VEC_index (constructor_elt, v, 0);
d.end = d.cur + VEC_length (constructor_elt, v);
- new_init = reshape_init_r (type, &d, true);
+ new_init = reshape_init_r (type, &d, true, false);
if (new_init == error_mark_node)
return error_mark_node;
Re: [plugins-ici-cloning-instrumentation] install-plugin Makefile target
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, which is a subdirectory of an otherwise empty plugin directory: [amyl...@laria gcc]$ /user/inria/bin/gcc --print-file-name=libgcc.a /user/inria/lib/gcc/i686-pc-linux-gnu/4.5.0/libgcc.a [amyl...@laria gcc]$ /user/inria/bin/gcc --print-file-name=plugin /user/inria/lib/gcc/i686-pc-linux-gnu/4.5.0/plugin [amyl...@laria gcc]$ ls -l `!!` ls -l `/user/inria/bin/gcc --print-file-name=plugin` total 4 drwxrwxr-x. 7 amylaar amylaar 4096 2009-11-18 17:48 include [amyl...@laria gcc]$ /user/inria/bin/gcc --version gcc (GCC) 4.5.0 20091108 (experimental) Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Re: Supporting decimal float on additional platforms
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 advice before continuing down that road. > > I found that --enable-decimal-float alone is not enough. One at least > needs to add config/t-dfprules to config.gcc, too. In addition, the > platform _scalar_mode_supported_p function needs to be augmented > accordingly. (I haven't tried this yet; it's just from code > inspection.) The target ABI needs to define how to handle the decimal32/64/128 data types. The compiler backend needs to implement that ABI for argument passing and function results, and needs to define which registers to use for those types. > Even if this works, I now think this won't be enough and probably not > even remotely useful (if only to pass parts of the testsuite) without > libc support for the new *printf/*scanf formats, which certainly won't > be added on legacy platforms like IRIX and Tru64 UNIX, and even on > Solaris probably won't show up until DFP is fully standardized. Much of the support for decimal floating types is in libraries that are outside the scope of the GCC project. This includes not just I/O but math functions and support for floating-point exceptions and rounding modes. That support is provided by the libdfp project hosted in the EGLIBC repository. libdfp currently supports only GNU/Linux targets, but that could be changed. Janis
Re: git mirror repacked, new branches
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 Labs - http://sugarlabs.org/
Re: Supporting decimal float on additional platforms
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 about whether it is an ISO/IEC Technical Report Type 2 (as at present - TR 24732:2009 published 2009-01-05) or an International Standard. As Janis says, the psABI needs to be aware of decimal floating point, so if there is any group or community for a particular target concerned with its ABI for interoperability between multiple implementations, you should work with them on establishing the ABI for decimal floating point for that target. Much the same applies if anyone wishes to add fixed point (TR 18037) support for more targets. -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
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 }; // warn
struct S2 s2 = { { 1, 1, 1 }, 1 }; // no warn
struct S3 s3 = { { 1, 1, 1, 1 }, 1 }; // warn
I didn't look at the code yet, but the test cases that you do have look
good, including the change in the aggregate you choose to reference in
the warning.
In case, the same kind of change should be implemented in the C
front-end, right?
Yes.
r~
Re: New g++ template stress/regression test?
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/ dir, we already > keep a copy of the paranoia FP tests in there, so your template package and > maybe a testscript to run it and record stats might make a nice little > addition in the same spirit. I don't think that's a good idea. Rather, why not add this to http://gcc.gnu.org/testing/ (look for "Build and test guide" there) if it really is a useful test? Gerald
Re: RFC: PR 25137: moving -Wmissing-braces to -Wextra?
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 in this case we also issue an hard error "too
many initializers for ‘S2’", with and without the patch, are you sure
it's important to clean-up somewhat the diagnostics in this case? Or you
really meant something slightly different?
Paolo.
build failure bootstrapping trunk on Ubuntu 9.10
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-bootstrap --enable-lto --enable-languages=c,c++ make -j5 . . . /home/matt/src/gcc-obj/./prev-gcc/xgcc -B/home/matt/src/gcc-obj/./prev-gcc/ -B/home/matt/x86_64-unknown-linux-gnu/bin/ -B/home/matt/x86_64-unknown-linux-gnu/bin/ -B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem /home/matt/x86_64-unknown-linux-gnu/include -isystem /home/matt/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_PPL_BACKEND -I/usr/include/libelf ../../gcc-trunk/gcc/ira-lives.c -o ira-lives.o cc1: warnings being treated as errors ../../gcc-trunk/gcc/ira-lives.c: In function ira_implicitly_set_insn_hard_regs: ../../gcc-trunk/gcc/ira-lives.c:748:13: error: regno may be used uninitialized in this function It looks like ira-lives.c:763 has some ambiguous parenthesizing that may be causing the warning that is failing the build). Note that the warning doesn't happen on a similar piece of code on line 830 in the same file. I've been fighting with the configure process for a few days and finally got past that to this issue. So, any help is greatly appreciated :) Thanks! -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt
Disabling the heuristic inliner
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 inlined I'm using -Os, and I'm trying to find the right combination of -f switches to enable this behaviour. Thanks, Shaun
Re: Disabling the heuristic inliner
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 that are called more than once are not inlined > > I'm using -Os, and I'm trying to find the right combination of -f > switches to enable this behaviour. > > Thanks, > Shaun I haven't done a lot of testing, but -Os -fno-inline-small-functions seems to accomplish this. Cheers, Shaun
Re: Disabling the heuristic inliner
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 find useful, like always_inline, see the docs for details. Paolo.
Re: Build logs of GCC, G++ and GNAT on FreeBSD x86_64 now available
'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/r154285_2009-11-18_103532/patch-gcc-ada-gcc-interface-Makefile.in This one just allows GCC to build on stricter settings (adds two missing ATTRIBUTE_UNUSED macros and fixes an 'old style' function definition): http://gcc.coreland.ath.cx/r154285_2009-11-18_103532/patch-gcc-ada-init.c.diff The latest build was made with Fortran support enabled as well: http://gcc.coreland.ath.cx/r154285_2009-11-18_103532/ I've been unable to get the contrib/test_summary script to work, unfortunately. Regards, M
Re: git mirror repacked, new branches
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 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). [svn-remote "svn"] rewriteRoot = svn+ssh://gcc.gnu.org/svn/gcc # url = svn+ssh://aol...@gcc.gnu.org./svn/gcc url = file:///l/tmp/build/gcc/gccrepo fetch = trunk:refs/remotes/trunk branches = branches/ARM/*:refs/remotes/branches/ARM/* fetch = branches/ARM:refs/remotes/dirs/branches/ARM branches = branches/apple/*:refs/remotes/branches/apple/* fetch = branches/apple:refs/remotes/dirs/branches/apple branches = branches/csl/*:refs/remotes/branches/csl/* fetch = branches/csl:refs/remotes/dirs/branches/csl branches = branches/dead/*:refs/remotes/branches/dead/* fetch = branches/dead:refs/remotes/dirs/branches/dead branches = branches/gcj/*:refs/remotes/branches/gcj/* fetch = branches/gcj:refs/remotes/dirs/branches/gcj branches = branches/ibm/*:refs/remotes/branches/ibm/* fetch = branches/ibm:refs/remotes/dirs/branches/ibm branches = branches/ix86/*:refs/remotes/branches/ix86/* fetch = branches/ix86:refs/remotes/dirs/branches/ix86 branches = branches/redhat/*:refs/remotes/branches/redhat/* fetch = branches/redhat:refs/remotes/dirs/branches/redhat branches = branches/st/*:refs/remotes/branches/st/* fetch = branches/st:refs/remotes/dirs/branches/st branches = branches/suse/*:refs/remotes/branches/suse/* fetch = branches/suse:refs/remotes/dirs/branches/suse branches = branches/ubuntu/*:refs/remotes/barnches/ubuntu/* fetch = branches/ubuntu:refs/remotes/dirs/branches/ubuntu branches = branches/*:refs/remotes/branches/* fetch = branches:refs/remotes/dirs/branches/root tags = tags/apple/*:refs/remotes/tags/apple/* fetch = tags/apple:refs/remotes/tags/dirs/apple tags = tags/csl/arm/*:refs/remotes/tags/csl/arm/* fetch = tags/csl/arm:refs/remotes/tags/dirs/csl/arm tags = tags/csl/coldfire/*:refs/remotes/tags/csl/coldfire/* fetch = tags/csl/coldfire:refs/remotes/tags/dirs/csl/coldfire tags = tags/csl/morpho/*:refs/remotes/tags/csl/morpho/* fetch = tags/csl/morpho:refs/remotes/tags/dirs/csl/morpho tags = tags/csl/renesas/*:refs/remotes/tags/csl/renesas/* fetch = tags/csl/renesas:refs/remotes/tags/dirs/csl/renesas tags = tags/csl/sourcerygxx/*:refs/remotes/tags/csl/sourcerygxx/* fetch = tags/csl/sourcerygxx:refs/remotes/tags/dirs/csl/sourcerygxx tags = tags/csl/wrs-linux/*:refs/remotes/tags/csl/wrs-linux/* fetch = tags/csl/wrs-linux:refs/remotes/tags/dirs/csl/wrs-linux tags = tags/csl/*:refs/remotes/tags/csl/others/* fetch = tags/csl:refs/remotes/tags/dirs/csl/root tags = tags/ix86/*:refs/remotes/tags/ix86/* fetch = tags/ix86:refs/remotes/tags/dirs/ix86 tags = branches/st/tags/*:refs/remotes/tags/st/* fetch = branches/st/tags:refs/remotes/tags/dirs/st tags = tags/redhat/*:refs/remotes/tags/redhat/* fetch = tags/redhat:refs/remotes/tags/dirs/redhat tags = tags/ubuntu/*:refs/remotes/tags/ubuntu/* fetch = tags/ubuntu:refs/remotes/tags/dirs/ubuntu tags = tags/*:refs/remotes/tags/* fetch = tags:refs/remotes/tags/dirs/root fetch = :refs/remotes/dirs/root -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: git mirror repacked, new branches
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). > > [svn-remote "svn"] > rewriteRoot = svn+ssh://gcc.gnu.org/svn/gcc > # url = svn+ssh://aol...@gcc.gnu.org./svn/gcc > url = file:///l/tmp/build/gcc/gccrepo > fetch = trunk:refs/remotes/trunk > branches = branches/ARM/*:refs/remotes/branches/ARM/* > fetch = branches/ARM:refs/remotes/dirs/branches/ARM > branches = branches/apple/*:refs/remotes/branches/apple/* > fetch = branches/apple:refs/remotes/dirs/branches/apple > branches = branches/csl/*:refs/remotes/branches/csl/* > fetch = branches/csl:refs/remotes/dirs/branches/csl > branches = branches/dead/*:refs/remotes/branches/dead/* > fetch = branches/dead:refs/remotes/dirs/branches/dead > branches = branches/gcj/*:refs/remotes/branches/gcj/* > fetch = branches/gcj:refs/remotes/dirs/branches/gcj > branches = branches/ibm/*:refs/remotes/branches/ibm/* > fetch = branches/ibm:refs/remotes/dirs/branches/ibm > branches = branches/ix86/*:refs/remotes/branches/ix86/* > fetch = branches/ix86:refs/remotes/dirs/branches/ix86 > branches = branches/redhat/*:refs/remotes/branches/redhat/* > fetch = branches/redhat:refs/remotes/dirs/branches/redhat > branches = branches/st/*:refs/remotes/branches/st/* > fetch = branches/st:refs/remotes/dirs/branches/st > branches = branches/suse/*:refs/remotes/branches/suse/* > fetch = branches/suse:refs/remotes/dirs/branches/suse > branches = branches/ubuntu/*:refs/remotes/barnches/ubuntu/* > fetch = branches/ubuntu:refs/remotes/dirs/branches/ubuntu > branches = branches/*:refs/remotes/branches/* > fetch = branches:refs/remotes/dirs/branches/root > tags = tags/apple/*:refs/remotes/tags/apple/* > fetch = tags/apple:refs/remotes/tags/dirs/apple > tags = tags/csl/arm/*:refs/remotes/tags/csl/arm/* > fetch = tags/csl/arm:refs/remotes/tags/dirs/csl/arm > tags = tags/csl/coldfire/*:refs/remotes/tags/csl/coldfire/* > fetch = tags/csl/coldfire:refs/remotes/tags/dirs/csl/coldfire > tags = tags/csl/morpho/*:refs/remotes/tags/csl/morpho/* > fetch = tags/csl/morpho:refs/remotes/tags/dirs/csl/morpho > tags = tags/csl/renesas/*:refs/remotes/tags/csl/renesas/* > fetch = tags/csl/renesas:refs/remotes/tags/dirs/csl/renesas > tags = tags/csl/sourcerygxx/*:refs/remotes/tags/csl/sourcerygxx/* > fetch = tags/csl/sourcerygxx:refs/remotes/tags/dirs/csl/sourcerygxx > tags = tags/csl/wrs-linux/*:refs/remotes/tags/csl/wrs-linux/* > fetch = tags/csl/wrs-linux:refs/remotes/tags/dirs/csl/wrs-linux > tags = tags/csl/*:refs/remotes/tags/csl/others/* > fetch = tags/csl:refs/remotes/tags/dirs/csl/root > tags = tags/ix86/*:refs/remotes/tags/ix86/* > fetch = tags/ix86:refs/remotes/tags/dirs/ix86 > tags = branches/st/tags/*:refs/remotes/tags/st/* > fetch = branches/st/tags:refs/remotes/tags/dirs/st > tags = tags/redhat/*:refs/remotes/tags/redhat/* > fetch = tags/redhat:refs/remotes/tags/dirs/redhat > tags = tags/ubuntu/*:refs/remotes/tags/ubuntu/* > fetch = tags/ubuntu:refs/remotes/tags/dirs/ubuntu > tags = tags/*:refs/remotes/tags/* > fetch = tags:refs/remotes/tags/dirs/root > fetch = :refs/remotes/dirs/root Amazing. And how well does this monster config work? Would you recommend doing the same with our public git mirror? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
