On 6/5/09, Graham Reitz wrote:
> I have been working through sections 16 & 17 of the gccint.info
> document and also read through Hans' 'Porting GCC for Dunces'.
There is also "Incremental Machine Descriptions for GCC"
http://www.cse.iitb.ac.in/~uday/soft-copies/incrementalMD.pdf
which describes
On Tue, 9 Jun 2009, Basile STARYNKEVITCH wrote:
> How do you folks have several GCC installed at the same prefix?
Yes, I have been doing this for the FreeBSD ports for years, and what
I am using there is the following
--program-suffix=${SUFFIX} \
--libdir=${TARGLIB} \
--libexecd
On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:
> Perhaps the only safe way to create the value, even in the presence of
> rounding mode changes, is to use conj(3.I) ?
Setting the __real__ and __imag__ parts of a temporary variable should
always be reliable for making a complex number out of arbitrary
Hi.
I've had no luck with recent bootstraps on both i386-pc-solaris2.10 and
sparc-sun-solaris2.10. The error messages below are from builds performed
after updating my repo this morning.
i386-pc-solaris:
cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefe
Bernie Innocenti wrote:
On 06/07/09 12:40, Ralf Wildenhues wrote:
Is this mirror an independent conversion from the infradead one (i.e., I
have to throw away the repo and re-download a full repo? Or can I reuse
objects)?
It's an independent mirror, and I wouldn't recommend switching to it y
From: "Joseph S. Myers"
On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:
Perhaps the only safe way to create the value, even in the presence of
rounding mode changes, is to use conj(3.I) ?
Setting the __real__ and __imag__ parts of a temporary variable should
always be reliable for making a comple
On Tue, Jun 9, 2009 at 11:26 AM, Kaveh R. Ghazi wrote:
> From: "Joseph S. Myers"
>
>> On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:
>>
>>> Perhaps the only safe way to create the value, even in the presence of
>>> rounding mode changes, is to use conj(3.I) ?
>>
>> Setting the __real__ and __imag__ par
Hello,
> i386-pc-solaris:
>
> cc1: warnings being treated as errors
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function
> 'loop_prefetch_arrays':
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error:
> format '%ld' expects type 'long int', but argument
On Tue, 9 Jun 2009, Art Haas wrote:
>
> Hi.
>
> I've had no luck with recent bootstraps on both i386-pc-solaris2.10 and
> sparc-sun-solaris2.10. The error messages below are from builds performed
> after updating my repo this morning.
>
> i386-pc-solaris:
>
> cc1: warnings being treated as errors
Revital1 Eres writes:
> Hello,
>
>> i386-pc-solaris:
>>
>> cc1: warnings being treated as errors
>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function
>> 'loop_prefetch_arrays':
>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error:
>
>> format '%ld' expe
Hello All,
I am unfortunately not attending the GCC summit which happens right now
in Montreal.
But apparently, there seems to be a lack of code reviewers for GCC. The
few people who do review code seems to have a lot of review in their
batch queue.
Perhaps could be discussed at the summit
Basile STARYNKEVITCH wrote:
> I am unfortunately not attending the GCC summit which happens right now
> in Montreal.
>
> But apparently, there seems to be a lack of code reviewers for GCC. The
> few people who do review code seems to have a lot of review in their
> batch queue.
>
> Perhaps could
Andrew Haley wrote:
Basile STARYNKEVITCH wrote:
Perhaps could be discussed at the summit some way to increase the set of
reviewers, i.e. the set of people able to say Ok to a patch submitted on
gcc-patches@
As I understand it, the set of reviewers allowed to say OK to a patch is
limited
Basile STARYNKEVITCH wrote:
Andrew Haley wrote:
Basile STARYNKEVITCH wrote:
PS. [note *] GCC is a huge software, so understanding well a part of
it could be enough to understand some patches.
And GCC is a huge software
I meant GCC is growing a lot. Its increase rate (about 1MLOC in less
Basile STARYNKEVITCH wrote:
> Andrew Haley wrote:
>> Basile STARYNKEVITCH wrote:
>>>
>>> Perhaps could be discussed at the summit some way to increase the set of
>>> reviewers, i.e. the set of people able to say Ok to a patch submitted on
>>> gcc-patches@
>>
>> As I understand it, the set of review
Andrew Haley writes:
> We need something more like "I think Fred Bloggs knows gcc well enough
> to approve patches to reload" or "I am Fred Bloggs and I know gcc well
> enough to approve patches to reload."
And whom should such email be sent to? The SC is best reached on gcc@
but I don't think t
Adam Nemet wrote:
> Andrew Haley writes:
>> We need something more like "I think Fred Bloggs knows gcc well enough
>> to approve patches to reload" or "I am Fred Bloggs and I know gcc well
>> enough to approve patches to reload."
>
> And whom should such email be sent to? The SC is best reached
>Revital1 Eres writes:
>> Hello,
>>
>>> i386-pc-solaris:
>>>
>>> cc1: warnings being treated as errors
>>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In
function
>>> 'loop_prefetch_arrays':
>>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7:
error:
>>>
>>> forma
FWIW, I am not taking this question personally (I don't really claim
that I could become any kind of reviewer; I believe in general that
reviewing abilities should be evaluated by others.). I just think the
set of reviewers should significantly grow.
Andrew Haley wrote:
My feeling is on
My feeling is on the contrary that the set of people having a real
knowledge of gcc (or at least of substantial parts of it [*]) is much
bigger than the set of reviewers allowed to say OK.
That's certainly true, but there's a big difference between having real
knowledge of gcc and having enoug
On Tue, Jun 9, 2009 at 2:10 PM, Basile
STARYNKEVITCH wrote:
> FWIW, I am not taking this question personally (I don't really claim that I
> could become any kind of reviewer; I believe in general that reviewing
> abilities should be evaluated by others.). I just think the set of reviewers
> should
Basile STARYNKEVITCH wrote:
> FWIW, I am not taking this question personally (I don't really claim
> that I could become any kind of reviewer; I believe in general that
> reviewing abilities should be evaluated by others.). I just think the
> set of reviewers should significantly grow.
But that ne
It is my pleasure to announce that the steering committee is
appointing Anthony Green as maintainer of the new Moxie port
that has been approved from a technical perspective as well.
Please adjust the MAINTAINERS file accordingly, Anthony, and
happy hacking! And of course, go ahead and commit the
Andrew Haley wrote:
Basile STARYNKEVITCH wrote:
FWIW, I am not taking this question personally (I don't really claim
that I could become any kind of reviewer; I believe in general that
reviewing abilities should be evaluated by others.). I just think the
set of reviewers should significantly
On 06/09/09 16:17, Jason Merrill wrote:
> Bernie Innocenti wrote:
>> On 06/07/09 12:40, Ralf Wildenhues wrote:
>>> Is this mirror an independent conversion from the infradead one (i.e., I
>>> have to throw away the repo and re-download a full repo? Or can I reuse
>>> objects)?
>>
>> It's an inde
On Tue, Jun 09, 2009 at 10:54:06AM -0700, Adam Nemet wrote:
> Andrew Haley writes:
> > We need something more like "I think Fred Bloggs knows gcc well enough
> > to approve patches to reload" or "I am Fred Bloggs and I know gcc well
> > enough to approve patches to reload."
>
> And whom should su
Basile STARYNKEVITCH wrote:
> Andrew Haley wrote:
>> Basile STARYNKEVITCH wrote:
>>
>> This is going to sound rude, but if you don't know what reload is
>> you're not able to talk about gcc maintenance.
>
> Reload is probably in the register allocator, which indeed is in the
> backend part I know
While developing my plugin I've noticed that many callbacks need to be
guarded with "if (errorcount)" or the plugin will cause a gcc crash due
to receiving less complete data than it expected.
Should the plugin API guard callbacks in invoke_plugin_callbacks() to
avoid 99% of plugins running in
Taras Glek wrote:
While developing my plugin I've noticed that many callbacks need to be
guarded with "if (errorcount)" or the plugin will cause a gcc crash
due to receiving less complete data than it expected.
Should the plugin API guard callbacks in invoke_plugin_callbacks() to
avoid 99% of
Dear all,
I've moved forward on this issue. Again, the problem is not that the
data is not aligned but that the compiler tries to generate this
instruction:
(set (reg:HI 141) (mem/s/j:HI (plus:DI (reg:DI 134 [ ivtmp.23 ])
(const_int 1 [0x1])) [0 .geno+0 S2 A16]))
And, in my target archi
Basile,
You don't need to convince us that we need more reviewers. We all
agree on that. You simply need to suggest a reviewer for some set of
files that
- Knows that set of files very well
- Is familiar with GCC development
- Is willing to review patches and be a maintainer for those files
- H
On Tue, Jun 9, 2009 at 3:22 PM, Diego Novillo wrote:
> You'll quickly find out that this makes for a fairly small set of
> people. Long term, I don't think we would do us a service if we
> relaxed any of those requirements too much.
Excellent summary.
-- Gaby
"Arthur Haas" writes:
> Now that this patch has been commited, the build on i386-pc-solaris2.10
> succeeds when building tree-ssa-loop-prefetch.o file but fails later on:
>
> cc1: warnings being treated as errors
> /export/home/arth/gnu/gcc.git/gcc/gcc.c: In function 'compare_files':
> /export/ho
> "Basile" == Basile STARYNKEVITCH writes:
Basile> I believe I might even become in a few years some kind of
Basile> gcc/ggc*.[ch] secondary reviewer. I don't want to become one
Basile> (being a reviewer is probably more a burden than an honor, and
Basile> probably consume a lot of time, and
Basile STARYNKEVITCH writes:
> I am unfortunately not attending the GCC summit which happens right
> now in Montreal.
>
> But apparently, there seems to be a lack of code reviewers for
> GCC. The few people who do review code seems to have a lot of review
> in their batch queue.
>
> Perhaps could
On Tue, Jun 9, 2009 at 15:33, Taras Glek wrote:
> While developing my plugin I've noticed that many callbacks need to be
> guarded with "if (errorcount)" or the plugin will cause a gcc crash due to
> receiving less complete data than it expected.
More details please. What exactly is the error and
Jean Christophe Beyler wrote:
> Dear all,
>
> I've moved forward on this issue. Again, the problem is not that the
> data is not aligned but that the compiler tries to generate this
> instruction:
>
> (set (reg:HI 141) (mem/s/j:HI (plus:DI (reg:DI 134 [ ivtmp.23 ])
> (const_int 1 [0x1]))
Snapshot gcc-4.4-20090609 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090609/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
2009/6/9 Ian Lance Taylor:
>
> I believe that POSIX specifices that munmap takes a void * argument. Is
> there some preprocessor define we can use to direct the Solaris header
> files to compile in POSIX mode? If so, it should work to add it to
> CFLAGS (using +=) in TOPLEVEL/config/mh-solaris.
On Tue, Jun 9, 2009 at 3:16 PM, Bernie Innocenti wrote:
> On 06/09/09 16:17, Jason Merrill wrote:
>> Bernie Innocenti wrote:
>>> On 06/07/09 12:40, Ralf Wildenhues wrote:
Is this mirror an independent conversion from the infradead one (i.e., I
have to throw away the repo and re-download a
On Tue, 2009-06-09 at 19:00 +0100, Andrew Haley wrote:
> I think it's a much better idea to contact Fred (or Freda, for that matter)
> Bloggs to ask them if they want to maintain reload. :-)
Wouldn't it be Alan Smithee to maintain reload? :-)
Ben
Daniel Berlin writes:
> I don't see a problem doing this (we definitely don't want two
> versions installed), but there are real live git projects on
> sourceware so we should be a bit careful.
fche has already installed git 1.6.3.2 in /usr/local/bin on sourceware.
That is now the one you will g
On Tue, 2009-06-09 at 21:13 +0200, Basile STARYNKEVITCH wrote:
> This is precisely my point. It should be perfectly acceptable that some
> people be authorized to approve some few patches without understanding
> the whole of GCC, and even without knowing all of it.
I sympathise with this point
On Tue, 9 Jun 2009, Ian Lance Taylor wrote:
> I believe that the most useful immediate thing we could do to speed up
> gcc development would be to move to a distributed version control
> system.
We haven't even finished the last version control system transition
(wwwdocs is still using CVS), it'
I have a question for C++ language lawyers. The common part of the
C/C++ frontends has a global variable named skip_evaluation. Both
frontends set this variable while parsing an expression inside sizeof
and friends. This has the effect of disabling various warnings which
are irrelevant for code
i...@google.com wrote:
> Daniel Berlin writes:
>
> > I don't see a problem doing this (we definitely don't want two
> > versions installed), but there are real live git projects on
> > sourceware so we should be a bit careful.
>
> fche has already installed git 1.6.3.2 in /usr/local/bin on sou
"Joseph S. Myers" writes:
> At the human level I suspect it would help to have people who watch for
> submissions from non-regulars (including those attached to Bugzilla) and
> help them prepare patches following all the usual conventions and get them
> reviewed (checking for copyright assignm
> "Joseph" == Joseph S Myers writes:
Ian> I believe that the most useful immediate thing we could do to speed up
Ian> gcc development would be to move to a distributed version control
Ian> system.
Joseph> We haven't even finished the last version control system
Joseph> transition (wwwdocs is
Ben Elliston wrote:
> On Tue, 2009-06-09 at 19:00 +0100, Andrew Haley wrote:
>
>> I think it's a much better idea to contact Fred (or Freda, for that matter)
>> Bloggs to ask them if they want to maintain reload. :-)
>
> Wouldn't it be Alan Smithee to maintain reload? :-)
>
> Ben
Burn, Reloa
Diego Novillo wrote:
On Tue, Jun 9, 2009 at 15:33, Taras Glek wrote:
While developing my plugin I've noticed that many callbacks need to be
guarded with "if (errorcount)" or the plugin will cause a gcc crash due to
receiving less complete data than it expected.
More details please. Wh
On Tue, Jun 9, 2009 at 8:51 PM, Joseph S. Myers wrote:
> On Tue, 9 Jun 2009, Ian Lance Taylor wrote:
>
>> I believe that the most useful immediate thing we could do to speed up
>> gcc development would be to move to a distributed version control
>> system.
>
> We haven't even finished the last vers
> The problem may be in the dependency cost between the SET (insn 27)
> and the USE (insn 30) being >= 1. Have you tried using
> targetm.sched.adjust_cost() hook to set the cost of USE to 0?
It doesn't get called for those two insns.
> Anyway, this seems strange, the scheduler should just outpu
Some progress... the scheduler is willing to schedule them together if
I define the SCHED_REORDER2 hook (just SCHED_REORDER was
insufficient), and always return the number of ready insns. In my
case, the VLIW packing restrictions are fully defined by a DFA; I
don't need to further restrict packin
Dennis Clarke wrote:
Re: http://gcc.gnu.org/gcc-4.3/buildstat.html
I was looking for testsuite results to compare with on Solaris and I saw
that nearly every report for GCC 4.3.3 was done by Tom G. Christensen.
All GCC 4.3.3 reports on Solaris from one person :
You better get cracking on 4.4
Gerald Pfeifer wrote:
It is my pleasure to announce that the steering committee is
appointing Anthony Green as maintainer of the new Moxie port
that has been approved from a technical perspective as well.
Please adjust the MAINTAINERS file accordingly, Anthony, and
happy hacking! And of course,
55 matches
Mail list logo
