On 29/10/2010 02:31, Ian Lance Taylor wrote:
> Dave Korn
>> What would be even nicer would be if we could share the same code-reader
>> interface between lto and go (and the lto-plugin), thereby getting object
>> format independence equally everywhere for no extra cost.
>
> How about this?
I know this sounds like it might be better answered in gcc-help, but
if I am right this is a bug report.
I'm using gcc 4.5 branch, rev. 165881 (a week old), on x86-64 Linux.
This testcase is derived from a larger program. I have looked at the
assembly and was puzzled.
#include
#include
int ma
On 29 Oct 2010, at 09:56, Dave Korn wrote:
This implements an object file reader/writer which does everything
required by LTO and gccgo. The ELF code works. I have not tested
the
Mach-O and COFF code at all beyond compiling it; I hope that somebody
else can test those targets and fix them.
On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote:
> On 29/10/2010 02:31, Ian Lance Taylor wrote:
> > Dave Korn >
> >> What would be even nicer would be if we could share the same code-reader
> >> interface between lto and go (and the lto-plugin), thereby getting object
> >> format inde
On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> What would be even nicer would be if we could share the same code-reader
>> interface between lto and go (and the lto-plugin), thereby getting object
>> format independence equally everywhere for no extra cost.
>
On 29/10/2010 14:31, Richard Guenther wrote:
> On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor wrote:
>> This patch requires approval from the LTO maintainers. I don't need
>> approval for the libiberty changes (if the code stays in libiberty) but
>> of course I would appreciate it if somebody
On 29/10/2010 14:18, Jack Howarth wrote:
> On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote:
>> On 29/10/2010 02:31, Ian Lance Taylor wrote:
>>> Dave Korn >>
What would be even nicer would be if we could share the same code-reader
interface between lto and go (and the lto-plugi
Jack Howarth writes:
>Doesn't the go compiler require functional split stack support? Mike Stump
> left me with the impression that split stack support would require additional
> linker support on darwin.
The Go compiler can work without split stack support. The effect is
that you are limit
roy rosen writes:
> How are they split before register allocation or scheduling. We've
> said that in any case only the combiner does the splitting.
No, we haven't said that. Or, if we did, we made a mistake. The
documentation I see says "There are two cases where you should specify
how to spl
Hi
I am working on a tool for building all the possible variants of C
code form the unpreprocessed file in order to perform an analysis on
those files proving some sort of correctness. The idea is to make sure
that any combination of preprocessor flags would produce a correct (in
terms of some too
On Fri, Oct 29, 2010 at 06:49:51AM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> >Doesn't the go compiler require functional split stack support? Mike
> > Stump
> > left me with the impression that split stack support would require
> > additional
> > linker support on darwin.
>
On 10/28/2010 6:31 PM, Ian Lance Taylor wrote:
> This patch requires approval from the LTO maintainers. I don't need
> approval for the libiberty changes (if the code stays in libiberty) but
> of course I would appreciate it if somebody could look it over. I think
> the configure and Makefile ch
Zeev Tarantov writes:
> I know this sounds like it might be better answered in gcc-help, but
> if I am right this is a bug report.
You can send bug reports to gcc-help also.
For this case please file an optimization bug report at
http://gcc.gnu.org/bugzilla with your test case. Indicate the ex
Jack Howarth writes:
>Is split stack support unique to the go compiler or might it eventually
> be leveraged in the other compilers as well? We could submit a radar for
> the addition of split stack support for the linker in Xcode 4.0 or later
> but it would helpful if the eventual usage was
Paolo Bonzini schrieb:
> On 10/28/2010 03:10 PM, Georg Lay wrote:
>> Georg Lay schrieb:
>>
>>> This code is not nice.
>>>
>>> ;; d8 = d4 * d6
>>> ;; d8 = d2
>>> ;; d2 = d8
>>> ;; return d2
>>
>> this should be
>>
>> ;; d2 = d4 * d6
>> ;; d8 = d2
>> ;; d2 = d8
>> ;; return d2
>
> It seems to me tha
On 10/29/2010 05:08 PM, Georg Lay wrote:
As far as I understand the internals, peephole2 matches due to predicates and
condition, it does not care for constraints (except for optional match_scratch)
Yes, I was referring as "using constraints in the define_insn". But
you're dong that as far as
Artem Shinkarov writes:
> That is why now I want to use a gcc code-base for solving the same
> task. And the main problem for me at the moment is to build a cpp
> binary which would be able to handle options for preprocessor but
> which would not pull so many code from middleend and backend. In o
On Fri, Oct 29, 2010 at 4:21 PM, Ian Lance Taylor wrote:
> Artem Shinkarov writes:
>
>> That is why now I want to use a gcc code-base for solving the same
>> task. And the main problem for me at the moment is to build a cpp
>> binary which would be able to handle options for preprocessor but
>> w
On Fri, 29 Oct 2010 16:45:43 +0100
Artem Shinkarov wrote:
>
> Yes, you are right the goals are of course separable but my concern is
> the following. All that I want to implement is a different behaviour
> for handling conditional an macros. So basically all the modifications
> are on the side of
Paolo Bonzini schrieb:
> On 10/29/2010 05:08 PM, Georg Lay wrote:
>> As far as I understand the internals, peephole2 matches due to
>> predicates and
>> condition, it does not care for constraints (except for optional
>> match_scratch)
>
> Yes, I was referring as "using constraints in the define_i
On 10/29/2010 06:18 PM, Georg Lay wrote:
(define_split
[(set (match_operand:SI 0 "register_operand" "")
(and:SI (match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "const_int_operand" "")))
(clobber (match_operand:SI 3 "register_operand" ""
Hi Fred,
> If you have access to a lm32 toolchain, can you test if gcc.c-
> torture/execute/built-in-setjmp.c passes at different optimization levels?
For a SVN snapshot from yesterday, patched so it fixes the problem Nathan
mentioned:
FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -
I have collected most papers and presentations for this year's GCC
summit at http://gcc.gnu.org/wiki/summit2010
Authors: please check and make sure that I uploaded the right content.
If you find a problem and can edit the wiki, please fix it yourself.
If not, contact me and I will fix it for you.
Artem Shinkarov writes:
> So my idea is to create just a light version of cpp binary. I'm not
> saying that we need to replace an existing approach of preprocessing
> used in gcc (cpp is basically "gcc -E"). I'm just saying that it could
> be a nice thing to have.
>
> I am ready to do that in ter
I see documentation for TARGET_VALID_POINTER_MODE, and I see ports that define
it... but I don't see any code that uses it.
Did I miss it?
paul
On Fri, Oct 29, 2010 at 2:28 PM, Paul Koning wrote:
> I see documentation for TARGET_VALID_POINTER_MODE, and I see ports that
> define it... but I don't see any code that uses it.
Ok, there are two issues it seems. First it is used in target.def:
/* True if MODE is valid for a pointer in __attr
dear gcc programers:
I tried to use math lib's power by the following simple code
(actually I copy from
http://www.java2s.com/Code/C/Math/Howtousepow.htm
that site show this code should run, but I get compiler error about not define
pow, please help, Eric, in 4.4.3
-
e...@
> that site show this code should run, but I get compiler error
Actually you get a *linker* (ie, ld) error. Try adding -lm to the command line.
Paolo
Ps: in the future please prefer gcc-help...
Paolo Bonzini writes:
> On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
>> configure.ac
>>Add libgo. If building Go, build C++ as a boot language.
>
> Can you generalize this using something in gcc/go/config-lang.in?
I have now done this on the gccgo branch. If language X's
config-lang.in
On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote:
> Paolo Bonzini writes:
>
>> On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
>>> configure.ac
>>> Add libgo. If building Go, build C++ as a boot language.
>>
>> Can you generalize this using something in gcc/go/config-lang.in?
>
> I hav
"H.J. Lu" writes:
> On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote:
>> Paolo Bonzini writes:
>>
>>> On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
configure.ac
Add libgo. If building Go, build C++ as a boot language.
>>>
>>> Can you generalize this using something in gcc
Quoting Mohamed Shafi :
On 29 October 2010 00:06, Joern Rennecke wrote:
Quoting Mohamed Shafi :
Hi,
I am doing a port in GCC 4.5.1. For the port
1. there is only (reg + offset) addressing mode only when reg is SP.
Other base registers are not allowed
2. FP cannot be used as a base register
> +extern objfile_read *
> +objfile_open_read (int descriptor, off_t offset, const char *segment_name,
> +const char **errmsg, int *err);
...
> +extern objfile_write *
> +objfile_start_write (objfile_attributes *ATTRS, const char *segment_name,
> + const char **errm
On Fri, Oct 29, 2010 at 4:39 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote:
>>> Paolo Bonzini writes:
>>>
On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
> configure.ac
> Add libgo. If building Go, build C++ as a bo
34 matches
Mail list logo
