Re: __function_size builtin
On 22/06/11 23:25, Ian Lance Taylor wrote: "Paulo J. Matos" writes: On 22/06/11 17:34, Paulo J. Matos wrote: I thought this was the same as using __attribute__((used)) on a function declaration (which works). DECL_PRESERVE_P(node) = 1; seems to be what I wanted. :) I always wondered what that was for. Now we know... however the funny thing is that you would expect __attribute__((used)) to set TREE_USED(node), however, __attribute__((used)) sets the preserve flag. This did confuse me yesterday! :) Fortunately it is now solved. Thanks for you help! Ian
Re: [GCC steering committee] I'd like to be maintainer for Linux/x86 platform
> On Wed, Jun 22, 2011 at 3:25 PM, Ian Lance Taylor wrote: > > "H.J. Lu" writes: > > > >> Apparently, there is no GCC maintainer for Linux/x86 platform. I have > >> been working on GCC, as well as binutils and C libraries, for Linux/x86 > >> over 20 years. I ported GCC, binutils and the C library to Linux/x86. I > >> like to be appointed as maintainer for Linux/x86 platform. > > > > H.J., you're a good developer, but I'm concerned that you commit patches > > too quickly without fully considering all the issues. You are quick to > > update your changes as well, but this leads to churn which has its own > > problems. I would be comfortable saying that you should have the > > ability to approve other people's patches for Linux/x86 (other people > > who don't work closely with you, at any rate), but I'm not entirely > > comfortable saying that you should be able to commit your own patches > > without review. > > > > My direct motivation is to use DT_INIT_ARRAY on Linux/x86. I > have worked on all areas of DT_INIT_ARRAY, including specification > as well as implementations in assembler, linker and glibc. My GCC patch > hasn't been reviewed for many months. It appears to me that no GCC > maintainers seem interested or have capability to review platform > specific support for Linux/x86. If I am wrong, please let me know > what I can do to make Linux/x86 to use DT_INIT_ARRAY. This patch in question is somewhat special: as presented here it probably falls under umbrella of x86 maintainer (except for configure bits). There is however nothing really x86 specific in the problem it solves. It is for targets that: a) use GNU binutils b) currently uses the old version of ctor/dtor support. as far as I can tell, the last incarnation of patch in http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00760.html updates those targets and thus is not x86/Linux specfic patch. I do like the idea of patch and see why it helps Mozilla/Chrome etc. I also looked into the original x86 specific version of the patch and I think I suggested getting it generic. It would help to answer the concerns discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 about relative ordering of "old" and "new" units with user defined constructor functions and status of support in the GOLD linker. Iant, it also do seem to me that you are about best fitting maintiner to review the change :) Honza > > Thanks. > > > -- > H.J.
Re: Middle end warnings cascading after C++ parsing errors
On Mon, Jun 20, 2011 at 10:50, Diego Novillo wrote:
> On Mon, Jun 20, 2011 at 10:47, Richard Guenther
> wrote:
>> On Fri, Jun 17, 2011 at 5:39 PM, Jason Merrill wrote:
>>>
>>> That seems reasonable to me.
>>
>> Yes. I think Steven proposed this as well at some point.
>
> Alright, thanks.
>
> Unsurprisingly, this produces 152 failures in the testsuite. I have
> not analyzed the reasons yet, but I hope it's just tweaking expect
> lines in the tests.
So, I think we need to re-think where to check for seen_errors().
Bailing out too early is disabling some valid diagnostics. For
instance,
gcc/testsuite/gcc.dg/asm-7.c:
$ cat -n
/home/dnovillo/g1/fix-4487457/Patch-752f00bd28e325efdfa0ac7abed22feb_branches-google-main/gcc/testsuite/gcc.dg/asm-7.c
1 /* Gcc 3.3.1 deprecates memory inputs of non-lvalues. */
2 /* { dg-do compile } */
3
4 void test(void)
5 {
6register int r;
7register int r2;
8int i;
9static int m;
10int *p;
11
12__asm__ ("" : : "m"(r)); /* { dg-error "" } */
This error is given by the parser.
13__asm__ ("" : : "m"(i));
14__asm__ ("" : : "m"(m));
15__asm__ ("" : : "m"(0)); /* { dg-error "" } */
16__asm__ ("" : : "m"(i+1));/* { dg-error "" } */
These two errors, however, are emitted by the gimplifier, which does
not run anymore. The gimplifier will not run until we are in
cgraph_finalize_compilation_unit (called from
lang_hooks.decls.final_write_globals).
Ideally, we would move all diagnostics from the gimplifier into the
front end, but that seems to be a pretty hairy mess to untangle.
In looking at cgraph_finalize_compilation_unit, it seems like the
earliest we can bail out is after we've gimplified and lowered every
function. But this means that we will do reachability analysis, which
takes me back to my original bug.
I'm thinking that the simplest fix for my release branch will be to
predicate reachability analysis with seen_errors().
For trunk, I think I would like to see us bailing out early:
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 2f1a4a8..5a48b3f 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -585,7 +585,7 @@ compile_file (void)
/* Compilation is now finished except for writing
what's left of the symbol table output. */
- if (flag_syntax_only || flag_wpa)
+ if (flag_syntax_only || flag_wpa || seen_error ())
return;
timevar_start (TV_PHASE_GENERATE);
But this is producing several regressions in diagnostics. Moving
those diagnostics to the parser does not look all that easy.
Thoughts?
Diego.
gcc-4.5-20110623 is now available
Snapshot gcc-4.5-20110623 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110623/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 175356 You'll find: gcc-4.5-20110623.tar.bz2 Complete GCC MD5=f5784972cd9d2cbe307c74a051c421bc SHA1=dc728433ff2a25171feb75be0c7df34bfe9ef68d Diffs from 4.5-20110616 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Middle end warnings cascading after C++ parsing errors
Diego Novillo writes:
> So, I think we need to re-think where to check for seen_errors().
> Bailing out too early is disabling some valid diagnostics. For
> instance,
>
> gcc/testsuite/gcc.dg/asm-7.c:
> $ cat -n
> /home/dnovillo/g1/fix-4487457/Patch-752f00bd28e325efdfa0ac7abed22feb_branches-google-main/gcc/testsuite/gcc.dg/asm-7.c
> 1 /* Gcc 3.3.1 deprecates memory inputs of non-lvalues. */
> 2 /* { dg-do compile } */
> 3
> 4 void test(void)
> 5 {
> 6register int r;
> 7register int r2;
> 8int i;
> 9static int m;
> 10int *p;
> 11
> 12__asm__ ("" : : "m"(r)); /* { dg-error "" } */
>
> This error is given by the parser.
>
> 13__asm__ ("" : : "m"(i));
> 14__asm__ ("" : : "m"(m));
> 15__asm__ ("" : : "m"(0)); /* { dg-error "" } */
> 16__asm__ ("" : : "m"(i+1));/* { dg-error "" } */
>
> These two errors, however, are emitted by the gimplifier, which does
> not run anymore.
Well, so what? This test case does not represent actual or even likely
user code. I don't think we need to contort ourselves to generate all
possible errors for erroneous input. As many errors as reasonable, yes.
All possible errors, no.
I agree that we should not make this change on the release branch. On
mainline we should simply split this test case into two.
Ian
Re: Middle end warnings cascading after C++ parsing errors
On 06/23/2011 06:48 PM, Ian Lance Taylor wrote: Well, so what? This test case does not represent actual or even likely user code. I don't think we need to contort ourselves to generate all possible errors for erroneous input. As many errors as reasonable, yes. All possible errors, no. I agree that we should not make this change on the release branch. On mainline we should simply split this test case into two. I agree. Jason
