Sorry for this off-topic.
I did not tell it is a conspiracy. I only found this funny.
Thanks,
Kirill
2009/4/21 Bill Wendling :
> On Mon, Apr 20, 2009 at 1:34 PM, Kirill Kononenko
> wrote:
>> Hello
>>
>>
>> So how did it happen that the only project which was a candidate for
>> libJIT Summer of
房陈 writes:
> I really want to how does gcc compile code like *(ptr base +
> offset), where ptr base is the initial address of a pointer variable
> and offset is any legal integer expression. There is a example here:
>
> int i = 1;
> int j = 1;
> int *buf = (int*)malloc(10 *sizeof(
Ian Lance Taylor wrote:
Vlad, I noticed that the code in setup_cover_and_important_classes in
ira.c does #ifdef CONSTRAINT__LIMIT. However, CONSTRAINT__LIMIT is not
a preprocessor macro; it is an enum constant defined in the generated
file tm-preds.h. I think that the code within the #ifdef is
This is typical of the types of failures m32c got before IRA, too. I
had a good build on Feb 19th, but if I try to reproduce it, it fails
too.
Fails with -O2, works with -Os. Note: you might need -fno-ivopts to
get around the recent m32c/IV problems.
Any ideas? Any thoughts on why gcc has so
Hi!
I really want to how does gcc compile code like *(ptr base +
offset), where ptr base is the initial address of a pointer variable
and offset is any legal integer expression. There is a example here:
int i = 1;
int j = 1;
int *buf = (int*)malloc(10 *sizeof(int));
*(buf + i +
On Mon, 20 Apr 2009, Andrew Pinski wrote:
> On Mon, Apr 20, 2009 at 2:30 PM, Ian Lance Taylor wrote:
> > I have not fixed every gcc backend to compile without producing any of
> > the new warnings. I have fixed some: arm, i386, ia64, mips, pa, rs6000,
> > s390, sparc, spu. This covers all the p
Vlad, I noticed that the code in setup_cover_and_important_classes in
ira.c does #ifdef CONSTRAINT__LIMIT. However, CONSTRAINT__LIMIT is not
a preprocessor macro; it is an enum constant defined in the generated
file tm-preds.h. I think that the code within the #ifdef is either
unnecessary or is n
On Mon, Apr 20, 2009 at 2:30 PM, Ian Lance Taylor wrote:
> I have not fixed every gcc backend to compile without producing any of
> the new warnings. I have fixed some: arm, i386, ia64, mips, pa, rs6000,
> s390, sparc, spu. This covers all the primary and secondary platforms,
> plus spu which I
Last week I committed a patch to check for enum comparisons which are
invalid in C++. Today I committed a patch to check for enum conversions
during function calls which are invalid in C++. These new warnings are
enabled by -Wc++-compat.
I have not fixed every gcc backend to compile without prod
On Mon, Apr 20, 2009 at 1:34 PM, Kirill Kononenko
wrote:
> Hello
>
>
> So how did it happen that the only project which was a candidate for
> libJIT Summer of Code in GNU, with the same title got selected in
> LLVM?
>
>
> Does it mean that the same genius idea came to two minds?
>
No. It's a consp
On Mon, Apr 20, 2009 at 01:34:15PM -0700, Kirill Kononenko wrote:
> So how did it happen that the only project which was a candidate for
> libJIT Summer of Code in GNU, with the same title got selected in
> LLVM?
You can ask the Google folks that question, but it's off-topic for the GCC
list.
Hello
So how did it happen that the only project which was a candidate for
libJIT Summer of Code in GNU, with the same title got selected in
LLVM?
Does it mean that the same genius idea came to two minds?
Thanks,
Kirill
--
http://code.google.com/p/libjit-linear-scan-register-allocator/
On Mon, 2009-04-20 at 14:55 -0400, Geert Bosch wrote:
> > For an invocation
> > gnat1 a.adb b.adb c.adb
> > , the files a.{s,ali} b.{s,ali} c.{s,ali} are produced.
>
> The back end is not prepared to produce multiple assembly files.
> The "gcc" driver program also assumes each invocation produces
This is the beta release of binutils 2.19.51.0.4 for Linux, which is
based on binutils 2009 0418 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Apr 20, 2009, at 14:45, Oliver Kellogg wrote:
It would be best to first contemplate what output a single
invocation of the compiler, with multiple compilation units
as arguments, should produce.
For an invocation
gnat1 a.adb b.adb c.adb
, the files a.{s,ali} b.{s,ali} c.{s,ali} are produced
> Ok, I'll try to look at that. Is there an area where I can see how to
> initialize the framework and get information about which registers are
> free?
The API is in df.h, see for example ifcvt.c.
--
Eric Botcazou
Hi Geert,
Thanks for your answer - I was starting to feel I'm entertaining a
monologue here ;)
On Mon, 2009-04-20 at 13:05 -0400, Geert Bosch wrote:
>
> While this may be an interesting idea, there are some fundamental
> assumptions in the compiler that each compilation indeed processes
> a sin
> You should use the DF framework in 4.3.x and later.
Ok, I'll try to look at that. Is there an area where I can see how to
initialize the framework and get information about which registers are
free?
Right now, I'm looking in combine.c to see how they are using it. Any
insight would be useful,
> Ok, so if I copy the locally allocated registers into N consecutive
> hard registers BEFORE the group of loads, then rerun cprp_harderg, it
> should replace the ones of the loads to the ones of the copies ? And
> then I suppose the copies will just disappear at a later pass, correct
> ?
Somethin
> The reorg pass runs after register allocation.
> You could try to identify consecutive loads within basic blocks, group them
That is not too difficult, I've written a pass that checks for that
and identifies the loads.
- and rename registers or add
> copy insns to be able replace them with mul
> Does any architecture do such a "machine-specific reorg" pass. I've
> looked around and haven't really seen one.
IA-64 has one, to build bundles; it reuses the scheduler.
> Could you give me an idea of where to look and how exactly that would work?
The reorg pass runs after register allocation
On Apr 12, 2009, at 13:29, Oliver Kellogg wrote:
On Tue, 4 Mar 2003, Geert Bosch wrote:
[...]
Best would be to first post a design overview,
before doing a lot of work in order to prevent spending time
on implementing something that may turn out to have fundamental
problems.
I've done a lit
On Mon, Apr 20, 2009 at 1:33 PM, fearyourself wrote:
>
> For the moment, we will be remaining in the 4.3.2 version and have no
> plans to follow the next 4.4/4.5 versions.
>
> Does any architecture do such a "machine-specific reorg" pass. I've
> looked around and haven't really seen one. Could you
For the moment, we will be remaining in the 4.3.2 version and have no
plans to follow the next 4.4/4.5 versions.
Does any architecture do such a "machine-specific reorg" pass. I've
looked around and haven't really seen one. Could you give me an idea
of where to look and how exactly that would work
> This is a little bit simpler than what you find in find_free_reg. Any
> comments/suggestions at this point?
The local register allocator (local-alloc.c) has been removed in the upcoming
4.4.x series of compilers so you might want to try something else. Doing it
during register allocation seems
On 2009-04-20 10:04:00 -0400, Joern Rennecke wrote:
>> As the bug occurs only when malloc is in the tested function,
>
> Note that gcc 'knows' that memory obtained by malloc does not
> alias other memory.
Yes, in the case of GMP, this was a GMP internal function, not malloc,
but this function is d
As the bug occurs only when malloc is in the tested function,
Note that gcc 'knows' that memory obtained by malloc does not
alias other memory.
You can use a differently named wrapper function for malloc,
or use the malloc attribute for another function, to experiment
how this affects code gene
Ok, I've move forward in this problem by identifying the loads I want
to suggest hard registers for and I've inspired myself with code in
combine_regs and finally have tried this:
/* Suggest pseudo register to hard register */
s_qtyno=reg_qty[pseudo];
if (s_qtyno >= 0) {
On 2009-04-20 00:30:21 -0700, James Dennett wrote:
> 2009/4/19 Jason Mancini :
> >
> >> Vincent Lefevre writes:
> >> while ((*(q++))-- == 0) ;
> >
> > Is that defined and legal?? Is q incremented before or after *q
> > is decremented? They are both post operators!
>
> It's defined and legal
On 2009-04-17 12:09:42 -0500, Gabriel Dos Reis wrote:
> At least, let's get it archived on GCC mailing lists.
Is it a bug that has been identified? If not, perhaps this should
be added to the regression tests.
The program without the quotes:
/* With GCC 4.3.2 and -O2 option: output value is 1 in
2009/4/20 Jan Hubicka :
>> On Mon, Apr 20, 2009 at 8:29 AM, Paolo Bonzini wrote:
>> > Dave Korn wrote:
>> >> Richard Guenther wrote:
>> >>
>> >>> Well ... in this case it's likely the problem that propagate_with_phi is
>> >>> inlined (single-use static function) and maybe other helpers of it too.
> On Mon, Apr 20, 2009 at 8:29 AM, Paolo Bonzini wrote:
> > Dave Korn wrote:
> >> Richard Guenther wrote:
> >>
> >>> Well ... in this case it's likely the problem that propagate_with_phi is
> >>> inlined (single-use static function) and maybe other helpers of it too.
> >>
> >> It is inlined. I
Hi!
The 4.4 branch is now frozen, all commits to it require explicit RM approval.
If there is anything that should block the 4.4 release, please CC me on it,
otherwise I plan to create the 4.4.0 release tomorrow.
Jakub
> Feel free to post patches replacing the various similar walks with
> the above pattern (or add a FOR_EACH_BB_IN_DOM_ORDER
> that does it, possibly with a BREAK_FROM_ that frees the
> VEC used for the worklist).
>
> grep next_dom_son *.c
>
> only finds 22 possible uses of the above pattern.
On Mon, Apr 20, 2009 at 8:29 AM, Paolo Bonzini wrote:
> Dave Korn wrote:
>> Richard Guenther wrote:
>>
>>> Well ... in this case it's likely the problem that propagate_with_phi is
>>> inlined (single-use static function) and maybe other helpers of it too.
>>
>> It is inlined. I rebuilt jc1 afte
On Sun, Apr 19, 2009 at 7:19 PM, James Dennett wrote:
> On Sun, Apr 19, 2009 at 4:15 PM, Paolo Piacentini
> wrote:
>> I don't think this is a bug but certainly it is a problem.
>>
>> Would you please consider it and let me know? I hope so. Thanks.
>>
>> The following simple volcalc.cpp code compi
2009/4/19 Jason Mancini :
>
>> Vincent Lefevre writes:
>> while ((*(q++))-- == 0) ;
>
> Is that defined and legal?? Is q incremented before or after *q is
> decremented? They are both post operators!
> Jason Mancini
It's defined and legal (so long as q != &q, which might well be
guaranteed
37 matches
Mail list logo
