: nop
5ffe0694: 1047beqzv0,5ffe06b4
Why? And the symble 'b' is of absolute type(*A*)?
2006/2/23, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Thu, Feb 23, 2006 at 01:33:05PM +0800, Eric Fisher wrote:
> > $ mips-elf-gcc -shared -fpic f
Hi,
I'm really confused by mips targets, such as mips-elf, mips-linux,
mips-elf-linux, mips-elf-linux-gnu. I will appreciate if anyone can
tell me the difference between them.
Thanks.
Eric.
On Feb 23, 2006, at 5:27 PM, Eric Fisher wrote:
Hi,
I'm really confused by mips targets, such as mips-elf, mips-linux,
mips-elf-linux, mips-elf-linux-gnu. I will appreciate if anyone can
tell me the difference between them.
The last two don't exist.
The first one is to target an
in
ux --prefix=/home/smj/local/
--with-as=/home/smj/local/bin/mytarget-linux-as --with-
ld=/home/smj/local/bin/mytarget-linux-ld
Kind regards,
Eric.
there anyway to make them to
default options?
Thanks.
Eric.
On Feb 27, 2006, at 10:52 PM, Eric Fisher wrote:
Hi,
I installed cross gcc3.4.4 on my linux/pc server with
--target=mips-elf. When I use mips-linux-gcc to compile a c file, the
assembly code will have psuedo-op used for system v.4 (e.g. .cpload).
And the object file is of big endian. So I have
But, they told me that mips-elf is for 'no-opsys' target, and does't
support glibc. So if I want to use gcc for operantion system and
glibc, should I use mipsel-linux?
Thanks
27 Feb 2006 22:55:48 -0800, Ian Lance Taylor :
> "Eric Fisher" <[EMAIL PROTECTED]&g
I think we shouldn't make abicalls as default in my opinion. :-)
2006/2/28, Eric Christopher <[EMAIL PROTECTED]>:
>
> On Feb 27, 2006, at 11:01 PM, Eric Fisher wrote:
>
> > But, they told me that mips-elf is for 'no-opsys' target, and does't
>
we really care about it for Doug's work.
Thanks for your feedback.
--
Eric Botcazou
s about the bounds of types, but it does
virtually use the whole spectrum of TYPE_PRECISION, TYPE_MAX_VALUE and
TYPE_MIN_VALUE settings, unlike the C-family of front-ends.
This problem was already raised when Diego contributed the VRP pass and Diego
ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch.
--
Eric Botcazou
PE_UNSIGNED? How do you represent subtypes with non-canonical bounds?
--
Eric Botcazou
uble? */
I think we would need to clarify that, because I'm not sure the Ada front-end
directly generates:
D.1480_32 = nam_30 - 30361;
if (D.1480_32 <= 1) goto ; else goto ;
:;
D.1480_94 = ASSERT_EXPR ;
--
Eric Botcazou
GNU tools), probably an assembler problem/limitation.
--
Eric Botcazou
write the patch, provided that
an adept at the new bootstrap (black) magic gives me a clue as to where I
should start. :-)
--
Eric Botcazou
Hi,
After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my
friend told that there is also a target of mips-linux-elf. My God,
confused.
Yours,
Eric.
On Mar 1, 2006, at 1:43 AM, Eric Fisher wrote:
Hi,
After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my
friend told that there is also a target of mips-linux-elf. My God,
confused.
Ignore your friend.
-eric
rmance anyway, so
> having a compliant implementation by default won't harm.
Changing compilation options to paper over potential bugs is IMHO not the best
approach, especially if the new options are little used. And the current
implementation of -gnato makes it a "heavy" option, not a "light" one.
--
Eric Botcazou
> it's not a bug, -gnato is clearly documented as required in this
> case, what makes you think otherwise?
Laurent's message.
Sorry about that, -gnato indeed has always been specified for this test.
--
Eric Botcazou
1 '\001', rangep=1 '\001', truncatep=0 '\0')
at /home/eric/svn/gcc/gcc/ada/trans.c:5322
5322 tree gnu_type = get_unpadded_type (gnat_type);
5323 tree gnu_in_type = TREE_TYPE (gnu_expr);
5324 tree gnu_in_basetype = get_base_type (gnu_in_type);
5325
_LANG_FLAG_2 (NODE)
>
> c460008__unsigned_edge_8 has the TYPE_EXTRA_SUBTYPE_P flag set.
Which is of course a bit confusing because get_ada_base_type precisely returns
the first subtype "not known to the front-end"...
--
Eric Botcazou
hecking in that change.
Right, we need to fix it ASAP because a testsuite hang on x86 is pretty much a
show stopper. Richard, could you please install the change?
--
Eric Botcazou
> I missed the fact that the test was already in overflow.lst :)
No worries, so did I. :-)
--
Eric Botcazou
on my sim? Or, which functionality should the sim
provide in order to run shared file.
Thanks.
Eric.
stage1_cflags="${stage1_cflags} -fkeep-inline-functions"
>fi
>
> since most versions of GCC (at least 2.7.2 which is the oldest I ever
> used, around 1998 on RH5.2) have the flag.
I'm not an autoconf guru but this test is trivial to write so I'd rather play
by the most strict rules.
--
Eric Botcazou
html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00345.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00344.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00343.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00342.html
--
Eric Botcazou
1, build_int_cst (etype, 0), value);
}
I gather that we should restrict the transformation to INTEGER_TYPEs.
--
Eric Botcazou
their base type.
I'm testing a pure fold-const.c patch based on Richard's suggestion.
--
Eric Botcazou
> One more note, we see the same kind of conditional and test
> simplification with for cxa4028 in Ada.Strings.Superbounded.Super_Trim.
> So I'm pretty confident that if we fix the bogus trees generated for
> a-stwifi.adb that all three of these regressions will be fixed.
Con
so "GCC for SPARC Systems" is a bit
misleading, given that FSF GCC for SPARC does run on the aforementioned
operating systems in addition to Solaris. Something like "Sun GCC for
SPARC/Solaris Systems" although I'm not sure if using "GCC" is not already
misleading.
--
Eric Botcazou
> GCC 4.0.3 has been released.
You need to add a link on the page
http://gcc.gnu.org/gcc-4.0
Similarly for the 4.1.0 release on the page
http://gcc.gnu.org/gcc-4.1
And don't you need to display the release date instead of "current changes"
for 4.1.0 on the main page?
--
Eric Botcazou
,
> so at the same time it would be good to change it to v8plus as well.
>
> All that changes can be done by easily tweaking gcc/config.gcc
> by adding with_cpu=v9
I'm all for it, at least for Solaris 7+.
--
Eric Botcazou
> It seems everybody agreed that solaris 10+ can be changed to -mcpu=v9
> default. Great!
> What are the thoughts about Solaris 7,8,9 ?
Go ahead, post the patch for Solaris 7+ on gcc-patches@, I'll install it.
--
Eric Botcazou
> Hi Jeff, this seems to work nicely - thanks again.
Well, this has introduced 3 regressions in the ACATS testsuite on x86/x86-64.
--
Eric Botcazou
> Which ones?
PR tree-optimization/26797.
--
Eric Botcazou
By enhancing the GOMP parser to handle
CONVERT_EXPR like NOP_EXPR (in check_omp_for_incr_expr)? Would other parts
of the compiler not be silently affected by similar problems that could
disable optimizations? By building a NOP_EXPR in convert.c instead of a
CONVERT_EXPR for the long int to int conversion?
Thanks in advance.
--
Eric Botcazou
ng constant sharing. */
value = build_int_cst_wide (TREE_TYPE (value),
TREE_INT_CST_LOW (value),
TREE_INT_CST_HIGH (value));
}
void foo ()
{
int x = (int) (unsigned int) (int) (-1);
}
--
Eric Botcazou
> Pragmatically I guess it is best for me to maintain a reversed patch
> which can be applied to a gcc-4.1.0 tar ball which reintroduces this
> TYPE. Any thoughts?
Integrating the Modula-2 front-end?
--
Eric Botcazou
under certain circumstances, modelled on flag_wrapv for Java.
> In the long run, TREE_OVERFLOW should go away and fold should
> provide front ends with information about the sorts of overflow happening
> so front ends can track their own information about what counts as
> overflow in each language.
Yes, that sounds like a good plan.
Thanks for your feedback.
--
Eric Botcazou
t) >= 0)
|| (! pos && TREE_INT_CST_HIGH (t) == -1
--- 4395,4400
--
Eric Botcazou
> Now, the question is: should `get_base_var' be extended to handle
> CONSTRUCTOR nodes or is ADDR_EXPR of a CONSTRUCTOR forbidden from
> getting there?
The latter. See PR c++/23171 and PR ada/22533.
--
Eric Botcazou
ight direction
> on this one... Do I need a patch for gcc 3.4.4 to build on sparc?
Nope, but please read the instructions carefully:
http://gcc.gnu.org/install/specific.html#x-x-solaris2
--
Eric Botcazou
> I thought it was OK to use a relative path. From what I understood, it is
> a bad idea to build inside the directory that the gcc tar file is
> uncompressed into, but I guess I can specifiy the path in full.
Yes, and while you are at it, use the recommended config shell.
--
Eric Botcazou
hi,
You know that treelang prescribes the function prototype must give the
storage class type explicitly, for an example, "external_definition
int add(int arg1, int arg2);"
I'd like to know how to modify the parse.y to let the storage type can
be implicitly and the default type is external_definiti
hi,
When I build gcc-3.2.2 for mips target, there's an error. What's the problem?
Thanks
Eirc
ake[1]: Leaving directory `/home/cii/qwang_gcc/libiberty'
xgcc: specs file malformed after 4096 characters
xgcc: specs file malformed after 4096 characters
xgcc: specs file malformed after 4096 character
Seems the question has been solved, here is the changes of
treelang/parse.y, just for fun :-)
$ diff treelang/parse.y treelang/parse_new.y -u
--- treelang/parse.y2004-01-08 15:50:46.0 +0800
+++ treelang/parse_new.y2006-04-13 18:00:34.390625000 +0800
@@ -48,6 +48,7 @@
#include
On Apr 14, 2006, at 8:29 AM, Shantonu Sen wrote:
(Moving to gcc@)
Eric, when will this be resolved? It's been over a month, and test
suite results still are horrible
I had MACOSX_DEPLOYMENT_TARGET set in my environment, when I removed
that everything worked just fine for me...
an't update the 10.4 version file. Since libgcc is unlikely to be
updated until 10.5 then ...
-eric
yone help me out and figure out what the problem is.
Delete your build directory between builds.
-eric
e () == 0 \
? assign_stack_local (MODE, GET_MODE_SIZE (MODE), 0) \
: gen_rtx_MEM (MODE, plus_constant (frame_pointer_rtx, \
STARTING_FRAME_OFFSET)))
--
Eric Botcazou
> Unfortunately, GCC needs to do marketing of performance, just like
> other compilers.
Not so obvious premise I'd personally think. Where would it come from?
--
Eric Botcazou
modifying that. It seemed weird to have a variable named the same as
the mode macro.
-eric
.
cpp relies on libiconv for almost all of it's translation support.
Try preprocessing a file with iconv and see if you can compile it
afterwards. If you can, then it's a gcc bug, otherwise you'll need to
bug the libiconv folks about implementing support.
-eric
Presumably, cpp wants everything from libiconv in UTF-8 with no BOM.
Yes.
-eric
> Any ideas?
Re-run the testsuite, they most likely will disappear.
--
Eric Botcazou
> FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_y_tst.o compile
I cannot reproduce on Solaris as of today, neither with the 64-bit compiler
nor with the 32-bit multiarch one.
--
Eric Botcazou
and split into
"atoms". Any atom not in the direct call graph or without a
relocation is then deleted in the final linked image.
-eric
the one not through MAC installer)?
Why not the one through the Xcode installer? At any rate, if you want
something else you'll need to use that one to build it.
-eric
entation
of source locations between successive generations of the core compiler.
--
Eric Botcazou
have to
bother about the legacy of a 10+ years old production compiler like GNAT.
--
Eric Botcazou
e the default, and
> Ada is basically the major blocker right now, so we need to agree on
> something instead of arguing... ;-)
Agreed. :-)
--
Eric Botcazou
> The real problem, as we all know, is that Adacore treats the GCC repo
> like an extension of their corporate repo, instead of as the main tree.
>
> The other languages don't do that.
What of Apple and Objective-C++ ?
--
Eric Botcazou
> They don't complain and they update their sources when integrating
> into the mainline. They had to update Objective-C++ for the new C++
> parser.
Just like AdaCore had to update Ada for tree-ssa?
--
Eric Botcazou
> Notice that the C and C++ parts are 10+ years old production compilers
> and they were converted.
Right, no disagreement. My reply was intended to be more general, on the same
level as Daniel's.
--
Eric Botcazou
On May 14, 2006, at 12:13 PM, Eric Botcazou wrote:
They don't complain and they update their sources when integrating
into the mainline. They had to update Objective-C++ for the new C++
parser.
Just like AdaCore had to update Ada for tree-ssa?
That's part of maintaining. Som
er compilers, especially the C family of compilers, there is no private
internal representation since they essentially manipulate the tree IL
directly.
--
Eric Botcazou
hi,
Anybody knows that if we can define a comment? For a statement such as,
COMMENT this is a comment.
will be preprocessed as,
// this is a comment.
or something valid and transparent to the compiler? Of cause we can't
directly use,
#define COMMENT //
Thanks.
Eric.
install cc or gcc in my
MAC OS X 7.9, thanks in advance, eric
What problem? You've not shown a problem, said what you're trying to
do, or anything. Honestly you should just download the latest copy of
Xcode from the Apple website which has a version of gcc.
And, I have no idea what
hi,
Does gcc support Simple Chinese language for now? Is there anyone
working on this?
Thanks.
more than just the gcc executable.
-eric
as.o
> "../../../gcc-4.1.1-20060517/gcc/tree-ssa-structalias.c", line 1615:
> warning: end-of-loop code not reached
> cc: Fatal error in /opt/SUNWspro/bin/../WS6U1/bin/acomp
> Status 138
> gmake[3]: *** [tree-ssa-structalias.o] Error 138
What happens if you configure with CC="cc -erroff"?
--
Eric Botcazou
> Anyway, how does this look to everyone?
FWIW fine with me. Thanks for taking care of this!
--
Eric Botcazou
On May 28, 2006, at 2:06 PM, Manuel López-Ibáñez wrote:
Thanks Andrew, that is exactly what I did, although I was expecting
configure to be smart enough to use that trick on my behalf.
but that would be guessing what you meant and not requiring you to
explicitly say what you meant.
-eric
a combined tree for this. There are also docs
on the web page on how to build a cross toolchain:
http://gcc.gnu.org/simtest-howto.html
-eric
, insn=0xb7f34b00,
in_mem=0)
at ../../gcc/gcc/jump.c:1469
The thing to figure out is why you're passing x=0x0 into
mark_jump_label.
-eric
x27;m sure it is my fault in some way... :-)
Well, it's likely the rtl that you're generating so, yeah, it'd be
likely your fault. :)
Otherwise you also might want to look to moving to 4.1/2 as long as
you're moving.
-eric
roduce with the same setup:
/bin/ksh ./libtool --tag=GCJ
--mode=link
/opt/build/eric/gcc-4_1-branch/gcc/gcj-B/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava/
-B/opt/build/eric/gcc-4_1-branch/gcc/
-L/opt/build/eric/gcc-4_1-branch/sparc-sun-solaris2.8/libjava -g -O2 -o
jv-convert
an move to something like -Wprototype-conversion or something for
the other (and stick the second in -Wall and have -Wconversion be
outside of that perhaps... that'd be up to others to debate though).
-eric
hi,
I configure GCC as follow:
PATH=/gnutools/bin:$PATH ; export PATH
mkdir -p /tmp/build/gcc
cd /tmp/build/gcc
/src/gcc-3.2.1/configure --target=mipsel-elf \
--prefix=/gnutools --enable-languages=c,c++ \
--with-gnu-as --with-gnu-ld --with-newlib \
--without-headers --disable-shared --disable-t
a striking example of the *major* problems we have been having
in the patch reviewing department for quite some time.
--
Eric Botcazou
> Thanks for chiming in this discussion. You've clearly given a good deal
> of thought to the problem, and if you have suggestions I'm all ears.
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00297.html
--
Eric Botcazou
> I didn't understand the purpose of:
>
> (build/gencondmd.o): Filter out -fkeep-inline-functions.
Read the comment?
--
Eric Botcazou
> However, the audit trail of the PR seems to say that now
> -fkeep-inline-functions is sort of implied by -O0; I can build
> insn-conditions.md with "-O0 -fkeep-inline-functions" so I'm not
> affected by the PR.
Comment #36 seems to say that we're back to the initial state.
--
Eric Botcazou
For example we could introduce
secondary maintainers with approval rights for bug fixes only or something
along these lines.
--
Eric Botcazou
> I actually like the existing behaviour, which I'm pretty sure hasn't
> changed for many years.
It has, at least for "make quickstrap".
--
Eric Botcazou
> By the way, -ftrapv only works on integral types.
When it works. Last time I took a look, it was easily wiped out by
optimization.
--
Eric Botcazou
and so on ad nauseam. The problem boils down to operand_equal_p returning
false on
operand_equal_p (arg0=0x93dc744, arg1=0x94d4724, flags=2)
at /home/eric/gnat/gnat6/src/gcc/fold-const.c:2491
2491 if (TREE_CODE (arg0) == ERROR_MARK || TREE_CODE (arg1) ==
ERROR_MARK)
(gdb) p d
> What do you mean by "in the VALUE_HANDLE itself"?
Returning a different VALUE_HANDLE for each instance of a volatile expression.
> I think we should not bother value-numbering volatile mem-accesses at all.
I guess that would be even better. :-)
Thanks for the quick fee
> It would be nice if you can track down this some more, as I do not
> have access to ppc-darwin.
And to SPARC/Solaris 32-bit? :-)
/opt/build/eric/gcc/./gcc/xgcc -B/opt/build/eric/gcc/./gcc/
-B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/bin/
-B/opt/build/eric/local/gcc/sparc-sun-sola
> At least this one looks "easier" to look at. Is SPARC/Solaris a
> strict alignment target?
Yes, all SPARC targets are.
--
Eric Botcazou
fail on SPARC64/Solaris 7+ either, for which the ABI says 16
for the alignment in both cases. They are 64-bit compilers.
--
Eric Botcazou
1048e58 "No space for profiling buffer(s)\n")
at /home/eric/svn/gcc/gcc/tree.c:1124
1124 length = len + sizeof (struct tree_string);
(gdb) next
1131 s = ggc_alloc_tree (length);
(gdb) p length
$1 = 58
(gdb) next
1133 memset (s, 0, sizeof (struct tree_common));
(gdb) p
SPARC64 bootstrap succeeds too. The discrepancy SPARC32/SPARC64
stems from the fact that SPARC32 also uses 64-bit instructions in some cases,
while there is no 128-bit integer instructions on SPARC64 so word alignment
is enough in practice.
--
Eric Botcazou
kernel coder wrote:
hi,
I'm trying to understand the backend code of gcc for MIPS
architecture.I'm having some trouble while understanding following
functions.
I think most of these are obvious, what problems in specific are you
having with them?
-eric
testsuite is clean:
http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00164.html
Not sure what's going on exactly...
--
Eric Botcazou
> Are you using --with-arch=i686 ?
Yes, I cannot reproduce the bootstrap failure with
[EMAIL PROTECTED]:~/build/gcc/native32> gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/eric/svn/gcc/configure i686-pc-linux-gnu
--prefix=/home/eric/install/gcc --w
reas' testsuite is clean:
> http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00164.html
... I get the tons of failures in libjava at rev 115159 too!
--
Eric Botcazou
> make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o differs
> warning: ./cc1obj-checksum.o differs
> Bootstrap comparison failure!
Does the attached patch make an
> What do we do if compiler ICE generating code for valid C syntax with
> defined behavior? Fix it!
> Why should we go another way for valid C syntax with undefined behavior?
The answer is in the question, no?
--
Eric Botcazou
hat do not use ARRAY_RANGE_REFs. With the additional patch, it is
supposed to be strictly a nop for them. Have you tried to revert it?
In the meantime I'm going to test on another machine.
--
Eric Botcazou
> Hmm, as far as I can tell, stage1 i386.c:ix86_split_ashr has been
> miscompiled by gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-54).
Thanks a bunch for sorting this out!
--
Eric Botcazou
1001 - 1100 of 1858 matches
Mail list logo