* Jeff Law:
> At least for Linux systems, the bootstrapping problem is largely a
> solved problem by the major vendors.
Debian is special because GNAT is typically built from a different GCC
release than the rest of the distribution because two Ada transitions
in a single release cycle are a bit
On Tue, Nov 12, 2013 at 9:52 PM, Diego Novillo wrote:
> On Tue, Nov 12, 2013 at 3:35 PM, Jakub Jelinek wrote:
>
>> Note that we have tons of code which accept either objects or types,
>> both in the frontends and in the middle-end, so changing TREE_TYPE
>> from tree to something else is definitel
On Tue, Nov 12, 2013 at 10:25 PM, Jeff Law wrote:
> On 11/12/13 13:35, Jakub Jelinek wrote:
>>
>> On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote:
>>>
>>> So I lost something like 3 hrs last night due to writing a hunk of
>>> code like this
>>>
>>> if (INTEGRAL_TYPE_P (gimple_assign_lhs (
On Wed, Nov 13, 2013 at 12:30 AM, Steven Bosscher wrote:
> Hello,
>
> Here is a non-comprehensive list of macros that are used with a
> function passed to the macro's argument, and the macro evaluates that
> argument at least twice:
>
> gimple.c: && (CONVERT_EXPR_CODE_P (gimple_assign_rhs
On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
> Well, he doesn't even consider that the exact same "tree rant" applies
> to frontend code.
That's not entirely true, either. Most front ends already use their
own IL in the parser (only C++ uses 'tree' for everything).
What worries me most
On Wed, Nov 13, 2013 at 11:15 AM, Richard Biener wrote:
> You know - 'tree's were a design decision (well, just my guess - I wasn't
> around 25 years ago ...). They are a perfect match to represent an AST.
I'd argue against that, but perhaps some other time, in a different thread...
> So I'd sa
On Wed, Nov 13, 2013 at 11:49:56AM +0100, Steven Bosscher wrote:
> source language? That's still true, and one reason for it is 'tree'.
> The Ada, Fortran, and even C front ends use front-end specific data
> structures for most parsed entities and only produce 'tree' from it in
> the process of gen
On Mon, Nov 11, 2013 at 10:27 PM, Matthias Klose wrote:
> Am 11.11.2013 11:06, schrieb Andrew Haley:
>> On 11/11/2013 03:22 AM, Jeff Law wrote:
>>> On 11/09/13 08:55, Andrew Haley wrote:
On 11/09/2013 03:44 PM, Alec Teal wrote:
> If Java must go, and it must have a replacement Ada makes s
On Wed, Nov 13, 2013 at 7:50 AM, Jeff Law wrote:
> On 11/12/13 01:27, Eric Botcazou wrote:
>>>
>>> From what I can see, bootstrapping with Ada is slower than bootstapping
>>> with Java, by around 15%. Again this is on one of my slower boxes, but
>>> the results clearly show building Ada & its ru
On 11/13/2013 10:56 AM, Richard Biener wrote:
> At least we don't need a Java source code frontend, no? Just keeping
> the bytecode compiler and GIJ should be enough? That way we can
> strip the classpath copy of everything that isn't needed, thus not
> provide a Java library. Reduces testing co
On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
> On 11/13/2013 10:56 AM, Richard Biener wrote:
>> At least we don't need a Java source code frontend, no? Just keeping
>> the bytecode compiler and GIJ should be enough? That way we can
>> strip the classpath copy of everything that isn't ne
On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher wrote:
> On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
>> Well, he doesn't even consider that the exact same "tree rant" applies
>> to frontend code.
>
> That's not entirely true, either. Most front ends already use their
> own IL in the
On 11/13/2013 11:29 AM, Richard Biener wrote:
> On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
>> On 11/13/2013 10:56 AM, Richard Biener wrote:
>>> At least we don't need a Java source code frontend, no? Just keeping
>>> the bytecode compiler and GIJ should be enough? That way we can
>>>
> Eric, would emitting GIMPLE from gigi make that a lot more
> complicated? That is, would you prefer to have an even
> higher-level early GIMPLE (considering stuff like TARGET_EXPR
> and WITH_CLEANUP_EXPR, etc.)?
This would mean privatizing in gigi all the machinery needed to support types
with
On Wed, Nov 13, 2013 at 5:10 AM, Richard Biener
wrote:
> Thus "fixing" trees would be far better as you'd win for both frontend
> and middle-end code!
For FEs, sure. I agree. But right now the focus is on fixing the
interface between FEs and the ME. One thing at a time.
Finally separating FE
On Wed, Nov 13, 2013 at 5:15 AM, Richard Biener
wrote:
> You know - 'tree's were a design decision (well, just my guess - I wasn't
> around 25 years ago ...). They are a perfect match to represent an AST.
Yes, of course. It may have been the right decision at the time. But
design is a dynamic
On Wed, Nov 13, 2013 at 5:37 AM, Steven Bosscher wrote:
> Really the best place to start IMHO would be to evict 'tree' from the
> front ends. That would really be a step towards making the front ends
> independent of the rest of the compiler, and it would simplify changes
> towards static 'tree'
On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
> On 11/13/2013 11:29 AM, Richard Biener wrote:
>> On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
>>> On 11/13/2013 10:56 AM, Richard Biener wrote:
At least we don't need a Java source code frontend, no? Just keeping
the byte
On Wed, Nov 13, 2013 at 1:07 PM, Eric Botcazou wrote:
>> Eric, would emitting GIMPLE from gigi make that a lot more
>> complicated? That is, would you prefer to have an even
>> higher-level early GIMPLE (considering stuff like TARGET_EXPR
>> and WITH_CLEANUP_EXPR, etc.)?
>
> This would mean priva
On 11/13/2013 12:37 PM, Richard Biener wrote:
> On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
>> On 11/13/2013 11:29 AM, Richard Biener wrote:
>>> On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
On 11/13/2013 10:56 AM, Richard Biener wrote:
> At least we don't need a Java s
On Wed, Nov 13, 2013 at 1:51 PM, Andrew Haley wrote:
> On 11/13/2013 12:37 PM, Richard Biener wrote:
>> On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
>>> On 11/13/2013 11:29 AM, Richard Biener wrote:
On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
> On 11/13/2013 10:56 AM,
On Wed, Nov 13, 2013 at 2:00 PM, Richard Biener
wrote:
> On Wed, Nov 13, 2013 at 1:51 PM, Andrew Haley wrote:
>> On 11/13/2013 12:37 PM, Richard Biener wrote:
>>> On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
On 11/13/2013 11:29 AM, Richard Biener wrote:
> On Wed, Nov 13, 2013 a
On Wed, Nov 13, 2013 at 02:01:52PM +0100, Richard Biener wrote:
> >> Really? Wouldn't it make more sense for people to check out what they
> >> need? Is this a mayor issue?
> >
> > It was one of the major complaints we received when dropping the
> > split of the distributed tarballs, that is, no
On Wed, 13 Nov 2013, Eric Botcazou wrote:
> > Eric, would emitting GIMPLE from gigi make that a lot more
> > complicated? That is, would you prefer to have an even
> > higher-level early GIMPLE (considering stuff like TARGET_EXPR
> > and WITH_CLEANUP_EXPR, etc.)?
>
> This would mean privatizing
On Wed, Nov 13, 2013 at 8:25 AM, Joseph S. Myers
wrote:
> assignment in general to fix bug 58943. I'd be happy for front ends to
> move to doing all these things themselves, rather than trying to define
> GENERIC in a way that works for every language's requirements on when
> things are evaluate
On 11/13/2013 01:22 PM, Jakub Jelinek wrote:
> On Wed, Nov 13, 2013 at 02:01:52PM +0100, Richard Biener wrote:
Really? Wouldn't it make more sense for people to check out what they
need? Is this a mayor issue?
>>>
>>> It was one of the major complaints we received when dropping the
>>>
On Wed, Nov 13, 2013 at 2:37 PM, Andrew Haley wrote:
> On 11/13/2013 01:22 PM, Jakub Jelinek wrote:
>> On Wed, Nov 13, 2013 at 02:01:52PM +0100, Richard Biener wrote:
> Really? Wouldn't it make more sense for people to check out what they
> need? Is this a mayor issue?
It was o
On Wed, Nov 13, 2013 at 3:06 AM, Richard Biener
wrote:
>
> Well, I'm thinking that waiting time is not so much of an issue (you
> can interleave other work). People not testing all languages and
> breaking bootstrap for others is the problem (that includes dropping
> in not tested libgo updates -
On Wed, Nov 13, 2013 at 5:30 AM, Diego Novillo wrote:
> On Wed, Nov 13, 2013 at 8:25 AM, Joseph S. Myers
> wrote:
>
>> assignment in general to fix bug 58943. I'd be happy for front ends to
>> move to doing all these things themselves, rather than trying to define
>> GENERIC in a way that works
Hi,
I am seeing a strange phenomenon on GCC 4.8 which I can't understand. I tested
this with v850 and mep, obtaining the same results (compiling with -O2).
With loop-1.c:
extern int *c;
void fn1 (unsigned int b)
{
unsigned int a;
for (a = 0; a < b; a++)
*c++ = 0;
}
both v850 (requires
On 11/13/2013 03:48 PM, Paulo Matos wrote:
> I cannot understand GCC's reasoning that the second loop is not
> simple. The only source code difference is that unsigned int b is
> extern. However, it will always be higher than 'a' (unsigned int)
> and the loop can't possibly be infinite.
>
> Does
> "Richard" == Richard Biener writes:
Richard> Whatever the "core language runtime" would be - I'm somewhat a
Richard> Java ignorant.
The core is quite large, unless you are also willing to track through
all the code and chop out the bits you don't want for testing. This
would mean having a
On Wed, 13 Nov 2013, Steven Bosscher wrote:
> Really the best place to start IMHO would be to evict 'tree' from the
> front ends. That would really be a step towards making the front ends
> independent of the rest of the compiler, and it would simplify changes
> towards static 'tree' types.
From
> "Jeff" == Jeff Law writes:
Jeff> Given the problems Ian outlined around adding Go to the default
Jeff> languages and the build time issues with using Ada instead of Java,
Jeff> I'm unsure how best to proceed.
IIRC from upthread the main reason to keep one of these languages is
-fnon-call-e
> -Original Message-
> From: Andrew Haley [mailto:a...@redhat.com]
> Sent: 13 November 2013 15:56
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> On 11/13/2013 03:48 PM, Paulo Matos wrote:
>
> Because GCC does not know that *c++
> "Steven" == Steven Bosscher writes:
Steven> Here is a non-comprehensive list of macros that are used with a
Steven> function passed to the macro's argument, and the macro evaluates that
Steven> argument at least twice:
[...]
Steven> Not sure what to do about them (if anything) but I don't t
On 11/13/13 09:00, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> Given the problems Ian outlined around adding Go to the default
Jeff> languages and the build time issues with using Ada instead of Java,
Jeff> I'm unsure how best to proceed.
IIRC from upthread the main reason to keep one
On Wed, 13 Nov 2013, Steven Bosscher wrote:
Here is a non-comprehensive list of macros that are used with a
function passed to the macro's argument, and the macro evaluates that
argument at least twice:
Note that in your list the macro argument is almost always a simple static
inline function
On 11/13/13 08:59, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Steven Bosscher wrote:
Really the best place to start IMHO would be to evict 'tree' from the
front ends. That would really be a step towards making the front ends
independent of the rest of the compiler, and it would simplify change
Hello,
I would like to propose the activation by default of -Wreturn-type.
The main objective would to provide a warning for such code:
int foo() {
return;
}
For now, it is only enabled when we have -Wall:
$ gcc -c foo.c
$ gcc -Wall -c foo.c
foo.c: In function ‘foo’:
foo.c:2:2: warning:
On Wed, 13 Nov 2013, Jeff Law wrote:
> On 11/13/13 08:59, Joseph S. Myers wrote:
> > On Wed, 13 Nov 2013, Steven Bosscher wrote:
> >
> > > Really the best place to start IMHO would be to evict 'tree' from the
> > > front ends. That would really be a step towards making the front ends
> > > indepe
On Wed, Nov 13, 2013 at 04:43:45PM +, Joseph S. Myers wrote:
> On Wed, 13 Nov 2013, Jeff Law wrote:
>
> > On 11/13/13 08:59, Joseph S. Myers wrote:
> > > On Wed, 13 Nov 2013, Steven Bosscher wrote:
> > >
> > > > Really the best place to start IMHO would be to evict 'tree' from the
> > > > fro
On 11/13/13 09:43, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Jeff Law wrote:
On 11/13/13 08:59, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Steven Bosscher wrote:
Really the best place to start IMHO would be to evict 'tree' from the
front ends. That would really be a step towards making th
On Wed, 13 Nov 2013, Jakub Jelinek wrote:
> Note, in many cases, removing optimizations from fold-const.c leads to
> regressions on code assuming something is folded (especially in
> initializers). Sure, that is all typically undocumented GNU extensions,
> but we had several such problems in the
> Yeah, that's why I am asking. I suppose you are refering to
> gimplify_type_sizes and the required lowering of ARRAY_REFs and
> COMPONENT_REFs? Yes, I'd not make them first class citizens
> in the GIMPLE that the optimizers see but I'm fine with having
> high-GIMPLE support for them, doing a lo
> Other places where GENERIC provides something that no doubt seemed
> convenient originally, but is less useful when you want to ensure things
> are evaluated at exactly the time implied by language semantics, include
> SAVE_EXPRs and pre/post increment/decrement.
I'm a little skeptical here beca
On 11/13/13 03:15, Richard Biener wrote:
You know - 'tree's were a design decision (well, just my guess - I wasn't
around 25 years ago ...). They are a perfect match to represent an AST.
So I'd say whoever introduced that middle-end between the FEs AST
and RTL was at fault :P (luckily I wasn't
On 11/13/13 04:06, Richard Biener wrote:
Well, I'm thinking that waiting time is not so much of an issue (you
can interleave other work). People not testing all languages and
breaking bootstrap for others is the problem (that includes dropping
in not tested libgo updates - a reason why I never
Richard Biener writes:
> On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher
> wrote:
>> On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
>>> Well, he doesn't even consider that the exact same "tree rant" applies
>>> to frontend code.
>>
>> That's not entirely true, either. Most front ends
On 11/13/13 05:51, Andrew Haley wrote:
I also want to reduce repository size by removing parts of (or you
say all of?) classpath, retaining only those portions we need for
bootstrap & regtest.
Really? Wouldn't it make more sense for people to check out what they
need? Is this a mayor issue?
On Wed, 13 Nov 2013, Gaius Mulley wrote:
> just for completeness this also applies to Modula-2 which uses the
> technique of double book keeping. Not sure if this is totally relevant
> but gm2 needs (would like :-) the ability to create a SET_TYPE which
> maps onto appropriate debugging type info
On 11/13/13 11:30, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Gaius Mulley wrote:
just for completeness this also applies to Modula-2 which uses the
technique of double book keeping. Not sure if this is totally relevant
but gm2 needs (would like :-) the ability to create a SET_TYPE which
maps
> Across 10 runs we came in right at 70 minutes with the usual ~20 second
> variance. So it's slightly slower than the default languages right now.
> That doesn't help the cycle time for developers which was the major
> point for me.
Your results still look a little strange to me...
> As for Ada
Jeff Law writes:
> On 11/13/13 11:30, Joseph S. Myers wrote:
>> On Wed, 13 Nov 2013, Gaius Mulley wrote:
>>
>>> just for completeness this also applies to Modula-2 which uses the
>>> technique of double book keeping. Not sure if this is totally relevant
>>> but gm2 needs (would like :-) the abil
Hi, I have set up new mirrors for GCC for the following locations:
+ Mirrors Taiwan:
http://mirrors.go-parts.com/crux/
ftp://mirrors.go-parts.com/crux/
rsync://mirrors.go-parts.com/mirrors/crux/
+ Mirrors-usa:
http://mirrors-usa.go-parts.com/crux/
ftp://mirrors-usa.go-par
On 11/13/13 12:33, Gaius Mulley wrote:
I'd be delighted to see gm2 in the gcc repository. The gm2 repository
is currently in git format (changed from cvs 2 weeks ago). All fsf
copyright assignment forms have been done some years ago.
At present the gm2 master can be grafted onto gcc-4.7.3 wit
On 11/13/13 11:55, Eric Botcazou wrote:
Across 10 runs we came in right at 70 minutes with the usual ~20 second
variance. So it's slightly slower than the default languages right now.
That doesn't help the cycle time for developers which was the major
point for me.
Your results still look a li
On Wed, 13 Nov 2013, Gaius Mulley wrote:
> >> In general, for GCC development to consider requirements of your front end
> >> or back end, getting it into the GCC repository and developing it there is
> >> strongly recommended.
> > Sadly, I tried multiple times in the late 90s to bring the folks g
"Joseph S. Myers" writes:
> On Wed, 13 Nov 2013, Gaius Mulley wrote:
>
>> >> In general, for GCC development to consider requirements of your front end
>> >> or back end, getting it into the GCC repository and developing it there is
>> >> strongly recommended.
>> > Sadly, I tried multiple times i
In case it is determined that a frame pointer is needed (in reload?),
who is supposed to make sure that the register that will hold the
frame pointer is not allocated for general use? We have a customized
register allocation mechanism, but I am trying to figure out /
understand the regular/general
On Wed, Nov 13, 2013 at 4:29 PM, Hendrik Greving
wrote:
> In case it is determined that a frame pointer is needed (in reload?),
> who is supposed to make sure that the register that will hold the
> frame pointer is not allocated for general use? We have a customized
> register allocation mechanism
> > So, given all that, is there any way to add the "target-specific
> > size_t" portion without waiting for-who-knows-how-long for the intN_t
> > and enum-size-type projects to finish? Some form of interim API that
> > we can put in, so that we can start working on finding all the
> > assumption
62 matches
Mail list logo
