We are organizing a gathering of GCC developers and interested parties
at the Google office in London, UK for the weekend of 17-Jun-2011.
The gathering will be Friday evening, all day Saturday, and Sunday
until some time in the afternoon.
The idea is to simply get together and discuss current/futu
Please contact us before 22/Apr to confirm your assistance. We need
to have an idea of how many people to expect for planning.
Thanks. Diego.
-- Forwarded message --
From: Diego Novillo
Date: Fri, Apr 8, 2011 at 16:15
Subject: GCC Gathering in London 17/Jun to 19/Jun 2011
To
I committed revisions 172504 and 172505 to google/gcc-4_6
Rev 172504 merges all the changes from gcc-4_6-branch since the 4.6.0
release.
Rev 172505 is the following release-only fix from Le-Chun that fixes
annotalysis conflicts with new constexpr changes in the parser:
2011-04-15 Le-Chun Wu
Merge google/integration into google/main at rev 172609.
Tested on x86_64.
Diego.
Merged google/main into google/gcc-4_6 up to rev 172617.
Tested on x86_64.
Diego.
This merge brings the branch up to rev 172633.
Tested on x86_64.
Diego.
This merge brings the branch up to rev 172662.
There are some LTO failures which are ICEs induced by a new
assertion I added in bp_pack_value. We discussed this in
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01115.html.
The failure happens when we try to pack DECL_OFFSET_ALIGN. We
only try to
[ Adding Jason and gcc@ ]
Jason,
On Tue, Apr 19, 2011 at 22:10, Lawrence Crowl wrote:
> For the testcase x1hardlookup.cc, we read in the following from
> the pph file.
>
> namespace :: {
> function_decl int (int, struct D) operator+
> type_decl struct D D
> var_decl int V
> type_
The previous merge broke release checking builds because of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48652.
That was fixed in the very next rev after my merge, so I just
cherry picked rev 172663.
Lawrence, this should fix your builds.
Diego.
We are starting to run tight on space. If you are thinking of
attending this event, please let us know soon.
Thanks. Diego.
-- Forwarded message --
From: Diego Novillo
Date: Fri, Apr 15, 2011 at 09:44
Subject: Reminder - GCC Gathering in London 17/Jun to 19/Jun 2011
To: g
On Fri, Apr 29, 2011 at 09:24, Dimitrios Apostolou wrote:
> Thank you all for your ideas, they are much appreciated. I will certainly
> investigate into the areas you mentioned, so do keep the feedback coming. I
> will certainly comment on them, once I have a better understanding. And I'd
> like t
-Chun Wu
* g++.dg/warn/Wnull-conversion-1.C: New.
* g++.dg/warn/Wnull-conversion-2.C: New.
cp/ChangeLog.google-main
2011-04-28 Diego Novillo
Le-Chun Wu
* call.c (conversion_null_warnings): Also handle assignments
when warning about NULL con
On Thu, May 5, 2011 at 12:53, Pierre Vittet wrote:
> Hello,
>
> I would like to announce that I have been able to compile GCC while checking
> it with a simple MELT plugin that I have wrote. This plugin is integrated
> into GCC by using the MELT plugin. I guess this is the first successfull use
>
On Thu, May 5, 2011 at 15:16, Diego Novillo wrote:
> I've always found MELT interesting as an exercise in impossibility and
> [ ... ]
There was some confusion about my meaning here. It was meant as a
compliment. Sorry for the confusion.
Diego.
This merge brings the gimple-front-end branch up to 4.7. It needed
some minimal adjustments, but things seem to be working. Sandeep,
please make sure it does. You may need to rebase your patch before
committing it.
We need some tests in testsuite/gimple. Sandeep, do you think you
could add som
er, wrong subject. I merged up to rev 173270.
Diego.
On Sat, May 7, 2011 at 16:50, Sandeep Soni wrote:
> I got the build working on my machine. So preliminarily things seem to
> be working. In case this merge brings our branch up to 4.7 should "gcc
> -v" be showing it? It is not currently.
Yes, gcc -v should show:
Using built-in specs.
COLLECT_G
This merge brings all the changes in google/main up to rev
173605.
Validated on x86_64.
Diego.
Merged revisions
173258,173353,173395,173398,173411,173416,173499,173504,173526,173605 via
svnmerge from
svn+ssh://gcc.gnu.org/svn/gcc/branches/google/main
r173258 | cgd | 2011-05-02 12
This merge brings every change in gcc-4_6-branch up to rev
173632.
Validated on x86_64.
Diego.
This merge brings google/main rev 174086 into google/gcc-4_6.
Validated on x86_64.
Diego.
This merge merges from gcc-4_6-branch as of rev 174114.
Validated on x86_64.
Diego.
I have created a wiki page for the Londong meeting coming up
(http://gcc.gnu.org/wiki/GCCGathering2011). Everyone who registered
to the event has been invited to join the mailing list
gcc-gather...@googlegroups.com. The mailing list is open for anyone
to join.
We will use the list and the wiki t
The new routines lto_output_int_in_range and lto_input_int_in_range do
not seem to be working right. In the pph branch, we have an LTO_tags
enum with a range [0 - 351]. This is causing two things:
- The writer gets out of sync with the reader because, we emit
delimiters with output_zero. This w
On Mon, May 30, 2011 at 13:44, Basile Starynkevitch
wrote:
> Diego and other people interested in plugins, what do you think of such
> a proposal?
I don't think that would work. Plugins need to know at what level
they are working. FE plugins would have access to functions and data
that gimple
This merge brings google/gcc-4_6 up to rev 174482.
Validated on x86_64.
Diego.
This merge brings google/gcc-4_6 to rev 174522.
Diego.
This merge did not bring any code changes. The only patch merged from
google/integration was the addition of -Wself-assign to c.opt that we
already have in google/main.
Diego.
This merge brings google/gcc-4_6 up to rev 174706.
Validated on x86_64.
Diego.
Ketaki, Sandeep,
My last merge from trunk into gimple-front-end was incomplete. I just
realized that I had failed to commit several directories. I just
committed a fix, so please make sure that your local checkout is at
rev 174754.
Diego.
This brings google/gcc-4_6 up to rev 174748.
Validated on x86_64.
Diego.
Gab has been debugging a failure that goes like this:
In testsuite/g++.dg/pph/x1functions.h:
struct type {
int mbr_decl_then_def(int);
int mbr_decl_inline(int i) { }
}
In testsuite/g++.dg/pph/x1functions.cc:
#include "x1functions.h"
int type::mbr_decl_then_def(int i)
{ return mbr_decl_inl
This merge brings google/gcc-4_6 up to rev 174986 from
google/main.
Validated on x86_64.
Diego.
This brings google/gcc-4_6 up to rev 175007.
Validated on x86_64.
Diego.
Tested on x86_64.
Diego.
I am looking at an internally reported bug against 4.6 that starts
with something like this:
$ cat a.cc
int bar(int);
struct B {
B(int);
~B() __attribute__((noreturn));
};
int foo(void)
{
B::B f(10);
return 0;
}
int bar(int j)
{
B(10);
}
$ ./cc1plus -Wall -Werror a.cc
int foo()
a.cc:
On Fri, Jun 17, 2011 at 14:47, Diego Novillo wrote:
> if (flag_syntax_only || flag_wpa)
> return;
>
> to
>
> if (flag_syntax_only || flag_wpa || errorcount > 0)
> return;
To clarify. It would be 'seen_error ()' instead of 'errorcount > 0',
but the idea is the same.
Diego.
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
n
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
On Thu, Jun 23, 2011 at 22:04, Jason Merrill wrote:
> 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
I've uploaded a copy of the notes we took during the meetings in
London last weekend.
http://gcc.gnu.org/wiki/GCCGathering2011
I think we may be missing a couple of slide presentations, so if you
have notes or slides that I didn't get to add, please let me know.
Diego.
On 11-06-28 08:51 , Richard Guenther wrote:
I think we started suggesting more maintainers / reviewers to the SC
and the appointments will slowly tickle in. If that works to our
satisfaction we do nothing (apart from proposing more people - the idea
was to broaden the area people can review pat
On 11-06-28 09:02 , Vladimir Makarov wrote:
Bernd and Richard, I'd like thank you for generous support of me. But
the email was mostly not about my frustration. I raised several
questions relative to the decision:
* ambiguity of the decision. What does RTL optimizers/RTL maintainer mean?
Anyt
This brings google/gcc-4_6 up to rev. 175526.
Validated on x86_64.
Diego.
This merge brings google/gcc-4_6 up to date with the recently
released 4.6.1 (rev 175583).
Since there was some interest in a few fixes in the upstream
branch, these are the revisions that made it through in this
merge.
Ollie, Martin's fix to PR 49516 will be committed in the next few
days. If n
On 11-06-29 11:42 , Martin Jambor wrote:
The fix for 49094 had to be changed and is still being tested, even
for trunk, and thus I have committed a 4.6 "backport" of the fix for
PR 49516 on its own today (as revision 175634). Nevertheles yes, the
patch is exactly the same, only with a minor lin
On Wed, Jun 29, 2011 at 12:24, Ollie Wild wrote:
> On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor wrote:
>>
>> The fix for 49094 had to be changed and is still being tested, even
>> for trunk, and thus I have committed a 4.6 "backport" of the fix for
>> PR 49516 on its own today (as revision 175
On Wed, Jun 29, 2011 at 12:31, Ollie Wild wrote:
> Diego will merge this to the google/gcc-4_6 branch.
Done.
Diego.
So, I thought this was not working, but it is:
$ make check-g++ RUNTESTFLAGS=pph.exp='c1eabi1.*'
will run all the tests for c1eabi1.cc and c1eabi1.h.
Diego.
This is the last merge from google/main into google/gcc-4_6 (rev
175816).
After this merge, both google/integration and google/main will
resume tracking trunk. From now on, any changes needed from
trunk or any other google branch, will need to be backported to
google/gcc-4_6.
Merges from gcc-4_6
FYI. I added some more slides and a group picture to
http://gcc.gnu.org/wiki/GCCGathering2011
Diego.
This merge brings the pph branch up to rev 175832. No new
failures nor merge conflicts this time.
Tested on x86_64.
Diego.
This brings google/gcc-4_6 up to rev 175849.
Diego.
Jason,
We are having several issues re-instantiating symbols and
namespaces from a pph image. We are not handling all the cases
and the contortions we are going through are getting increasingly
bizarre. Perhaps you could give us a few pointers?
When we write the contents of a header file into a
We discussed this briefly at the recent London meetings. If anyone is
interested in participating, please contact me.
Diego.
Original Message
Subject:Google Summer of Code 2011 Doc Camp 17 October - 21 October
Date: Mon, 11 Jul 2011 17:41:02 -0700
From: Carol S
On 11-07-12 12:52 , Philip Herron wrote:
Would Gcc internals documentation count or is it more for a whole
project documentation work? I probably missed the thing about this in
London since i had to leave on the Sunday morning.
I am kind of interested but i am unsure what kind of documentation
On Wed, Jul 13, 2011 at 07:09, Philip Herron wrote:
> I am quite interested in applying for this but not quite sure what my
> proposal should be like. Should i just discuss my interest in
> front-end and middle-end stuff and the lack of documentation currently
> etc.
Given that you are volunteer
This brings in the cp_binding_level change I made recently on
trunk.
Tested on x86_64.
Diego.
On Wed, Jul 13, 2011 at 10:22, AJM-2 wrote:
> My question is whether LTO can be used in this way, to have a simple ipa
> pass called once at link time with access to the function bodies, and if so
> how is this achieved? cgraph_function_body_availability seems to only be
> half the story.
Yes,
On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor wrote:
> 2011-07-15 Ian Lance Taylor
>
> * configure.ac: Add --enable-build-poststage1-with-cxx. If set,
> make C++ a boot_language. Set and substitute
> POSTSTAGE1_CONFIGURE_FLAGS.
> * Makefile.tpl (POSTSTAGE1_CONFI
g-error "must be a scalar coarray of type LOCK_TYPE" }
- lock(lock[1]) ! { dg-error "must be a scalar coarray of type LOCK_TYPE" }
+ lock(lock[1]) ! { dg-error "must be a scalar coarray of type LOCK_TYPE" {
xfail *-*-* } }
end subroutine lock_test2
diff --git a/lib
On Mon, Jul 18, 2011 at 20:29, Gabriel Charette wrote:
> so the asm diff we are seeing in c1builtin-integral is not something
> we are not streaming out, or any other logic being wrong in the pph.
>
> The problem is: we define a dg-options entry in the header file which
> tells deja-gnu to add fl
On Mon, Jul 18, 2011 at 20:45, Gabriel Charette wrote:
> To demonstrate my point:
> add /* { dg-options "-ffinite-math-only -fno-math-errno" } */
> to c1builin-integral.cc
>
> and watch the test pass (since now we are using the flags across all
> compilations).
Ah, OK. That's your fix then.
Di
On Mon, Jul 18, 2011 at 21:00, Gabriel Charette wrote:
> We probably only want to enforce this for a subset of the flags (i.e.
> we don't care about flags like -Wall and stuff like that, but only
> about the flags actually affecting the binary output).
In principle, this is no different than mix
On Tue, Jul 19, 2011 at 00:09, Gabriel Charette wrote:
> There is also the case where different C files are compiled with different
> flags, but using the same headers (in the current build system say). When
> moving to pph we would need to recognize that and generate different pph
> files (as op
I just committed a merge from gcc-4_6-branch into google/gcc-4_6.
This brings google/gcc-4_6 up to rev 176416.
Diego.
On Wed, Jul 20, 2011 at 08:41, Richard Guenther
wrote:
> Which is good as it increases testing coverage. We probably would have
> missed this bug completely if you wouldn't have notice it.
Agreed. The pain we feel due to this is similar to the pain one feels
after exercising vigorously.
Dieg
This merge brings trunk into google/main (via google/integration).
It had been a long while since we had merged from trunk so it
took a while to fix and there are several broken modules.
We decided that it's better to commit the merge for now and fix
the broken modules next. So, if you had a copy
This merge brings in Gab's trunk changes to line_map and my
refactoring of the streaming code. It also allows us to
use C++ for the implementation (with the same caveats we have in
trunk, the code must be ifdef'd to build with both C and C++
compilers).
I will continue the next phase of the strea
This brings the second part of the streamer refactoring. I'm
going to be doing frequent merges in the next little while to
avoid big conflicts.
Tested on x86_64.
Diego.
Tested on x86-64. This syncs up with the libcpp changes that Gab
committed upstream recently.
Diego.
One of the most vexing aspects of GCC development is dealing with
failures in the various testsuites. In general, we are unable to
keep failures down to zero. We tolerate some failures and tell
people to "compare your build against a clean build".
This forces developers to either double their te
On Thu, Sep 8, 2011 at 04:31, Richard Guenther
wrote:
> I think it would be more useful to have a script parse gcc-testresults@
> postings from the various autotesters and produce a nice webpage
> with revisions and known FAIL/XPASSes for the target triplets that
> are tested.
Sure, though that
On Thu, Sep 8, 2011 at 07:16, Richard Guenther
wrote:
> Well, you'd need to maintain a list of known XPASS/FAILs anyway.
Yes, of course. That's the manifest of things you expect to be broken.
> You can as well do it in the testcases themself (add XFAILs, remove
> XPASSes and open bugreports to
On Thu, Sep 8, 2011 at 07:49, Richard Guenther
wrote:
> Well, I'd rather _fix_ dejagnu then. Any specific example you can't
> eventually xfail by dg-skipping the testcase?
Several I mentioned upthread:
- Some .exp files do no support xfail markers.
- Different directories will have their own sy
On Thu, Sep 8, 2011 at 08:20, Richard Guenther
wrote:
> Cache the comparison result? If you specify a (minimum) revision
> required for testing just test against a cached revision that fulfils
> the requirement. Something I never implemented for ours.
Nope. Build must be functionally independ
On Thu, Sep 8, 2011 at 08:29, Richard Guenther
wrote:
> It _does_ live with the source code. Think of implicitly "checking in" the
> build result with the tested revision. That's not different from your idea
> of checking in some sort of whitelist of fails.
Ah, I see what you mean. Yes, that'
On Thu, Sep 8, 2011 at 09:23, Richard Earnshaw wrote:
> And that's only going to work if all the test names are unique. I
> currently see quite a few tests that appear in my log as both PASS and
> FAIL in a single run. For example:
That's fine. What we are looking for is to capture the state
on x86_64. Committed to google/integration.
2011-09-14 Diego Novillo
Mainline merge rev 178783.
Cherry pick mainline rev 178833.
2011-09-14 Diego Novillo
contrib/ChangeLog.google-integration
* testsuite-management/x86_64-unknown-linux-gnu.xfail: New.
gcc
This merge adds the testsuite validation script to
google/gcc-4_6. Merged up to rev 178854.
Validated on x86_64.
Diego.
On 11-09-16 12:05 , Joachim Wieland wrote:
I am looking at the AST from a plugin and a tree walking function
called from PLUGIN_PRE_GENERICIZE. Is there an earlier phase that I
could hook into? If not, would it be acceptable to add the original
tree to a folded tree for analyzing tools like mine
On 11-09-16 16:25 , Joachim Wieland wrote:
Hm, I don't see how exactly this would solve my problem... The issue I
am facing is that references to necessary header files are optimized
away. Just knowing that an expression has been folded doesn't help
me... :-(
Sorry, I was too cryptic. The set
On 11-09-19 23:32 , Sandeep Soni wrote:
It gives me a internal compiler error saying:
gimple1: internal compiler error: tree check: expected
identifier_node, have var_decl in gimple_symtab_entry_hash
As Balaji said, the problem is that you need to pass
DECL_NAME(base->decl) to IDENTIFIER_HASH
. The
token caching done in cp_parser_save_attribute_arg_list was
causing ICEs during parsing (it forces a type cast from token
cache to a tree node).
Validated on x86_64. Committed to google/main.
Diego.
libgcc/ChangeLog.google-main
2011-09-16 Diego Novillo
* Makefile.in: Re-apply
Lawrence,
This merge brings the testsuite validation script. You can use
it after builds with:
$ cd
$ /contrib/testsuite-management/validate_failures.py
It will tell you what new failures you have in the build.
Tested on x86_64. Committed to branch.
Diego.
On 11-09-22 09:40 , Dodji Seketeli wrote:
Romain Geissler a écrit:
I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
The followings does not currently trigger the PLUGIN_FINISH_DECL
(or not in all cases), but should them ?
- function parameters (in the function prototype
On Thu, Sep 22, 2011 at 20:06, Hans-Peter Nilsson wrote:
> On Thu, 8 Sep 2011, Diego Novillo wrote:
>
>> On Thu, Sep 8, 2011 at 04:31, Richard Guenther
>> wrote:
>>
>> > I think it would be more useful to have a script parse gcc-testresults@
>> > posting
On Wed, Oct 19, 2011 at 21:30, Cary Coutant wrote:
> http://gcc.gnu.org/wiki/DebugFission
>
> I expect we'll be ready to merge our work into trunk when Stage 1
> opens for GCC 4.8.
>
> Any objections? Is it OK to make a git-only branch?
Anyone with SVN write access can create a new branch. Th
On 11-11-01 11:23 , Jeff Law wrote:
This stuff is fairly isolated in terms of what it touches and I'm sure
if anything goes wrong, Aldy, Richard& Torvald will be available to
fix it.
The request to merge came in before the end of stage1, I don't see a
reason to delay things another 6-9 months.
On Tue, Nov 1, 2011 at 17:19, Robert Dewar wrote:
> On 11/1/2011 12:59 PM, David Edelsohn wrote:
>>
>> On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
>> wrote:
>>
>>> Given that you only recently merged with trunk again are you really
>>> sure this is a great
>>> idea at this point in time? D
On 11-11-01 14:44 , Aldy Hernandez wrote:
Aldy, Richard, is there a patchset or master patch I could read?
I have made current diff as of today:
http://quesejoda.com/tm-branch-latest.bz2
Thanks.
Diego.
Gerald, I've been searching for the release criteria pages for various
releases. I haven't found anything. I was expecting to find them as
top-level links on the home page.
Should I prepare a patch? Or should I have looked in a different place?
Thanks. Diego.
On 11-11-17 11:19 , Richard Guenther wrote:
They are release specific - in gcc-MAJOR.MINOR/criteria.html. Especially
the list of primary and secondary targets may vary. It would be
certainly useful
to have a "next upcoming release" link on the main page, pointing to
gcc-4.7/index.html. But we
==
GNU Tools Cauldron 2012
http://gcc.gnu.org/wiki/cauldron2012
Call for Abstracts
July 2012
Charles University, Prague, Czech Republic
On Fri, Nov 18, 2011 at 07:54, Gerald Pfeifer wrote:
> On Thu, 17 Nov 2011, Diego Novillo wrote:
>> I was thinking changing the text:
>>
>> Active development: GCC 4.7.0 (changes)
>>
>> to
>>
>> Active development: GCC 4.7.0 (changes, release criteri
On Sun, Nov 20, 2011 at 03:43, Jeff Evarts wrote:
> I posted this question at irc://irc.oftc.net/#gcc and they suggested
> that I pose it here instead.
>
> I do some "large-ish" builds (linux, gcc itself, etc) on a too-regular
> basis, and I was wondering what could be done to speed things up. A
>
On Sun, Nov 20, 2011 at 08:10, Basile Starynkevitch
wrote:
> I'm not sure the question belongs to gcc@gcc.gnu.org, perhaps
> gcc-h...@gcc.gnu.org might
> be a better place.
gcc@ is the right forum for this question.
Diego.
includer fields, we now write
relative indices. These are later relocated during read. This
way, it doesn't matter where individual line tables are inserted
(patch below).
Tested on x86_64. Committed to branch.
2011-11-22 Diego Novillo
* pph-streamer-in.c (pph_in_int)
On Wed, Nov 30, 2011 at 15:06, David Malcolm wrote:
> Any thoughts on how to address this? Are there any other approaches
> I've missed?
Why not use a langhook? We do this for lang_hooks::decl_printable_name.
Diego.
I just merged from trunk and several of my C++ tests are failing with
the error:
In file included from <...>/libstdc++-v3/libsupc++/new:42:0,
from
<...>/gcc/testsuite/g++.dg/pph/x5dynarray3.h:5:<...>/libstdc++-v3/libsupc++/exception:40:42:
fatal error: bits/atomic_lockfree_d
On Fri, Dec 2, 2011 at 19:54, Andrew MacLeod wrote:
> bkoz rewrote all the libstdc++ support. I'd guess your missing an update or
> something since I didnt see anything like what you are seeing with a scratch
> build and full testsuite run yesterday... ?
Thanks. I think I must've had a bad bu
401 - 500 of 1389 matches
Mail list logo
