Grigory Zagorodnev wrote:
Hi!
/gcc-43/src/libgcc/../gcc/unwind.inc:287: internal compiler error: tree
check: expected class 'expression', have 'constant' (integer_cst) in
ia64_expand_builtin, at config/ia64/ia64.c:9194
xgcc(cc1) fails at expand of __builtin_ia64_bsp regardless of the
optimiz
Hi,
May somebody can explain me, the following case. I compiled a
cross-complier for x86_64-pc-mingw32 and was successful on translare with
the following build steps:
1. configure --target=x86_64-pc-mingw32
2. make all-gcc
3. make install-gcc
But then I noticed, that the pathes to the tool-chai
Kai Tietz wrote on 19/02/2007 10:29:13:
> Hi,
>
> May somebody can explain me, the following case. I compiled a
> cross-complier for x86_64-pc-mingw32 and was successful on translare with
> the following build steps:
> 1. configure --target=x86_64-pc-mingw32
> 2. make all-gcc
> 3. make install
On 2/19/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Grigory Zagorodnev wrote:
> Hi!
> /gcc-43/src/libgcc/../gcc/unwind.inc:287: internal compiler error: tree
> check: expected class 'expression', have 'constant' (integer_cst) in
> ia64_expand_builtin, at config/ia64/ia64.c:9194
I think th
But then I noticed, that the pathes to the tool-chain - which is
installed
under /usr/local/x86_64-pc-mingw32 - is used while compile, is somehow
broken for the gcc tool. I assume, that the gcc toolchain is to be found
under /usr/local/libexec/gcc/x86_64-pc-mingw32/4.3.0, but it is search in
/
Hi,
No the point is that I am using the default settings of gcc (without any
"--prefix="). The compiler is built and installed at the expected place
(/usr/local/libexec/gcc/...), but the gcc,exe tool installed under
/usr/local/x86_64-pc-mingw32/bin does not have the proper path to its gcc
tool
On 2/19/07, Lee Millward <[EMAIL PROTECTED]> wrote:
On 2/19/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
> Grigory Zagorodnev wrote:
> > Hi!
> > /gcc-43/src/libgcc/../gcc/unwind.inc:287: internal compiler error: tree
> > check: expected class 'expression', have 'constant' (integer_cst) in
>
Hi,
please could someone comment on this one:
http://gcc.gnu.org/ml/gcc/2007-01/msg01261.html
I still don't have a solution to replace the mode(word) uses in unind-generic.h
with a different mechanism. Currently mode(word) is the only way how non-gcc
code can define the _Unwind_Word data type.
On Mon, Feb 19, 2007 at 10:35:41AM +0100, Kai Tietz wrote:
> Hi,
>
> No the point is that I am using the default settings of gcc (without any
> "--prefix="). The compiler is built and installed at the expected place
> (/usr/local/libexec/gcc/...), but the gcc,exe tool installed under
> /usr/loc
Lee Millward wrote:
I think this is down to the CALL_EXPR changes. Can you try changing
and see if that fixes it? I'm not able to test this change myself at
the moment but I think the above should do it.
Just noticed I got the line number wrong in my message above. It
should be 9194 as reported
Thank you very much. I solved this problem (of my absent-mindedness). When
I use the binaries install in /usr/local/bin everything works well 8).
Sorry and best regards,
i.A. Kai Tietz
Daniel Jacobowitz <[EMAIL PROTECTED]>
19.02.2007 13:04
To
Kai Tietz <[EMAIL PROTECTED]>
cc
Tehila Meyzel
On Sat, 10 Feb 2007, Sascha Schwarz wrote:
> To support your efforts we put up a mirror on our website Cybermirror.org
> under http://gcc.cybermirror.org.
Thanks, but this currently gets me a
ZUGRIFF NICHT ERLAUBT
Die angeforderte Seite darf nicht angezeigt werden.
(which translates to "acc
It is my pleasure to announce that the steering committee has appointed
Kaz Kojima maintainer of the sh port. Kaz has already been serving as
maintainer for sh libraries/configury, and I know that Alexandre and Joern
are in full support of this nomination.
Please adjust the MAINTAINERS file acc
Hello,
I've got a question for experts of alias analysis in GCC.
In the CLI back-end of GCC, there is a CLI-specific pass responsible of
some modifications on GIMPLE that simplify the emission of CIL bytecode
(see http://gcc.gnu.org/projects/cli.html#internals for more details).
One of such mod
On 2/19/07, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello,
I've got a question for experts of alias analysis in GCC.
In the CLI back-end of GCC, there is a CLI-specific pass responsible of
some modifications on GIMPLE that simplify the emission of CIL bytecode
(see http://gcc.gnu.org/projects/c
> Date: Fri, 16 Feb 2007 18:26:10 +0100
> From: Steven Bosscher <[EMAIL PROTECTED]>
> I have tested a small patch on i686, x86_64, ia64, mips, and sh:
> Index: loop-unroll.c
> ===
> --- loop-unroll.c (revision 122011)
> +++ loop
Snapshot gcc-4.1-20070219 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070219/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello,
> For instance, let's consider the following struct definition (taken from
> gcc.dg/struct-alias-1.c):
>
> struct S {
>int a[3];
>int x;
> };
>
> This is the original code in GIMPLE pseudo-C dump representation:
>
> s.x = 0;
> i.0 = i;
> s.a[i.0] = 1;
> D.1416 = s.x;
>
On 2/19/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the vi
Daniel Berlin wrote:
>> > > > It looks like your changeset listed bellow makes performance
>> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal
>> > > > test for this issue this week and update you in any case.
>> > The price of fixing them in 4.2 was a serious performance
On 2/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
>> > > > It looks like your changeset listed bellow makes performance
>> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal
>> > > > test for this issue this week and update you in any case.
>> > The
On Mon, Feb 19, 2007 at 03:16:12PM -0800, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
> >> > > > It looks like your changeset listed bellow makes performance
> >> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal
> >> > > > test for this issue this week and update you in a
I've spent some time today looking at GCC 4.2.
I've heard various comments about whether or not it's worth doing a 4.2
release at all. For example:
[Option 1] Instead of 4.2, we should backport some functionality from
4.2 to the 4.1 branch, and call that 4.2.
[Option 2] Instead of 4.2, we shoul
H. J. Lu wrote:
> FP performance regressions of the recent GCC 4.2 (revision 120817)
> compiler against September GCC 4.2 (revision 116799)
> 410.bwaves -6.3%
> 433.milc-7.0%
> 437.leslie3d-25.4%
> 450.soplex -3.9%
> 459.G
On Mon, 19 Feb 2007, Mark Mitchell wrote:
> One of the key points behind these suggestions is that Red Hat and
> Novell plan to skip to 4.3 for their next releases, so we'll have a hard
> By hypothesis, 4.1 is satisfactory (shipping with major GNU/Linux
> distributions, and widely used throughou
On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
>... *All* releases seem to have the
> predictions that they are useless, should be skipped because the next
> release will be so much better in way X or Y, etc.; I think the question
> of how widely used a release series turned o
Daniel Berlin wrote:
>> 2. What is the effort required to backport the necessary infrastructure
>> from 4.3? I'm not looking for "a lot" or "is hard", but rather, "two
>> weeks" or "six months". What needs to be backported, and what are the
>> challenges?
>
> Including bug fixes, i'd guess 2 mo
On 2/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
>> 2. What is the effort required to backport the necessary infrastructure
>> from 4.3? I'm not looking for "a lot" or "is hard", but rather, "two
>> weeks" or "six months". What needs to be backported, and what are the
Wiadomość napisana w dniu 2007-02-20, o godz01:27, przez Joseph S.
Myers:
This is *not* the only such prediction for a previous release, by far,
just the one I found quickest. *All* releases seem to have the
predictions that they are useless, should be skipped because the next
release will
Target-specific builtins (that almost always map to a single
corresponding machine instruction) are presently registered with
add_builtin_function(). This function takes an `attrs' parameter that
can attached additional attributes to the builtin.
Some builtins can indeed be marked pure or const,
Mark Mitchell wrote:
I've heard various comments about whether or not it's worth doing a 4.2
release at all. For example:
[...]
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have
hello,
Please can any one tell me how to bulid gcc newer version for
generating
code for i960MC processor.
is there any switch to generate coed for i960MC or i will
have to build it first
for target i960.
Right now i am using Linux i686.Pleasee help me.
On Feb 19, 2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> It is my pleasure to announce that the steering committee has appointed
> Kaz Kojima maintainer of the sh port.
Awesome! Congratulations to Kaz, and thanks to the Steering Committee
for having accepted our recommendation.
--
Alexand
Hello,
> >you might try turning the references to TARGET_MEM_REFs, and copy the
> >alias information using copy_ref_info to it. I am not sure how that
> >would interact with the transformations you want to do, but we do lot
> >of magic to keep the virtual operands for TARGET_MEM_REFs the same
> >
34 matches
Mail list logo
