if (DWARF2_UNWIND_INFO || DWARF2_FRAME_INFO)
initial_return_save (INCOMING_RETURN_ADDR_RTX);
#endif
--
Eric Botcazou
of 1 cycle instructions more offently?
You'll want to probably use -march= so that it will generate
the instructions. Tuning is otherwise just costs, and some universal
features of the core that would also run on more generic arm chips.
-eric
ver plagued by serious
problems due to the SRA bit-field patch.
--
Eric Botcazou
> -Original Message-
> From: Mike Stump [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 28, 2007 6:47 PM
> To: [EMAIL PROTECTED]
> Cc: gcc@gcc.gnu.org
> Subject: Re: how to start using gcc on windows
>
> On Apr 28, 2007, at 5:03 PM, [EMAIL PROTECTED] wrote:
> > I have looked hard, bu
> GCC 4.2.0 RC2 is building now, and, if all goes well, will be announced
> and uploaded later today.
Bad timing I'd think, Ian's controversial TYPE_MAX_VALUE patch is still there.
--
Eric Botcazou
/usr/local --enable-doc --disable-libssp
Thread model: single
gcc version 4.2.0 20070430 (prerelease) (WinAVR 2007xxyy)
This is building from the "core" .bz2 and "c++" .bz2 packages.
Eric Weddington
27;make -C gcc gnattools'.
[EMAIL PROTECTED] i586-mandrake-linux-gnu]$ gcc/xgcc -v
Using built-in specs.
Target: i586-mandrake-linux-gnu
Configured with: /home/eric/gnat/gnat6/src/configure i586-mandrake-linux-gnu
--with-as=/usr/bin/i586-mandrake-linux-gnu-as
--with-ld=/usr/bin/i586-mandrake-linux-
> also on 4.0 branch, LAST_UPDATED: Thu Mar 3 12:00:26 UTC 2005
Sure? The suspected patch is not present on that branch.
--
Eric Botcazou
.0 branch, and I don't see any
patch from you or Roger there, so I presume you're confusing with mainline.
--
Eric Botcazou
n matches the
> Linux version, also the Solaris version behaves like *I* expect.
The shared version is required on Solaris to properly support exception
handling across shared libraries.
> Now my question: which behaviour is the correct one?
Both.
--
Eric Botcazou
n
> the same way, no dynamic linking necessary. With the newest snapshot
> gcc-4.0-07032005 there is dynamic linking necessary. The code is written in
> C++, but there is no exception handling.
That's a bit odd. However we would need more information to properly diagnose
the
ibgcc if
you want to use the static libgcc, at the cost of proper EH support.
--
Eric Botcazou
ines in C
> is that they will see more testing. I think it would be really tough
> for, say Ada, to rely on features in the backend that are not used at
> all by C/C++.
That's already the case for other features, although these are primarily
middle-end features.
--
Eric Botcazou
GCC, I think we'd be better off with a function
> attribute which prevented cross jumping to any function with
> the attribute set.
I think it makes sense to just not crossjump noreturn attribute
functions if we're going to do this.
-eric
> What we might want to do is provide an option to disable all such
> optimizations.
>
We have had enough requests for -Odebug or something like that.
Probably could be just dce, ccp, and a couple of other optimizations...
-eric
> stage1/xgcc -Bstage1/ -B/usr/local/sparc-linux/bin/ -c -g -O2
> -gnatpg -gnata -g -O1 -fno-inline \
> -I- -I. -Iada -I/usr/local/src/trunk/gcc/gcc/ada
> /usr/local/src/trunk/gcc/gcc/ada/a-except.adb -o ada/a-except.o
> unhandled expression in get_expr_operands():
>
This i
back-end and be released with 4.1. The amount of
work is not overwhelming but, as GCC is a volunteer project, your company
might consider hiring someone to do the work if it deems the feature a
requirement for 4.1.
--
Eric Botcazou
s that any chance these libraries to be
> build without
> mention relocation?
You could also try upgrading your gcc and binutils. Without a testcase
I'm not certain what's happening, but we've fixed a number of problems
with such over the years.
-eric
> If my conclusion is correct, is it possible to rebuild this libraries with
> -mlong-calls and -G0 option?
Yes. You'll need to modify the multilib options.
-eric
ssion guidelines on:
http://gcc.gnu.org/contribute.html
-eric
> 20263 SPARC64 ASM bug
>
> Eric has a patch; I've asked about possible other ways to fix it.
I've answered, but probably not very constructively as your remark was not
crystal-clear either. :-) Btw, I think you should "Add CC" you when you
comment on specific
reas with a bare 'make' it is built by the installed
compiler. So in general the final compilers are not identical.
What prevents you from setting CFLAGS="-O2 -fomit-frame-pointer" if you
happen to be rebuilding the compiler with an installed version of itself?
--
Eric Botcazou
Why should 2 different build processes generate the
same executable? Is there a (written) rule about this?
--
Eric Botcazou
problem is present in 3.4.x for the C++ compiler (but
> > is not a regression there) so I'd like you to make a decision for that
> > branch too.
>
> I'd prefer not to apply this for 3.4.
Agreed.
--
Eric Botcazou
ding some kind of
> special support. (I'm not actually sure what the assembler does with
> the name; presumably puts it in debug information.)
I can speak for the SPARC 64-bit assembler: it creates a special ELF symbol
for it (STB_GLOBAL, STT_REGISTER, SHN_UNDEF).
--
Eric Botcazou
> I do regular bootstraps of mainline all languages on FC3
> i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm using
> --enable-checking=tree,misc,rtl,rtlflag which might make a difference.
You should add 'assert' with 4.x, otherwise you miss the
nfig/mips/t-elf.
gcc/config.gcc has the multilib makefile fragment used for each target.
-eric
directory `/usr/local/src/trunk/objdir32/gcc'
> make[1]: *** [stage2_build] Error 2
> make[1]: Leaving directory `/usr/local/src/trunk/objdir32/gcc'
> make: *** [bootstrap] Error 2
Now fixed. Thanks for the heads up.
--
Eric Botcazou
rk into gas and so it wasn't added. The tests are still in gcc:
./gcc.c-torture/compile/mipscop-4.c
./gcc.c-torture/compile/mipscop-3.c
./gcc.c-torture/compile/mipscop-2.c
./gcc.c-torture/compile/mipscop-1.c
At some point it might be good to collate all of the mips specific tests
into the gcc.target directory. I doubt that cvs history is particularly
important for tests.
-eric
neration.
>
I'm not sure what the question is here.
> Plus: can gcc co-operate with dynamic code generation tools e.g. the GNU
> lightning? I have also heard of another tool, dcg (if i spell it correctly).
I've not done any of this.
-eric
f d_off;
} d_un;
} Elf32_Dyn;
Here's what I get with -H:
. /opt/build/eric/gcc-3_4-branch/gcc/include/sys/types.h
.. /usr/include/sys/isa_defs.h
.. /usr/include/sys/feature_tests.h
.. /usr/include/sys/machtypes.h
.. /usr/include/sys/int_types.h
.. /usr/include/sys/select.h
... /usr
> > Here's what I get with -H:
>
> Sorry? -H applied to what command?
The GCC command line you pasted.
--
Eric Botcazou
how to proceed though.
Remove that file when bootstrapping GCC or configure --with-local-prefix.
--
Eric Botcazou
No, is not directly included, only .
--
Eric Botcazou
Hi Eric,
The __builtin_apply/__builtin_return mechanism is broken on SPARC in 4.x
because of
2004-03-17 Eric Christopher <[EMAIL PROTECTED]>
* builtins.c (apply_args_size): Use reg_raw_mode.
(apply_result_size): Ditto.
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg0142
> That was my thoughts too. You could take a look at how I fixed it on
> ARM.
Thanks. So basically you bypass the apply_result_mode array entirely, which
is still wrong as it is on SPARC?
--
Eric Botcazou
> sparc
>
> Eric Botcazou says he is working on predicates.md himself.
>
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01694.html
Confirmed. :-) However don't hold your breath, my priority is 4.0.0 until
after it is released.
--
Eric Botcazou
s bigger and
> better, but don't need all the parts)
Configure with --disable-libgcj. I even considered making this the default on
SPARC/Solaris because libgcj build times are insanely long in 4.x and the
default setting is to build 2 such monsters on Solaris 7 and up.
--
Eric Botcazou
> single digits.
Sure, but libgcj build times have escalated, /bin/ksh or not /bin/ksh, and
they are getting unreasonable on (low-end) hardware currently sold by Sun.
--
Eric Botcazou
On Thu, 2005-04-07 at 16:48 +0200, Eric Botcazou wrote:
> > That was my thoughts too. You could take a look at how I fixed it on
> > ARM.
>
> Thanks. So basically you bypass the apply_result_mode array entirely, which
> is still wrong as it is on SPARC?
>
mode describes the widest mode of a *single* hard register.
Now, before your change, apply_result_size computed the widest mode of
*multi* hard registers, that's not the same thing.
--
Eric Botcazou
save the
values (a quick glance at sparc.md didn't show any problems, but...). Or
is something else clobbering later?
-eric
ll and untyped_return can be hacked to work around this (a la
ARM), but this would need to be done in every back-end. So I think you
should find another approach to fix your MIPS-specific problem, possibly by
hacking MIPS' untyped_call and untyped_return.
--
Eric Botcazou
x86_64-linux is clean too.
--
Eric Botcazou
cd $dir/run
> + if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
> + sync
> + fi
> target_run $dir/tests/$chapter/$i/$binmain >
> $dir/tests/$chapter/$i/${i}.log 2>&1 cd $dir/tests/$chapter/$i
> cat ${i}.log >> $dir/acats.log
Thanks, I'll test.
--
Eric Botcazou
> http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01875.html
A bit outdated. Most of them should be gone as of today.
--
Eric Botcazou
istributors will provide access to g77 as long until
gfortran is compliant with Fortran 77."
-eric
On Sun, 2005-04-10 at 12:23 -0700, Zack Weinberg wrote:
> Eric Christopher <[EMAIL PROTECTED]> writes:
>
> >> "This compiler at present doesn't cover all of Fortran 77. We assume
> >> distributors to provide access to g77 as long as that's us
ia:
>
> http://gcc.gnu.org/gcc-4.0/criteria.html
>
> for primary and secondary platforms.
sparc-sun-solaris2.9 is OK for C/C++/Objective-C/Ada/F95, except
FAIL: gcc.dg/builtin-apply4.c execution test
in 32-bit mode. Patch in testing.
We severely regressed for Java (22*2 new failures) 3 days ago.
--
Eric Botcazou
> Is that a regression though? builtin-apply4.c is a new test.
http://gcc.gnu.org/ml/gcc/2005-04/msg00299.html
--
Eric Botcazou
e
cases Java hackers should coordinate with the platform maintainers that try
to keep the Java compiler healthy on their architecture, despite the huge tax
of CPU cycles this entails. These CPU cycles should not be simply wasted.
--
Eric Botcazou
> Please post the list of failures to [EMAIL PROTECTED]
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00671.html
--
Eric Botcazou
nd SPARC is the port that features the greatest number of officially
appointed maintainers. :-)
> However, if you can let me have a logon I can have a look.
Thanks for the offer. I'll try and see what I can do.
--
Eric Botcazou
> which I see you've already committed a patch for, and a large number
> of Java failures.
>
> <http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html>
>
> for 4.0.0-20050410.
Same failure as on Solaris.
Andrew, do you have a Darwin machine at hand?
--
Eric Botcazou
> Did this get resolved?
We found that PowerPC/Darwin and SPARC/Solaris have regressed the same way.
Andrew should be looking at the failures on the Darwin side.
> Eric> Tom, I presume there was a very good reason for installing such
> Eric> a potentially destabilizing patch a
RC, so the 4.0.0pre compiler is now regression-free for all languages on
sparc-sun-solaris2.9 (as well as sparc64-sun-solaris2.9).
--
Eric Botcazou
er you compile with -m32 or -m64.
--
Eric Botcazou
not
> directly addressable
> ../sysdeps/unix/sysv/linux/mips/pread.c:86: error: memory input 6 is not
> directly addressable
Probably a problem with the INLINE_SYSCALL macro? Can you post a smaller
preprocessed testcase? (or at the outside the preprocessed file)
-eric
l is the default.
> >
> > I notice that these are pedwarns,
>
> In that case, we can enable it only when -pedantic is used (like many
> pedwarns) ?
You could, but in this case it's probably best to fix the code...
-eric
ml/gcc-testresults/2005-04/msg01297.html
--
Eric Botcazou
possibilities?
For 3.3 and 3.4, this was "fixed" by not recording memory equivalences that
have the infamous RTX_UNCHANGING_P flag set.
--
Eric Botcazou
oes the whole job should be made available.
The second patch is not necessary. It is only meant to avoid the tons of
failures you get (it was inadvertently dropped from Binutils 2.15).
--
Eric Botcazou
s of course not optimal, unnecessary spills are generated.
--
Eric Botcazou
as generated by GCC).
As an alternative, I could probably disable STABS for the 64-bit compiler.
--
Eric Botcazou
tion.
Was that long enough? :-) However, my reaction has not changed since
yesterday: did you mean SET_DEST?
--
Eric Botcazou
else than setting the pseudo to the value it
is already equivalenced to.
--
Eric Botcazou
sub in order
to proceed with the build. Haven't run into any other errors yet but
the build is still going...
Eric.
On Thu, 2005-04-21 at 22:27 -0600, Eric Lemings wrote:
...
> So again, I had to create links for install-sh and config.sub in order
> to proceed with the build. Haven't run into any other errors yet but
> the build is still going...
>
> Eric.
Build was successful after that.
> Not being able to build in the source directory is a bug.
> Having to set CONFIG_SHELL is a bug.
> Having to install a newer cctools is a bug.
>
> Bugs should be fixed. Papering over them with documentation is, well,
> unappealing to me.
How can you fix bugs in Solaris&#
the patterns you do have don't have a lot
of multiple insns to accomplish a single task, but also make sure that
you're generating the insns in the first place :)
-eric
abels
>
> Therefore :
> 1) This seems to be x86-specific, so I would suggest moving this
> paragraph from sparc-sun-solaris2* to i?86-*-solaris2*
The problem is present on SPARC so the paragraph can't be moved.
Not sure whether the bug ID is correct though.
--
Eric Botcazou
lignment errors
> during bootstrap.
Did you read http://gcc.gnu.org/install/specific.html? There are known
problems in some versions of the GNU tools and some versions of the Sun
tools. Please provide more detailed info.
--
Eric Botcazou
> is for x86 platforms only.
The problem is definitely present on SPARC (see the relocation).
> In any case this looks wrong and needs to be fixed.
Yes, we should probably revisit the problem.
--
Eric Botcazou
On Fri, 2005-05-06 at 07:06 +0200, Stephane Wirtel wrote:
> Hi all,
>
> I would like to know how many stages are there ?
> What's the first stage ?
>
http://gcc.gnu.org/develop.html
-eric
ctions
>
> c.lt.FMT and
> c.le.FMT
>
> instead of
>
> c.olt.FMT and
> c.ole.FMT.
No reason in particular. The only difference is that the first will
signal an exception on QNaN and the second won't, thereby simplifying
the programming model. Do you have a good reason for doing it the other
way?
-eric
hows up for sparc.
Do you have a testcase? AFAIK the problem only shows up with the Sun tools.
--
Eric Botcazou
> In any case it looks like gcc cannot be built on Solaris using standard
> GNU binutils releases.
2.15 is the only one problematic, unless proven otherwise.
--
Eric Botcazou
proven otherwise.
>
> No, I've had problems with almsot all other previous GNU binutils
> releases, see my previous posts on this list.
Including 2.13.x and 2.14?
--
Eric Botcazou
ibgcj.so.6
> collect2: ld returned 1 exit status
>
> Is there a way I can find the exact "ld" command line, in order to
> provide a small testcase for the GNU binutils bugzilla?
Pass -debug to collect2. I'm not sure this will give you a *small* testcase
though.
--
Eric Botcazou
ibgcj.so.6
> collect2: ld returned 1 exit status
>
> Is there a way I can find the exact "ld" command line, in order to
> provide a small testcase for the GNU binutils bugzilla?
Pass -debug to collect2. I'm not sure this will give you a *small* testcase
though.
--
Eric Botcazou
t to be enough.
Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not
be used to build libgcj nowadays. ;-)
--
Eric Botcazou
h-as and --with-ld are respectively
specified because the configure machinery will probe in that case.
They are required otherwise because the Sun tools are the default.
--
Eric Botcazou
the patched assembler. If we are lucky, the
problem was generic and has been fixed on SPARC too.
--
Eric Botcazou
> Personally, I think we should default to not installing libiberty.a,
> though we should install libiberty.so if we build it.
And fix PR other/16513 in the process.
--
Eric Botcazou
thing. IIRC I tried before filing the PR
but got lost in the configure machinery.
--
Eric Botcazou
> For one thing, libgfortran requires c99 support, which is not in
> newlib iiuc.
In practice, no, it doesn't. F95 works fine on Solaris 2.5.1, which is the
typical non-C99 native platform.
--
Eric Botcazou
> We'd unslush when the primary platforms have clean test results.
>
> Thoughts?
Aye :)
-eric
060.html
and can be considered as a baseline for now.
--
Eric Botcazou
> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
>
> The vectorization failures still need to be fixed.
Are these specific to SPARC? If so, I don't think development should be held
off for the
ve detected that the insn is not valid.
--
Eric Botcazou
struct S1132 {
struct{
unsigned long int b;
struct{void * d[7];}c[30];
}a[3];
char e:8) - 1) & 7) + 1);
struct{}f;
};
extern int fails;
void check1132va (int z, ...)
{
struct S1132 arg;
long double ld;
__bui
rc64-sun-solaris2.9> gcc/xgcc -Bgcc -S
t007_y.c -dr
cc1: warning: unrecognized gcc debugging option: r
[EMAIL PROTECTED]:~/build/gcc/sparc64-sun-solaris2.9> gcc/xgcc -Bgcc -S
t007_y.c
-fdump-rtl-expand
cc1: error: unrecognized command line option "-fdump-rtl-expand"
--
Eric Botcazou
a look and it seemed to work for me, I'll double check with a
clean tree and all multilibs in a bit.
-eric
> Eric (and anyone else who wasn't aware): there's been a lot of
> discussion about this on gcc-patches since I posted that message:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
>
> It's also PR21638:
>
> http://gcc.gnu.org/bugzi
han to iterate on each one separately.
>
> And int the mean time, things stay broken?
Probably for the best I agree. If things are broken I can wander my
sources back a few days and continue to get some work done.
-eric
se_ins_ext_p
What is yours?
--
Eric Botcazou
usable in modulo-sched.c.
* modulo-sched.c (doloop_register_get): Use
doloop_condition_get instead of duplicating it.
This patch. I've emailed Steven.
-eric
> For Ada, I propose we make the following changes:
>- by default, enable overflow checks using -ftrapv
-ftrapv is not practically usable because (1) it generates awful code and (2)
it badly interacts with the RTL optimizers.
--
Eric Botcazou
cause it is too low-level. Its
general mechanism certainly can help (once it is fixed) but it must be driven
by something more Ada-aware.
--
Eric Botcazou
> This particular problem is gone now
Right, works fine on Solaris too.
--
Eric Botcazou
at path.
> I don't see that's so terrible, the jmp will be free in practice anyway
> so I don't think you will find this slows things down.
You missed the point; the overflow check has been optimized away by one of the
RTL optimization passes.
--
Eric Botcazou
101 - 200 of 1857 matches
Mail list logo
